I’m curious to know more about the choice to introduce the Tagged syntactic production parameter. Existing parameterized productions are "shorthand" for 2 or more permutations that end up being meaningfully different somewhere down the line. All existing parameterized productions have in common the possibility of a descendent production that includes a member whose presence is conditional on whether that parameter is true or false. It seemed to me that the parameter notation (which is expressly called "shorthand" for these permutations, e.g. StatementList[Return] --> StatementList + StatementList_Return) was primarily for avoiding redundancy in the grammar specification for these kinds of cases.
This spec introduces a new parameter, but it does not introduce any productions predicated on that parameter. If I understand correctly, in this case it is only being used as a ‘carrier’ for metadata. If that’s the case, I would think that an alternative production, rather than parameterizing existing productions, would be more consistent with patterns established by the grammar.
i.e., something like this:
Other productions (except the lexical ones) would not be changed. The early errors etc would be predicated on the parent production (as many already are) instead of the parameter:
(etc). Unless I’m missing something here (a major possibility), this approach appears to get the same job done with fewer "touches" to the grammar + consistency with existing patterns.
It’s possible that using production parameters as in the current proposal is not really inconsistent with the original intent at all, and that it’s only a coincidence that currently they all lead to actual differences w/ regard to "set of possible valid token sequences".
I’m curious to know more about the choice to introduce the Tagged syntactic production parameter. Existing parameterized productions are "shorthand" for 2 or more permutations that end up being meaningfully different somewhere down the line. All existing parameterized productions have in common the possibility of a descendent production that includes a member whose presence is conditional on whether that parameter is true or false. It seemed to me that the parameter notation (which is expressly called "shorthand" for these permutations, e.g.
StatementList[Return]-->StatementList+StatementList_Return) was primarily for avoiding redundancy in the grammar specification for these kinds of cases.This spec introduces a new parameter, but it does not introduce any productions predicated on that parameter. If I understand correctly, in this case it is only being used as a ‘carrier’ for metadata. If that’s the case, I would think that an alternative production, rather than parameterizing existing productions, would be more consistent with patterns established by the grammar.
i.e., something like this:
Other productions (except the lexical ones) would not be changed. The early errors etc would be predicated on the parent production (as many already are) instead of the parameter:
(etc). Unless I’m missing something here (a major possibility), this approach appears to get the same job done with fewer "touches" to the grammar + consistency with existing patterns.
It’s possible that using production parameters as in the current proposal is not really inconsistent with the original intent at all, and that it’s only a coincidence that currently they all lead to actual differences w/ regard to "set of possible valid token sequences".
tldr: Why the parameterized approach?
[edit: typos in screenshot]