Logical operators don't use valueOf()

Brendan Eich brendan at mozilla.com
Sun Sep 8 15:32:42 PDT 2013


> Marius Gundersen <mailto:gundersen at gmail.com>
> September 8, 2013 3:20 PM
>
> The only thing that is unclear is the reason memoizatation isn't used. 
> It would seem to be the way most of the js engines would implement 
> this anyways.
>

This isn't an implementation question -- first we have to agree on the 
semantics, then (unobservable except by stopwatch) optimizations can be 
done.

The semantics we discussed way back in late '96 or early '97 only 
briefly touched on memoization, and none of the implementors in the room 
liked it. We all had naive (and slow) interpreters then. We didn't do 
much or any analysis at compile time. We didn't have JITs.

> I'm not familiar with the inner workings of JavaScript JIT engines, 
> but in a situation like this, would that code not be compiled into 
> something which stores the truthyness of obj in a register, until the 
> expression is completely evaluated?
>

First, the more easy-to-understand semantics would not memoize -- it 
would *require* multiple calls to the hook, one for each implicit 
conversion. This is what value objects bring back; see Filip's post and 
my reply for more.

Second, we would have had a hard time specifying and requiring 
memoization. Your paragraph here hopes that it "falls out" of 
implementations, but there's no guarantee. A register-poor machine such 
as x86 would not necessarily even keep the last implicit conversion's 
boolean result around at all. If we required memoization, extra would 
would be done for every &&/|| chain.

Finally, if we came up with a guaranteed-idempotent extension mechanism, 
then we might indeed require memoization, but the spec would be quite 
complex. It does not seem worthwhile to go down this road.

> Thanks for the detailed information you can provide on this subject btw.
>

No problem. I hope it's clear this is not an implementation problem, 
rather a specification one, or two: (a) what do we *want*; (b) how can 
we spec that.

/be


More information about the es-discuss mailing list