Open UberKluger opened 4 years ago
jmdyck
commented
4 years ago I think the suggested moves make sense, but if #1950 is likely to happen, there's probably no point.
Some of the suggested notes might still be useful in a post-1950 spec, but we might as well wait until that happens (or doesn't).
jmdyck
commented
3 years ago To make the suggestions easier to understand after the merge of PR #2271, here's the original post with updated section numbers, and also links:
Sections 13.3.8.1 and 13.2.9.3 relate to conversion of a template literal to an argument list (using ArgumentListEvaluation S13.3.8.1 and GetTemplateObject S13.2.9.3). However, section 13.2 describes the evaluation of primary expressions. The evaluation of a template literal as a primary expression does not involve conversion to an argument list, only the evaluation to a String as described in S13.2.9.4 and S13.2.9.5.
Section 13.3.11 describes the evaluation of a tagged template where conversion of the template literal to an argument list is central. However, the description for the runtime evaluation of a tagged template does not directly reference ArgumentListEvaluation but only EvaluateCall. The description for EvaluateCall (S13.3.6.2) makes reference to ArgumentListEvaluation but makes no distinction between arguments derived from Arguments (S13.3.8) and those derived from TemplateLiteral (currently S13.3.8.1). (Yes, I know that the resulting argument list has no such distinction but it would help when tracing the operation.)
Moving the nominated sections and adding a note (in S13.3.11.1) that the evaluation of a tagged template by EvaluateCall uses ArgumentListEvaluation as described in (new) S13.3.11.2 and S13.3.11.3 would eliminate the need to go searching for the appropriate description when investigating the operation of this feature (at least it would have for me). Further, the description for EvaluateCall could be expanded to note the difference between invoking ArgumentListEvaluation for an Arguments and for a TemplateLiteral (with appropriate hyper-links).
Alternatively, since the template literal of a tagged template is effectively the argument list of a function call (albeit with some manipulation), the template specific description of ArgumentListEvaluation (S13.3.8.1) (and GetTemplateObject in S13.2.9.3) could be merged into section 13.3.8 thereby having both descriptions of ArgumentListEvaluation (and dependencies) in one section.
(BTW, upon reflection I can see that the note already included in S13.3.11 provides some clues as to the location of the relevant information but this was not clear before I knew where to look. Using the runtime evaluation chain leads from tagged template to EvaluateCall and then the non-specific reference to ArgumentListEvaluation which is not mentioned in the S13.3.11 note.)
I think PR 2271 mostly resolves this issue, in that the consolidation of ArgumentListEvaluation is part of what the "Alternatively" paragraph suggested. But that para also suggests moving GetTemplateObject into 13.3.8. Moreover, this issue has suggestions re notes. @UberKluger should perhaps review the current spec and either revise or close this issue.
Sections 12.2.9.3 and 12.2.9.4 relate to conversion of a template literal to an argument list (using ArgumentListEvaluation S12.2.9.3 and GetTemplateObject S12.2.9.4). However, section 12.2 describes the evaluation of primary expressions. The evaluation of a template literal as a primary expression does not involve conversion to an argument list, only the evaluation to a String as described in S12.2.9.5 and S12.2.9.6.
Section 12.3.11 describes the evaluation of a tagged template where conversion of the template literal to an argument list is central. However, the description for the runtime evaluation of a tagged template does not directly reference ArgumentListEvaluation but only EvaluateCall. The description for EvaluateCall (S12.3.6.2) makes reference to ArgumentListEvaluation but makes no distinction between arguments derived from Arguments (S12.3.8) and those derived from TemplateLiteral (currently S12.2.9.3). (Yes, I know that the resulting argument list has no such distinction but it would help when tracing the operation.)
Moving the nominated sections and adding a note (in S12.3.11.1) that the evaluation of a tagged template by EvaluateCall uses ArgumentListEvaluation as described in (new) S12.3.11.2 and S12.3.11.3 would eliminate the need to go searching for the appropriate description when investigating the operation of this feature (at least it would have for me). Further, the description for EvaluateCall could be expanded to note the difference between invoking ArgumentListEvaluation for an Arguments and for a TemplateLiteral (with appropriate hyper-links).
Alternatively, since the template literal of a tagged template is effectively the argument list of a function call (albeit with some manipulation), the template specific description of ArgumentListEvaluation (S12.2.9.3) (and GetTemplateObject in S12.2.9.4) could be merged into section 12.3.8 thereby having both descriptions of ArgumentListEvaluation (and dependencies) in one section.
(BTW, upon reflection I can see that the note already included in S12.3.11 provides some clues as to the location of the relevant information but this was not clear before I knew where to look. Using the runtime evaluation chain leads from tagged template to EvaluateCall and then the non-specific reference to ArgumentListEvaluation which is not mentioned in the S12.3.11 note.)