On Thu, Jul 10, 2014 at 10:37 AM, Allen Wirfs-Brock <[email protected]> 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. :) 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 anything. > 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. -j _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
