Allen Wirfs-Brock wrote:
This is good...Perhaps we should have a design rules section of the Wiki
to capture stuff like this?
I don't have edit rights to the wiki (the former ES4 wiki, that is, not
the Trac wiki), and AFAIK neither does anyone else who is not a member
of TC39.
-Original Message-
From: es5-discuss-boun...@mozilla.org
[mailto:es5-discuss-boun...@mozilla.org] On Behalf Of David-Sarah Hopwood
Sent: Friday, November 20, 2009 7:18 PM
To: es5-disc...@mozilla.org
Subject: Re: ES5 left-to-right evaluation order issues
Allen Wirfs-Brock wrote:
So, the main point is that a belief that ECMAScript has or is supposed
to have a strict left-to-right evaluation order (as the concept is
likely to be understood by typical users of the language) is wrong.
I'm going to have to insist that the understanding attributed to typical
users here is an improper understanding of evaluation and coercion in
general, and that ECMAScript *does* have left-to-right evaluation order.
In most languages, the issue we're discussing here doesn't arise because if
there are implicit coercions, these coercions don't have side effects, and
therefore they don't have an observable ordering.
However, in an imperative call-by-value language with left-to-right
evaluation where *individual operators* perform coercions with observable
side effects, the ECMAScript behaviour is precisely what should be expected.
That's because the coercions are not part of the definition of evaluation;
they are specific to the computations performed by each operator.
For example, the ECMAScript * operator behaves as though it were defined
something like the following function:
function *(a, b) {
return primitive_multiply(ToNumber(a), ToNumber(b));
}
Exactly as for a function application, the argument subexpressions are
evaluated, and then some computation is applied to the argument values.
The coercions are performed, in order, as part of that computation.
In fact, the coercions are different for each operator, so it is almost
essential that they be defined as part of the computation.
If the change to coercion order that Allen originally suggested were made,
then it would be necessary to understand the evaluation of operator argument
subexpressions as being influenced by the operator and by the argument
position (for example, the shift operators coerce their left subexpression
with ToInt32 and their right subexpression with ToUint32), as opposed to
being uniform for all subexpressions. This is in some ways even weirder that
what ECMAScript currently does.
It would also mean that if any future version of ECMAScript included operator
overloading, then either it would not be possible to precisely emulate the
semantics of the built-in versions of operators, or else the coercions would
have to be baked in and not overloadable (i.e. the overloading function
would have to receive its arguments pre-coerced, rather than being
responsible for coercing them). Either of these options are undesirable --
the former would be inconsistent, and the latter less flexible and less
efficient, since it wouldn't be possible to drop the coercions.
For consistency,
Dave-Sarah's observation that we first evaluate and then coerce
the operands is probably the guideline we should continue to follow if
we ever define any additional operators where the distinction is relevant.
Yes, also for the reasons above.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
