brendan at mozilla.com
Thu Dec 17 21:53:49 PST 2009
On Dec 17, 2009, at 8:00 PM, Kris Kowal wrote:
> I am also in favor of the quasi-literal type name not being mangled.
> I would, in fact, consider making the quasi-literal type any
> expression returning a function, even if this necessitates a
> parenthetical expression.
Necessitates for the simple identifier case? I don't see why,
> You might consider refining the escaping rules to resemble r"raw
> strings" as in Python. That would afford a greater degree of
> flexibility in escaping rules within the quasi-literal. The only
> difference is that in a raw string, only backslash before the same
> quote character as the enclosing quotes and a backslash are treated as
> escape characters and all others are preserved. Then, the
> quasi-literal function would be entirely in control of the meaning of
> other escaped characters.
See history in
or be condemned to repeat it. :-/
> There's also a trade-off between using back-ticks and plain
> double-quotes. Using back-ticks affords us an opportunity to have a
> "default" quasi-literal. On the other hand, I don't miss having to
> distinguish front and back ticks in Perl.
We are talking about quasi-quotations:
not string literals. We absolutely need new syntax, whether backquotes
or something else.
> Also, it might be
> undesirable to have to claim a variable name for the default case,
> unless your intention is that the default quasi-literal have a
> consistent behavior in any scope.
Could we define the common, printf-style case as the default?
> In one of my former language projects, I considered something similar
> for numbers, in suffix. For example: 3ce for "thrice" or 1mm for "one
> millimeter", where "ce" and "mm" were constructors in scope.
See the 1999-era JS2/ ES4 proposal:
More information about the es-discuss