Discuss
  • Quasi literal function call syntax

Quasi literal function call syntax

# Aron Homberg (13 years ago)

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 , Aron

# Matthew Robb (13 years ago)

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.

# Matthew Robb (13 years ago)

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.escapemy ${unsafe} stuff

# Rick Waldron (13 years ago)

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

# Brendan Eich (13 years ago)

Rick Waldron wrote:

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

Isn't it "Template Strings"? :->

# Matthew Robb (13 years ago)

I'm very interested in this being clarified actually.

# Rick Waldron (13 years ago)

On Sunday, September 23, 2012 at 4:17 PM, Brendan Eich wrote:

Rick Waldron wrote:

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

Isn't it "Template Strings"? :->

TBH, I typed that first, went back to the July notes an saw Allen's original renaming proposal as "string templates", but you're right. Thankfully the ticket I file in July was correct as well ;)

# Matthew Robb (13 years ago)

Is there any harm in simply having a "Template" global constructor. Call the feature Templates. Is this being avoided due to things like C++ Templates? If not has there been any talk around providing any built in API's to support the desugaring? String.template(), String.interpolate().

# Aron Homberg (13 years ago)

2012/9/23 Matthew Robb <matthewwrobb at gmail.com>

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.escapemy ${unsafe} stuff

Sounds great.

Just an idea to extend your idea a little bit, combining with mine:

What if whatever ${test} foo would just construct an object of Quasi? The Quasi object prototype could look lile this:

// In ES harmony syntax :) Quasi.prototype = { toString() {...}, getParts() {...}, getValues() {...} }

etc. pp.

This would normally lead to an implicit string conversion where it's needed e.g. if you do something like that:

whatever.innerHTML = `foo {$bar}`;

And you can use the full power of Quasis when calling a function in standard way: safehtml(foo ${bar}) where the first argument would be an object representing the Quasi prototype + Quasi value initialized by the constructor.

Or you could construct a Quasi like this: new Quasi('foo ${bar}'); or Quasi('foo ${bar}')

This way Quasi's would be straight forward to use and can be implemented without any additional grammar magic.

What do you think?

Thanks and , Aron

# Aron Homberg (13 years ago)

Ahmn, yeah - missed the mails in between, to be precise:

Sounds great.

Just an idea to extend your idea a little bit, combining with mine:

What if whatever ${test} foo would just construct an object of Template? The Template object prototype could look lile this:

// In ES harmony syntax :) Template.prototype = {

toString() {...},
getParts() {...},
getValues() {...},
...

}

etc. pp.

This would normally lead to an implicit string conversion (toString()) where it's needed e.g. if you do something like that:

whatever.innerHTML = `foo {$bar}`;

And you can use the full power of Templates when calling a function in standard way: safehtml(foo ${bar}) where the first argument would be an object representing the Template prototype + Template value initialized by the constructor.

Or you could construct a Template like this: new Template('foo ${bar}'); or Template('foo ${bar}')

This way Template's would be straight forward to use and can be implemented without any additional grammar magic. It would also lead to a late/delayed binding / rendering of the template - if toString() is called, not when the Template object is created which may be useful for performance too.

What do you think?

Thanks and , Aron

# Aron Homberg (13 years ago)

...and, additionally: This would allow one to encode/decode Template's in JSON notation as string primitive.

2012/9/23 Aron Homberg <info at aron-homberg.de>