String identity template tag

[Mark Miller]

I like String.cooked best. While I agree that method names should generally
be verbs, I suggest this rule should *not* be used for template literal tag
names. Rather, the tag name should generally be descriptive, naming the
language being parsed or the way it is interpreted or what the value of the
template literal expression will be. Most often, it should name the
language being parsed. By contrast with "raw", "cooked" is the right name
for this language --- the language of escaped characters within a normal
string literal.

Historical note: Template literals derive from E's quasi-literals
http://www.erights.org/elang/grammar/quasi-overview.html . Template literal
tags are E's quasi-parsers. We usually named quasi-parsers according to the
language they were quasi-parsing. This is natural for most JS uses. See
https://github.com/erights/quasiParserGenerator



On Thu, Dec 13, 2018 at 5:42 AM T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> On Thu, Dec 13, 2018 at 1:03 PM kai zhu
> <kaizhu256 at gmail.com> wrote:
> > why not copy python's list-zip static-function
>
> The result isn't a string, it's an array you'd then have to join with
> `.join("")`. Not that `zip` isn't a useful function *too*... (At least,
> presumably it is, it shows up in libs a lot. I don't recall having had to
> do it outside a tag function.)
>
> > i'm also against the spread-operator signature.
>
> Good point to raise. (FWIW: It's "rest," not "spread;" and it's not an
> operator.)
>
> An argument in favor of using a rest parameter is it aligns with
> `String.raw`. (It also makes `cook` a valid tag function, though a
> pointless one to use in that way as the result is what you'd get from an
> untagged template.)
>
> An argument against using a rest parameter (taking an array instead) is
> that, to my mind anyway, the primary use case for this function is as a
> tool within other general-purpose tag functions (like Isiah's `debug` and
> `trust` examples). In a general-purpose tag function, since you don't know
> how many substitution values you're going to get, you're likely to have
> used a rest parameter, meaning you already have an array. Passing the array
> directly is more efficient, surely, than spreading it and having `cook`
> gather it up into a rest parameter. (That said, if engines don't already
> aggressively optimize calls using spread with an array that has the default
> iterator to functions using a perfectly-matching rest parameter list,
> presumably they will at some point, or investigations have proved it's not
> worth the trouble.)
>
> I'm not bothered either way.
>
> -- T.J. Crowder
>


-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181213/b8b75f28/attachment-0001.html>