Quasi literal function call syntax

[Rick Waldron]

Heads up! Quasis are no longer called Quasi, the new name is String
Templates.

On Sun, Sep 23, 2012 at 11:59 AM, Matthew Robb <matthewwrobb at gmail.com>wrote:

> BUT, just putting this out there, I do think it would be great to have a
> Quasi global constructor that could have some static members hanging off of
> it, possibly including a potential parse method, but also some of the more
> likely bundled output:
>
> Quasi.escape`my ${unsafe} stuff`


>
> On Sun, Sep 23, 2012 at 11:56 AM, Matthew Robb <matthewwrobb at gmail.com>wrote:
>
>> I had the same initial reaction, however, working with desugaring both
>> quasi-literals and their tagged brothers has brought me to a new
>> appreciation for their elegance. Actually using the tagged quasis has a
>> powerful feel to it and it can help expose people to what's actually
>> happening under the hood. It's not a simple shorthand for concatenation and
>> without seeing that most people will miss the potential I think.
>>
>> On Sun, Sep 23, 2012 at 11:53 AM, Aron Homberg <info at aron-homberg.de>wrote:
>>
>>> 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) {
>>>     // ...
>>> }
>>>
>>> correct?
>>>
>>> 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 nice.
>>>
>>> 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 text.');
>>>
>>> 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,
>>> Aron
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> - Matthew Robb
>>
>
>
>
> --
> - Matthew Robb
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120923/1749ecb1/attachment.html>