Quasi-literals for templating?

Brendan Eich brendan at mozilla.com
Wed Jun 15 08:06:44 PDT 2011


On Jun 15, 2011, at 2:43 AM, Axel Rauschmayer wrote:

>>> Has that been considered as a use case (e.g. after a compilation/generation step?). But it doesn’t seem like identifier names are accessible to quasi handlers, which would make this difficult.
>> 
>> If the consensus ends up being that more than simple identifiers are
>> allowed in substitutions, then I don't know what it would mean for
>> identifiers to be available.
> 
> I didn’t find in the spec how the "substitutions" parameter (that quasi handlers get) is structured, thus I assumed that it was an array of values.

That's right, it is the trailing arguments after the "callSiteId". A rest parameter can be used to capture these as an array. The examples probably should use rest params instead of |arguments|.

The point is that the callSiteId captures all the literal/constant/loop-invariant parts of the quasi, both raw and cooked ("expandedLP"). The remaining quasi handler parameters are the necessarily variable, evaluated-at-runtime substitution expression results.

The proposal needs to say this a bit more explicitly, and up front.


> It could be an array of (key,value) pairs, then going beyond simple identifiers would be easy.

No, the proposal desugars, so whatever is after the $ and possibly in {} is an expression evaluated without change, and its result value goes is passed to the quasi handler.

The reason for grammatical restrictions on the substitutions, to be identifiers or perhaps dotted identifier chains (a restricted MemberExpression) is so that the spec and users' models of it are simple and we don't end up with hellish lexical rules for finding that closing }.


> I am assuming that order matters, if not, then there is something fundamental about handler parameters that I haven’t understood.

Yes, order matters.

/be


More information about the es-discuss mailing list