editorial: More reasons to change the grammatical parameter notation

[jmdyck]

In https://bugs.ecmascript.org/show_bug.cgi?id=2794, I proposed a small change to the notation of parameterized productions. In addition to the two reasons given there, I've recently thought of two more...

---

(3)
It makes bugs shallower.

Consider the production

    AssignmentProperty[Yield] : PropertyName `:` AssignmentElement[?Yield]

This seems unremarkable, but imagine if it were written:

    AssignmentProperty[Yield] : PropertyName[~Yield] `:` AssignmentElement[?Yield]

This makes it clear that PropertyName takes a Yield parameter, and yet it isn't inheriting the Yield setting from AssignmentProperty. My guess is that this is a bug (i.e., it should be [?Yield]), but even if it isn't, it's an anomaly that's worthy of explanation, and yet the question doesn't even arise with the current notation.

---

(4)
Ease of search.

For example, say you're interested in the parameter 'Return'.

If you want to see what effect the Return parameter has on the grammar, that's easy: just search for

    [+Return]

and you'll find it in the production for Statement, guarding the RHS for ReturnStatement. (You should also search for [~Return], but won't get any hits outside of examples.)

If you then want to see how a 'positive/present' setting for Return arises, that's not so easy. What you're looking for is a RHS (not LHS) nonterminal that has a subscript 'Return' (not '?Return'). For this, you need something like this (at least):

    \w\[(.*[^?])?Return.*[^:]$

which finds that FunctionStatementList derives StatementList with a 'positive' Return. (That regex has potential problems; if you wanted a more bullet-proof regex, it would be more complicated.)

Finally, if you want to see how a 'negative/absent' setting for Return arises, you almost can't even do it with a regex. Now you're looking for a RHS nonterminal that could take a Return parameter, but doesn't have one. (If you really wanted a regex, you'd first need a list of all the nonterminals that are defined to take a Return parameter, and then you'd have figure out how to write a pattern for a []-subscript that doesn't contain 'Return', which might not be easy depending on your regex language.)

With my proposal, you could find all of the above just by searching for

    [+~]Return

or, if you want a regex for each specific question:

    ^ *\[[+~]Return
    \w.*+Return
    \w.+~Return

[jmdyck]

@bterlson: If this sounds worthwhile, I'll prepare a pull request.

Originally, my proposal included changing N[?P] to N[P], but now I'm thinking I'll leave that part out. Keeping it in would increase the diff, and would also have the drawback that N[P]exists both before and after, but with different meanings, which might be confusing. (Keeping that substitution would also remove the ability to easily distinguish between LHS params and RHS pass-it-down params, though I'm not sure that makes much difference.)

[jmdyck]

@bterlson: If this sounds worthwhile, I'll prepare a pull request.

Originally, my proposal included changing N[?P] to N[P], but now I'm thinking I'll leave that part out. Keeping it in would increase the diff, and would also have the drawback that N[P]exists both before and after, but with different meanings, which might be confusing. (Keeping that substitution would also remove the ability to easily distinguish between LHS params and RHS pass-it-down params, though I'm not sure that makes much difference.)

[bterlson]

Let's wait until after March 1 (when I snap for ES2016). I don't want to change the notation now. Also we'll have to wait for grammarkdown to get support for this new syntax. On the surface I think this change is definitely good, though, so let's work toward getting all the necessary pieces updated sometime after March 1.

[bterlson]

Let's wait until after March 1 (when I snap for ES2016). I don't want to change the notation now. Also we'll have to wait for grammarkdown to get support for this new syntax. On the surface I think this change is definitely good, though, so let's work toward getting all the necessary pieces updated sometime after March 1.

[jmdyck]

Ah, I was hoping to get it in before the snap. But I guess I don't mind that much.

Also we'll have to wait for grammarkdown to get support for this new syntax.

Hm, yup, looks like it would complain about the new syntax.

[jmdyck]

Ah, I was hoping to get it in before the snap. But I guess I don't mind that much.

Also we'll have to wait for grammarkdown to get support for this new syntax.

Hm, yup, looks like it would complain about the new syntax.

[jmdyck]

PR #571 resolved this.

[jmdyck]

PR #571 resolved this.