Specifying template strings

Jason Orendorff 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 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
>> structure.
> 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 mailing list