On Jul 10, 2014, at 1:43 PM, Jason Orendorff wrote:
> On Thu, Jul 10, 2014 at 10:37 AM, Allen Wirfs-Brock
> <al...@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_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
