Quasi literal function call syntax

Aron Homberg info at aron-homberg.de
Sun Sep 23 08:53:12 PDT 2012

Hi all,

currently I'm reading the recent draft spec of edition 6 from 7-8-12 and I
was a bit suprised about the special function call syntax in relation to
quasi literals e.g.:

    safehtml`Some tpl text ${variableToPlaceHere} more text.`

which will result in a call like:

function safehtml(/*Array*/ tplParts, ...tplValues) {
    // ...


I think this special function call syntax has a relative high
"wtf?!"-factor ;-) (like <| had :)

Because this special use case mostly targets to library developers (I
guess, because the most app developers will just use var tpl = `abc ${var1}
...` etc.)
I think a more straight forward approach without a special grammar would be

I just wanted to know what you think about the following approach using a
new built-in function, which acts like parseFloat() or parseInt() - just
for quasi literals:

    var parsedQuasi = parseQuasi('Some tpl text ${variableToPlaceHere} more

The result variable would contain e.g. an array or an object (plain or of
prototype Quasi with methods like getParts(), getValues()) which contains
the parts and the assigned values.

Simply it would be:

    safehtml(parseQuasi('Some tpl text ${variableToPlaceHere} more text.'));

Instead of:

    safehtml`Some tpl text ${variableToPlaceHere} more text.`

This would:
- (pro) reduce the complexity of the parsing grammar
- (pro) result in a more straight forward function call syntax without
special cases (magic)
- (pro) follow the built-in functions "standard" for preprocessing special
values (parseNumber(), parseInt() functions)
- (con) but it also would break the `` syntax - because in case of
parseQuasi()-calling the ' or " would be used

What do you think?

Thanks and regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120923/b8bc76a6/attachment.html>

More information about the es-discuss mailing list