Field assignments are reordered in record creations
Thu May 25 00:24:54 CEST 2006
> So what is ,? Can I not depend on an expression prior to a , being
> evaluated before something after the ,? What about ; in guard statements?
> Is it the same idea, simply not called a sequence point? Or is the idea
> not existent?
Sequence points bring along a whole load of baggage that does not apply to
Erlang. For example, in C you can have multiple side-effecting subexpressions
between two sequence points, and much of the complexity of the sequence point
model is only needed to deal with that case. I would strongly discourage
anyone from trying to understand the evaluation order of other languages in
terms of concepts from C (especially since there are significant problems
with the way that the C89/C99 standards explain these concepts , even for
Besides, in the following C example similar to the Erlang one:
the reason for the nondeterministic evaluation order is *not* that the order
of execution between two sequence points is undefined. In C there is a sequence
point before and after each function call (i.e. at least 4 sequence points in
the example, besides those within the function bodies). In this example the
nondeterminism arises from the unspecified  order of evaluation of the
arguments to make_foobar, not from the order of execution between any two
consecutive  sequence points.
 One problem is that although the standards talk about "previous", "next"
and "consecutive" sequence points, the ordering of sequence points is
only partial, so it is not clear what these terms really mean. An annex
that would have clarified this was dropped in final editing of C99,
apparently because the C committee couldn't understand it.
 Note that use of "undefined" in the Erlang reference manuals is closer
to the use of "unspecified" in the C standard than to C's "undefined
> On May 24, 2006, at 9:59 AM, David Hopwood wrote:
>> David Hopwood wrote:
>>>> I don't believe what is happen is what you think is happening. The
>>>> issue is that the order of execution in a single sequence point is
>>>> not defined. Your code does no say anything about which record fields
>>>> gets assigned first, simply which function gets executed first. You
>>>> cannot depend on the order of execution of an expression to reflect how
>>>> you wrote it. Compilers are generally free to execute expressions in
>>>> whatever order is easiest for them.
>>> Erlang is not C; it has no concept of sequence points. However, you're
>>> correct that the evaluation order of arguments to an operator or
>>> function call is undefined. [...]
David Hopwood <>
More information about the erlang-questions