quasi-literal strawman

Mike Samuel mikesamuel at gmail.com
Mon Apr 5 14:37:46 PDT 2010

2010/4/1 Ash Berlin <ash_js at firemirror.com>:
> On 29 Dec 2009, at 16:36, Mike Samuel wrote:
>> 2009/12/28 Waldemar Horwat <waldemar at google.com>:
>>> 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
.  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

== 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.

More information about the es-discuss mailing list