Specifying template strings

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Jul 10 15:06:36 PDT 2014


On Jul 10, 2014, at 1:43 PM, Jason Orendorff wrote:

> On Thu, Jul 10, 2014 at 10:37 AM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> Most of this is already in Note 2 of 12.2.9.22 with somewhat different wording.  (but the section reference in Rev25 to tagged templates is wrong).
> 
> Oh, yes. I actually looked at that recently, because the person
> implementing template strings for SpiderMonkey (Lakshmi Narasimha
> Guptha Munuhur Rajagopal) was confused by the spec as written, and I
> had to clarify for him.
> 
> Step 1 did not strike me as totally clear. NOTE 2 is the only reason I
> didn't bring a question to this list. :)

Looking at it just now,  Step 1 really only makes sense relative to understanding step 12. Putting in an explicit forward reference. 
> 
> This particular bit of spec is just specially weird. The language in
> step 1 is (necessarily) unique. It might be helpful to rewrite that
> step with even more explicit language, so that a note is less
> necessary to understanding. I guess the issue for me was that I had
> never thought of ES grammar productions as having identity before. Is
> there a place in the spec that explicitly says that each time code is
> parsed, a new tree of constructions is generated, distinct from other
> parses of the same code? If so, a link from here to there would help.

that's why it says "source code corresponding to TemplateLiteral".  It's the actual source code that we are identifying as a call site.  Except for explicit cover grammars each source code unit is only parsed once. (except for eval, and we'll probably have to say something about module loaders in this regard...) but that is mostly implicit in the spec. Chapter 5 talks a bit about correspondences between source code and corresponding grammar productions.  the spec. isn't very explicit about parse trees and/or ASTs.  This all could be...don't know how much can be done for ES6.

BTW, eval brings up an interesting question:

let t = "tag`hello, ${world}.`";
eval(t);
eval(t);

or
new Function(t)();
new Function(t)();

Do each of these pairs compile into different call sites or are they the same call site? I'm inclined to say different.  That each parse of an input string whither via eval, the function constructor, or module/script loading represent a logically distinct input into the ES environment.

> 
>>> There are so many algorithms with no explanatory text at all that it
>>> seems like it must be a deliberate style choice. Is it?
>> 
>> Yes.  The experience with Ecma-262 (and other standards)  is that redundant descriptive text (whether marked as normative or informative) is frequently misleading. And any redundancy introduces the possibility of internal specification inconsistency.
> 
> OK. I respect these concerns.
> 
> This specific decision is really hard on implementers, who I think are
> the spec's target audience (?). Please consider mitigations for the
> observed problems other than defaulting to no explanation for
> anything.

It would be really nice to have a guide to reading the ES6 spec. specifically target for implementors. I gave a talk something like that for ES5 when I was at Microsoft.  But finding the time to write that is going to be hard (at least for me) until ES6 is done. Any volunteers out there?  I'd be happy to work with somebody on this...

Bug reports are a good way to let me know that something is confusing and needs a note or something.  Even better is proposing what it should say, like you did for this. 

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140710/b568a6bf/attachment-0001.html>


More information about the es-discuss mailing list