I think it is important not to provide the source text of the hole expressions to the quasi parser, for the same reason that we shouldn't provide the source text of the rest of the enclosing file. The output of the quasi parser should depend only on its legitimate inputs, which are the quasi strings and the values of the hole expressions, not their sources. If you provide the sources as well, then source to source transformations which should otherwise be correctness preserving would no longer be.
OTOH, we already have this problem with Function.prototype.toString. People do source to source transformations anyway. An earlier version of the quasis proposal implicitly thunkified the hold expressions, in which case Function.prototype.toString would have provided the holes anyway. So I don't suppose this is any worse. +1-1 = 0, i.e., I don't know if I'm in favor or not. On Fri, Mar 16, 2012 at 2:38 PM, Erik Arvidsson <[email protected]>wrote: > With the current proposal it is not possible to get the raw string, > including the place holders and everything. > > One possible use case: It is often common to want to have the textual > content of an expression to provide better output for unit testing. > Today, this is often done using global evals which requires global > variables everywhere. > > For example we could add an expressions property to the parameter. > > test`a $b c ${d} e` > > could be desugared t to something like: > > const unguessableCallSiteId1234 = Object.freeze({ > raw: Object.freeze(["a ", " c ", " e"]), > cooked: Object.freeze(["a ", " c ", " e"]), > expressions: Object.freeze(["$b", "${d}"]) > }); > > test(unguessableCallSiteId1234) > > -- > erik > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
