2010/4/1 Ash Berlin <[email protected]>: > On 29 Dec 2009, at 16:36, Mike Samuel wrote: >> 2009/12/28 Waldemar Horwat <[email protected]>: >>> Mike Samuel wrote: >>>> >>>> That's the case right now, except that to escape a backtick one does >>>> $\` instead of \`. >>> >>> Having `\`` not do what I'd expect escaping to do truly surprised me. I >>> thought that this was just a bug in the grammar when I read the wiki page. >>> >>> The grammar has other bugs having to do with \ characters inside identifiers >>> and QuasiLiteralBodyParts. >> >> Are you referring to problems with something like like >> `$foo\u0061\u0020` >> where the Identifier production consumes both escape sequences but the >> second makes the identifier illegal? >> >> So an dentifier production that would limit the UnicodeEscapeSequence >> to matching classes (L*, Mc, Mb, Nd, Nl, Pc) and the single codepoints >> (_, $, ZWNJ, ZWJ). >> > > > Has there been any feedback on quasi-literal at any of the TC39 meeting(s)?
Ash, I presented on this at the meeting at Apple last week. You can find my slides at file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html . Those are the slides I presented with one exception -- I changed terminology from macros to quasis for reasons explaned below. Below are some of the major threads of discussion. I apologize if I've missed anything, and I can't remember who said what so I've just left everything unattributed. My responses are inline, and if anyone feels I've miscaptured the discussion, please respond inline. == It is not a macro system Quite right. An earlier version of the proposal was a macros proposal with JIT expansion, but the version I presented had the same goals but was not a macro system and I caused a lot of confusion by billing it as such. My apologies. == Arguments on performance are weak. It was pointed out that hand coded code often works better than macro expansion in practice. I agree though with the overall criticism that performance might not be the best selling point. I agree that a human who understands the compiler can do better than a macro expander. I disagree that this is the case for code under maintenance, and think that an idiom implemented as a macro can benefit greatly from a library author who understands the compiler, whereas in the non-macro case, the understanding of the compiler has to be in a much larger group of application authors. == The calling conventions are profligate with object creation and function calls. This is a valid criticism. The object creation, and function overhead can be entirely eliminated by inlining as described in the performance section. And we discussed a few ways of tweaking the calling conventions to avoid unnecessary object creation. == Proposed performance optimizations are untenable It was argued that the proposed performance optimizations are untenable because they require global analysis. This is false -- function inlining does not require global analysis. It was suggested that implementing these optimizations in browsers is difficult. I think this is false, but can only handwave. Pre-browser code optimization tools like Google's closure compiler can do inlining. Browsers have good reason not to do complicated optimizations when code is loaded, but could always use slow times to do similar rewriting optimization on hot JS files in the browser cache, so there is no need to accept a load time hit to benefit from inlining. == Grammar There was a missing production in the grammar and the grammar, especially escaping conventions, are going to require some time to hammer out. == Conclusion There was no consensus on the goals, proposed semantics, or grammar. As such it's premature to take it out of strawman status. Knowing what library developers want would help target discussions. I am going to canvas library developers so that I can present a more compelling proposal. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
