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: [email protected] > [mailto:[email protected]] On Behalf Of David-Sarah Hopwood > Sent: Friday, November 20, 2009 7:18 PM > To: [email protected] > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
