ES5 left-to-right evaluation order issues

[David-Sarah Hopwood]

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-bounces at mozilla.org [mailto:es5-discuss-bounces at mozilla.org] On Behalf Of David-Sarah Hopwood
> Sent: Friday, November 20, 2009 7:18 PM
> To: es5-discuss at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091121/57bc0f3a/attachment.bin>