clarification on single assignment

[Robert Virding]

Hakan Mattsson <hakan@REDACTED> writes:
>
>You mean as perverse as the spurious ';' separator? ;-)

Well, actually the semantics of the "spurious ';' separator" is quite
clear and consistent, it is a sequential or operator between clauses.
Perhaps you are referring to the fact that it is a separator and not a
terminator, personally I have never had any trouble with that.  
I suppose we could make it a terminator if you really want, however, 
if you are willing to go through all code and add one to each final 
clause in every function definition and if/case/receive.  :-)

Otherwise trying writing as I have seen Richard O'Keefe does:

    case <expr> of
        <pat1> -> ...
    ;   <pat2> -> ...
    ;   <pat3> -> ...
    end,

which looks a little odd but is very logical.  I don't think Erlang 
mode supports it though.

>The semantics of the '=' operator depends of its context, but the '.'
>could not be reused as separator between function clauses!?

What is wrong with a whole function as one unit and not as a disjoint 
collection of clauses?  It is much clearer than allowing clauses to be 
separated.

The trouble with generally using '.' as an operator is that it can 
occur within a token, a float, and using it as operator can cause 
confusion. Prolog has/had it as the list operator so you could write 
a.b.c.d.[] instead of [a,b,c,d].  How do you parse 1.2.3.4.[]?  Forcing 
blanks occasionally sucks. (I know it is necessary now, but it still 
sucks)

>Perverse or not, I think that the different semantics of the '='
>operator in its various contexts (match/assign), is a little bit
>confusing. The bad example below does not work as you already pointed
>out, but both the ugly ones does. It is not intuitive.

Yes, I know, '=' is used in three contexts:

Explicit match operator
Couple record field name to value/pattern
Aliases in patterns.

The trouble is that there is a limited number of symbols on the 
keyboard so there will be overloading.

>    ugly() ->
>	B = #type{name = 3},
>	fun(A = #type{name = Value}) -> Value end(B).
>
>    ugly2() ->
>	B = #type{name = 3},
>	case B of
>	    A = #type{name = Value} -> Value
>	end.

I personally can't conceive why anyone would write aliases in patterns 
in that direction, I always do it the other way:

ugly() ->
    B = #type{name = 3},
    fun(#type{name = Value}=A) -> Value end(B).

Writing it this way means you have the same semantics as for a normal 
explicit match, take the value of "A" and match it with the record ...  
This then only gives two uses.

I was much to lenient with the syntax and didn't realise what people
would do with it.  Though after all these years you would think that I
would learn.  It ought to be changed.  So remember:

ALWAYS WRITE PATTERN ALIASES AS <PATTERN>=<VAR>!!

Hmm, maybe lint should warn? :-)

	Robert