[erlang-questions] Core Erlang questions

[Richard Carlsson]

Lars-Åke Fredlund wrote:
>  From reading the Core Erlang 1.0.3 language specification it seems that
> it is impossible to have expressions with "complex subexpressions" (a 
> very nice syntactic property!)
> 
> For example,
>    the tuple
>            {2, receive <X> when 'true' -> X after 'infinity' -> 'true'}
>    would not be legal Core Erlang since the receive (like any other 
> expression)
>    returns a sequence, not a value. And because it is not a value,
>   such a sequence cannot be "spliced" into a tuple (except via an outer 
> let expression):
> 
>  let <_cor1> =
>            receive
>              <X> when 'true' ->
>                  X
>            after 'infinity' ->
>              'true'
>        in
>            {2,_cor1}
> 
> 
> Is this a correct understanding of the dynamic semantics? (or is a 
> singleton sequence also a value?)
> 
> How should one then understand the "2" in the tuple, doesn't this 
> expression also return a sequence?

No no, don't worry, you can nest expressions as much as you like.

Grammatically, page 7 shows how an Expression 'e' can be either a
SingleExpression 's' or a ValueList '< s1, ..., sN >' of zero or more
SingleExpressions. A SingleExpression is an "ordinary, plain expression"
like an atom, a tuple, a fun, a case switch, etc. The arguments to
these (such as the elements of a tuple) are in their turn also
Expressions.

Page 11 explains (or tries to) that in Core Erlang, every expression
evaluates to a sequence of zero or more values, whereas in plain Erlang,
an expression always evaluates to exactly one value. Sequences have no
runtime representation in themselves, so you cannot pass them around
or nest them. A sequence '<x>' is usually written 'x' where there is
no risk of confusion.

For the dynamic semantics ("what does it _mean_"), first, Page 13 states
that expressions used as arguments to other expressions (e.g., an
element of a tuple) is expected to always evaluate to a sequence of
exactly one element, i.e., you cannot return multiple values if you are
going to use the result as a direct argument - for that, you do need a
let-binding or similar to access the different values. But the main
thing (which is not very obvious), is that you need to read the
evaluation rules for expressions (section 6.3) carefully if you want to
see how the transition between "values" and "sequences" is specified.
For example, evaluation of a tuple is described like this:

 "{e_1, ..., e_n}
  This evaluates to the Erlang n-tuple {x_1, ...,x_n}, where for i in
  [1,n], e_i evaluates to x_i. ..."

Here, "e_i evaluates to x_i" really means "e_i evaluates to <x_i>"
(that's the "no risk of confusion" part above), so e.g. in your
example, the '2' evaluates to '<2>', from which the rule takes the
naked value 2 and uses it to construct <{2,...}>.

(In my original specification drafts, I used a downcast operator
everywhere to move explicitly from seqences to naked values, but
it turned out messy and unreadable. Switching to a more implicit
specification, I got something that is much more readable but
perhaps harder for a semanticist to follow to the point, at least
without a guide.)

    /Richard

PS. It was hard to write, so by Zeus, it should be hard to read!