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 : \?\. COND_DOT then became simply another binary operator in the Expression production. However, this is a very simple use case. Supporting e.g. function calls would require more tokens (which raises the question: why stop at '.'? Should we have arithmetic versions too?). Given the proliferation of binary operator tokens in JS, I'm not sure if this is a good thing. Joe On Mon, Apr 6, 2015 at 12:45 PM, joe <[email protected]> wrote: > I hacked together something similar myself. IIRC, this particular > transformation has issues with nested operators (e.g. a.b?.c.d?.e.f?.h). > Of course that's an implementation detail, but the problem (if I'm > remembering it right) is that people couldn't figure out what the > implementation constraints are (I think there was consensus that the > trinary transformation was unworkable), and without knowing those > constraints it wasn't possible to write a spec for it. > > I could be remembering all this wrong, but that's my recollection of how > that conversation went. I think the consensus was to wait for the ? > operator to become more mature in other languages. > > On Mon, Apr 6, 2015 at 12:19 PM, Kevin Smith <[email protected]> wrote: > >> >> >>> If we can come to an agreement on the existential operator for member >>> expressions, we would also be setting a precedent for other features >>> of the same family. For example, existential call expressions: `fn?()` >>> which would conditionally invoke `fn`. >>> >> >> In the meeting notes you linked to, Waldemar (WH) noted that some of >> these variations may have grammar issues. >> >> Although not strictly ambiguous with conditional expressions, `fn ? ()` >> would require the use of YACG (yet another cover grammar). >> >> Also, what about computed property names? For example: `obj ? >> [Symbol.iterator]`. I'm not sure that even YACG will help here. >> >> (Thanks for compiling the list of previous threads BTW). >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
