[erlang-questions] Floating guard sequences

[Richard O'Keefe]

On 20 Feb 2009, at 2:31 pm, fess wrote:
> However this case made me realize that pattern matching in the '='
> had less power than in a case clause or a function clause where the
> guards were possible.  So that more balanced approach is what seemed
> interesting to me about Michael's proposal.

Trying to optimise several objectives at once is always tricky.
Surely uniformity and expressiveness are virtues.
But readability is also a virtue.

At the moment, my perspective on this is that of someone who
wants to _read_ Erlang code.  From that perspective, the most
important thing about an '=' binding is that it gives values
to some variables.  I need to *see* those variables.  Anything
that makes it harder for me to see those variables hurts.

It's sometimes overlooked that 'if' doesn't need more than one
clause.  So we can always write

	{X,[$x|Rest]} = string:to_integer(Str),
	if is_integer(X) -> true end,
	{Y,_        } = string:to_integer(Rest)

So it's not as if (Pattern when Guard) = Expression
added any power to the language; it can always be
rewritten as
	Pattern = Expression,
	if Guard -> true end
and we can clarify that a little bit with a macro:
	-define(check(X), if X -> true end).
then
	Pattern = Expression,
	?check(Guard)

This I can read.  I see clearly in one place what variables
are bound, with no distractions.  I see clearly in another
place what conditions they must satisfy.  Separating
?check from = means that it is now very easily thinkable
to use ?check in situation where there is no = .

If I were opposed to changes to Erlang on principle, I would
not have written as many EEPs as I have.  But Erlang has
notational resources already that are not getting as much
use as they should.


that