Specifying template strings
jason.orendorff at gmail.com
Thu Jul 10 13:43:13 PDT 2014
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 18.104.22.168 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. :)
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.
>> 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
> Prior editions had more such descriptive text and there have been several situations where a buggy or incompatible implementation of a feature was traced back to somebody misinterpreting a vague descriptive statement rather than following the details of the an algorithm.
Thanks for clarifying this. I didn't know such things had ever happened.
Certainly there have often been implementation bugs due to
underspecification. I'm very grateful for the increased precision in
the spec under your editorship.
>> Speaking as a user of the spec, a little prose can be a big help. In
>> regions of the spec that don't have any, I often feel like I'm reading
>> uncommented assembly code, reverse-engineering all higher-level
> I agree. But good informative notes needs to clarify the normative text rather than just provide redundant and simplified alternative descriptions
I'll take whatever I can get.
More information about the es-discuss