Existential Operator / Null Propagation Operator

Sebastian McKenzie sebmck at gmail.com
Wed Apr 8 02:34:56 UTC 2015


No, you’d just memoise it to a variable:



  a?.d().f?.b




to:




  var _temp, _temp2;

  (a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined ? _temp2.b : undefined) : undefined)));




You’re going to need to memoise all member expressions anyway as they might be accessing a getter and you don’t want to call it twice.

On Tue, Apr 7, 2015 at 7:32 PM, joe <joeedh at gmail.com> wrote:

> Okay.  I've updated my transpiler to demonstrate how (and why) this could
> work at the VM level (I do think VM devs will have to add new opcodes for
> this), and I've appended an example transformation to this email.
> Why is this so complicationed?  The answer is that when you start nesting
> ?. operators, it's pretty easy to cause some operators to be called twice.
> E.g, if you transformed the following to the NULL syntax:
>   a?.d().f?.b
> You would get:
>   (a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b
> : undefined) : undefined)));
> Notice how a.d() gets called multiple times.
> The solution is probably new VM opcodes.  Since my transpiler is obviously
> not a VM, it transforms ?. operators into auto-generated functions.
> Anyway, here's the example I transpiler:
>     a?.b.c.e?.f.g?.h.t.c?.d()?.e;
> Which turned into this:
>    function q0eILlfx7_3(obj) {
>     var _t=obj;
>     if (_t==undefined)
>       return undefined;
>     _t = _t.b.c.e;
>     if (_t==undefined)
>       return undefined;
>     _t = _t.f.g;
>     if (_t==undefined)
>       return undefined;
>     _t = _t.h.t.c;
>     if (_t==undefined)
>       return undefined;
>     _t = _t.d();
>     return _t;
>   }
>   q0eILlfx7_3(a);
> On Tue, Apr 7, 2015 at 6:24 PM, Brendan Eich <brendan at mozilla.org> wrote:
>> joe wrote:
>>
>>> That's a good point.  Are lexical non-DFA grammars allowed?  It would be
>>> trivial to solve that with a regular expression lookahead.  Although I
>>> suppose at that point you might as well call it a cover grammar.
>>>
>>
>> We must avoid being too clever -- it complicates implementations and
>> inevitably incurs future-hostility to extensions we may want, if not
>> outright bugginess.
>>
>> All of this suggests prefix ? is the better course. Anyone have
>> counterexamples?
>>
>> /be
>>
>>>
>>> Joe
>>>
>>> On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org
>>> <mailto:brendan at mozilla.org>> wrote:
>>>
>>>     joe wrote:
>>>
>>>         By the way, I don't remember having grammar issues (I use a
>>>         LALR compiler-compiler).  Looking at my code, it looked like I
>>>         handled it in the tokenizer stage; I added a COND_DOT token:
>>>
>>>         COND_DOT : \?\.
>>>
>>>
>>>     Did you keep backward compatibility? `x?.1:y` must continue to work.
>>>
>>>     /be
>>>
>>>
>>> No, it looks like I didn't.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/4df35294/attachment.html>


More information about the es-discuss mailing list