clarification on single assignment

[Richard Carlsson]

On Thu, 23 Nov 2000 matthias@REDACTED wrote:

> The strange thing about pattern matching with records is that no
> pattern matching actually occurs unless you're already in the context
> of another pattern match. 

Maybe you mean that the '=' in record field definitions should be read as
the generic match operator? Then would it be less confusing if the syntax
for records looked something like this?:

	A = B#type{name is value, foo is X, ...}

In record field descriptors `<Field> = <Value>', the '=' is just a
separator symbol, not an operator. It has no precedence, and does not need
one, since `<Field>' must be an atom.

> Why* can I write
>  
>   Value = 3,
>   B = #type{},
>   A = B#type{name = Value}.
> 
> but not
> 
>   B = #type{name = 3},
>   A = B#type{name = Value},
>   Value.
> 
> Pattern matching is supposed to bind unbound variables. If the second
> '=' really were a pattern matching operator, A would be the same as B,
> Value would be 3. Maybe it's "restricted pattern matching".

Because the expression `A = B#type{...}' is a "match expression", in which
the left hand side is a pattern, and the right hand side is *any
expression*. Here, the `=' is an operator which is left-associative and
has a certain precedence compared to other infix operators.

If the match expression regarded both sides as patterns (which can contain
free variables, to become bound), it would constitute a *unification*
operation, as found in Prolog, which has much more complicated semantics.

For example, if in your expression:

	A = B#type{name = Value}

both `A' and `Value' are allowed to be free variables, then what about:

	A = foo(Value)

(where foo is some function)? Should we evaluate `foo' like a logic
program would, passing it the *unbound* variable `Value'? No - this makes
the behaviour of programs difficult to understand and adds a runtime cost.
Erlang is a strict functional language for precisely the reason that this
model is well understood, makes programs easier to understand and to
predict the behaviour of, and can be efficiently implemented. However, the
reader must be able to distinguish between patterns and expressions in the
syntax.

	/Richard Carlsson



Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://www.csd.uu.se/~richardc/