14.1.7 "Static Semantics: Formal Parameters"
defines a semantic routine named "Formal Parameters".
On the face of it, this routine does not appear to be mentioned anywhere else in the spec, either to define it further or to invoke it.
Or perhaps the space in the name is a typo, and it should be "FormalParameters". In that case, the only invocation would appear to be in B.3.3:
... an element of BoundNames of FormalParameters of /g/, ...
Is that the intent?
In any case, it seems to be a pointless routine, because you can achieve the same effect simply by using the /FormalParameters/ *non-terminal*.
fixed in rev31 editor's draft
It's not supposed to have the space in the name and B.3.3 is the only place it is needed. It was just easier to spec it this way rather than crafting the prose to days get the FormalParameters non-terminal from the RHS of g.
> It was just easier to spec it this way rather than crafting
> the prose to days get the FormalParameters non-terminal from the RHS of g.
I don't understand. Why can't B.3.3 just say:
... an element of BoundNames of the /FormalParameters/ of /g/, ...
? (No semantic routine, no prose-crafting.)
In Rev31
I still don't understand. Why can't B.3.3 simply use the /FormalParameters/ non-terminal? What does the 'FormalParameters' routine accomplish that the non-terminal wouldn't?
Is this related to the fact that 'g' is (described as) a function, not a FunctionDeclaration? If so, I can see that it doesn't work to use the /FormalParameters/ non-terminal, but by the same token, it also doesn't work to use the 'FormalParameters' routine (because it operates on syntax, just like the non-terminal). Either way, that'd be a bug.
On the other hand, it's unclear to me why 'g' *isn't* a FunctionDeclaration.
sold, particularly after the changes for Bug 3918
Since we know we are dealing with a FunctinoDeclaration we know that argumentsList is a FormalParameters
fixed in rev34 editor's draft
fixed in rev34