String identity template tag

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

String identity template tag

Isiah Meadows-2
It'd be *way* easier to construct simple template tags if there was a
built-in identity tag, like this:

```js
String.identity = (template, ...args) => {
    let str = ""
    for (let i = 0; i < args.length; i++) {
        str += template[i] + String(args[i])
    }
    return str + template[template.length - 1]
}
```

This would also provide some language consistency in that tag-less
templates are evaluated as if they were tagged with the internal
`String.identity`.

The usefulness of this is for simple utility template tags, like:

- `` debug`Value: ${value}` ``, where `value` is auto-inspected.
- `` trust`html` ``, which returns a raw HTML virtual DOM node.
- `` escape`trusted ${untrusted}` ``, which escapes template variables

Here's how `debug` and `trust` above would be implemented:

```js
// `debug` - logs a message with inspected values to the console
const debug = (template, ...args) =>
    String.identity(template, ...args.map(arg => util.inspect(arg)))

// `trust` - returns a Mithril `m.trust` vnode
// https://mithril.js.org/trust.html
const trust = (...args) =>
    m.trust(String.identity(...args))

// `escape` - logs a message with inspected values to the console
const escape = (template, ...args) =>
    String.identity(template, ...args.map(escapeString))
```

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

T.J. Crowder-2
On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
<[hidden email]> wrote:
>
> It'd be *way* easier to construct simple template tags if there was a
> built-in identity tag

Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).

I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
I'm not married to `identity`, and I agree the name is probably not
ideal. I'm more concerned about functionality, though.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
<[hidden email]> wrote:

>
> On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
> <[hidden email]> wrote:
> >
> > It'd be *way* easier to construct simple template tags if there was a
> > built-in identity tag
>
> Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>
> I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>
> -- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Michael Luder-Rosefield
Why not String.tag or .tagged?

While we're at it, is there any good reason not to have something like this:

```
String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
// apologies for pseudo-semi-functional code
// having keys be an object allows template to be filled by key name rather than just index
```
This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.


On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
I'm not married to `identity`, and I agree the name is probably not
ideal. I'm more concerned about functionality, though.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
<[hidden email]> wrote:
>
> On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
> <[hidden email]> wrote:
> >
> > It'd be *way* easier to construct simple template tags if there was a
> > built-in identity tag
>
> Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>
> I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>
> -- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:

>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

T.J. Crowder-2
On Wed, Dec 12, 2018 at 6:59 AM Isiah Meadows
<[hidden email]> wrote:
>
> Those names a little too generic for my liking here. What about
> `String.expand(template, ...params)`?

I like it.

> And also, let's not try to bake a traditional template engine into the
> JS spec - syntactic template strings already work well enough.

Agreed.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

David Rajchenbach-Teller-2
Yeah, `String.expand` is the nicest one I've seen so far.

On 12/12/2018 10:05, T.J. Crowder wrote:

> On Wed, Dec 12, 2018 at 6:59 AM Isiah Meadows
> <[hidden email]> wrote:
>>
>> Those names a little too generic for my liking here. What about
>> `String.expand(template, ...params)`?
>
> I like it.
>
>> And also, let's not try to bake a traditional template engine into the
>> JS spec - syntactic template strings already work well enough.
>
> Agreed.
>
> -- T.J. Crowder
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Mark Miller-2
In reply to this post by Isiah Meadows-2
What is the intuition behind "expand"? What is being expanded, and what is it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:
>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
The template is being expanded as if the template itself is untagged. The point of this is a template tag that just does the default untagged behavior of coercing all expressions to strings and joining the whole thing together.
On Wed, Dec 12, 2018 at 20:21 Mark Miller <[hidden email]> wrote:
What is the intuition behind "expand"? What is being expanded, and what is it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:
>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Mark Miller-2

On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows <[hidden email]> wrote:
The template is being expanded as if the template itself is untagged.

Does this mean that you describe what tagged templates do, or what untagged templates do, as "expanding" something? If so, what is the intuition behind that prior usage of "expand"?

 
The point of this is a template tag that just does the default untagged behavior of coercing all expressions to strings and joining the whole thing together.

I certainly agree that the name should suggest equivalence to the default untagged behavior. I just never would have thought to describe that behavior as "expanding" something. What is it expanded into?

 
On Wed, Dec 12, 2018 at 20:21 Mark Miller <[hidden email]> wrote:
What is the intuition behind "expand"? What is being expanded, and what is it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:
>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM


--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
I mean equivalence to untagged behavior, if that helps.

FWIW, as stated previously, I'm not married to the name.
On Wed, Dec 12, 2018 at 20:31 Mark Miller <[hidden email]> wrote:

On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows <[hidden email]> wrote:
The template is being expanded as if the template itself is untagged.

Does this mean that you describe what tagged templates do, or what untagged templates do, as "expanding" something? If so, what is the intuition behind that prior usage of "expand"?

 
The point of this is a template tag that just does the default untagged behavior of coercing all expressions to strings and joining the whole thing together.

I certainly agree that the name should suggest equivalence to the default untagged behavior. I just never would have thought to describe that behavior as "expanding" something. What is it expanded into?

 
On Wed, Dec 12, 2018 at 20:21 Mark Miller <[hidden email]> wrote:
What is the intuition behind "expand"? What is being expanded, and what is it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:
>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM


--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Andrea Giammarchi-2
I agree with Mark, and I wonder why `String.tag` is not the obvious choice here, since every interpolation is also coerced as String

On Thu, Dec 13, 2018 at 9:34 AM Isiah Meadows <[hidden email]> wrote:
I mean equivalence to untagged behavior, if that helps.

FWIW, as stated previously, I'm not married to the name.
On Wed, Dec 12, 2018 at 20:31 Mark Miller <[hidden email]> wrote:

On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows <[hidden email]> wrote:
The template is being expanded as if the template itself is untagged.

Does this mean that you describe what tagged templates do, or what untagged templates do, as "expanding" something? If so, what is the intuition behind that prior usage of "expand"?

 
The point of this is a template tag that just does the default untagged behavior of coercing all expressions to strings and joining the whole thing together.

I certainly agree that the name should suggest equivalence to the default untagged behavior. I just never would have thought to describe that behavior as "expanding" something. What is it expanded into?

 
On Wed, Dec 12, 2018 at 20:21 Mark Miller <[hidden email]> wrote:
What is the intuition behind "expand"? What is being expanded, and what is it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
Those names a little too generic for my liking here. What about
`String.expand(template, ...params)`?

And also, let's not try to bake a traditional template engine into the
JS spec - syntactic template strings already work well enough.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
<[hidden email]> wrote:
>
> Why not String.tag or .tagged?
>
> While we're at it, is there any good reason not to have something like this:
>
> ```
> String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
> // apologies for pseudo-semi-functional code
> // having keys be an object allows template to be filled by key name rather than just index
> ```
> This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>
>
> On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>
>> I'm not married to `identity`, and I agree the name is probably not
>> ideal. I'm more concerned about functionality, though.
>>
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>> www.isiahmeadows.com
>>
>> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>> <[hidden email]> wrote:
>> >
>> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>> > <[hidden email]> wrote:
>> > >
>> > > It'd be *way* easier to construct simple template tags if there was a
>> > > built-in identity tag
>> >
>> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>> >
>> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>> >
>> > -- T.J. Crowder
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM


--
  Cheers,
  --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Claude Pache
Random suggestions:

* `String.cooked`, which pairs well with already existing `String.raw`
* `String.vanilla`
* `String.plain`
* `null`, i.e., using a null (or undefined) value as tag before a template literal is equivalent to using no tag. (Con: not polyfillable)

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
In reply to this post by Andrea Giammarchi-2
To me, `String.tag` seems more descriptive of the syntactic location
(the template *tag*) than the semantics it carries.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Thu, Dec 13, 2018 at 2:53 AM Andrea Giammarchi
<[hidden email]> wrote:

>
> I agree with Mark, and I wonder why `String.tag` is not the obvious choice here, since every interpolation is also coerced as String
>
> On Thu, Dec 13, 2018 at 9:34 AM Isiah Meadows <[hidden email]> wrote:
>>
>> I mean equivalence to untagged behavior, if that helps.
>>
>> FWIW, as stated previously, I'm not married to the name.
>> On Wed, Dec 12, 2018 at 20:31 Mark Miller <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows <[hidden email]> wrote:
>>>>
>>>> The template is being expanded as if the template itself is untagged.
>>>
>>>
>>> Does this mean that you describe what tagged templates do, or what untagged templates do, as "expanding" something? If so, what is the intuition behind that prior usage of "expand"?
>>>
>>>
>>>>
>>>> The point of this is a template tag that just does the default untagged behavior of coercing all expressions to strings and joining the whole thing together.
>>>
>>>
>>> I certainly agree that the name should suggest equivalence to the default untagged behavior. I just never would have thought to describe that behavior as "expanding" something. What is it expanded into?
>>>
>>>
>>>>
>>>> On Wed, Dec 12, 2018 at 20:21 Mark Miller <[hidden email]> wrote:
>>>>>
>>>>> What is the intuition behind "expand"? What is being expanded, and what is it expanding into?
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows <[hidden email]> wrote:
>>>>>>
>>>>>> Those names a little too generic for my liking here. What about
>>>>>> `String.expand(template, ...params)`?
>>>>>>
>>>>>> And also, let's not try to bake a traditional template engine into the
>>>>>> JS spec - syntactic template strings already work well enough.
>>>>>>
>>>>>> -----
>>>>>>
>>>>>> Isiah Meadows
>>>>>> [hidden email]
>>>>>> www.isiahmeadows.com
>>>>>>
>>>>>> On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
>>>>>> <[hidden email]> wrote:
>>>>>> >
>>>>>> > Why not String.tag or .tagged?
>>>>>> >
>>>>>> > While we're at it, is there any good reason not to have something like this:
>>>>>> >
>>>>>> > ```
>>>>>> > String.template = (template : String, taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object) => taggerFn(template, (keys is Array) ? ...keys : keys)
>>>>>> > // apologies for pseudo-semi-functional code
>>>>>> > // having keys be an object allows template to be filled by key name rather than just index
>>>>>> > ```
>>>>>> > This would make templates closer to the traditional usage, where the template comes first and is later passed values to be filled in with. Having the taggerFn as an argument allows for things like Isiah's escape-then-apply tagging examples.
>>>>>> >
>>>>>> >
>>>>>> > On Wed, 12 Dec 2018 at 12:51 Isiah Meadows <[hidden email]> wrote:
>>>>>> >>
>>>>>> >> I'm not married to `identity`, and I agree the name is probably not
>>>>>> >> ideal. I'm more concerned about functionality, though.
>>>>>> >>
>>>>>> >> -----
>>>>>> >>
>>>>>> >> Isiah Meadows
>>>>>> >> [hidden email]
>>>>>> >> www.isiahmeadows.com
>>>>>> >>
>>>>>> >> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>>>>>> >> <[hidden email]> wrote:
>>>>>> >> >
>>>>>> >> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>>>>>> >> > <[hidden email]> wrote:
>>>>>> >> > >
>>>>>> >> > > It'd be *way* easier to construct simple template tags if there was a
>>>>>> >> > > built-in identity tag
>>>>>> >> >
>>>>>> >> > Wholeheartedly agree, a couple of months ago I considered posting something very similar, both for utility reasons and in hopes that it would be an optimization target (being a standard operation).
>>>>>> >> >
>>>>>> >> > I find the name `identity` unilluminating, though, partially because it's not quite the same meaning as the usual "identity" function (`function identity(x) { return x; }`), though it's close. `assemble`?
>>>>>> >> >
>>>>>> >> > -- T.J. Crowder
>>>>>> >> _______________________________________________
>>>>>> >> es-discuss mailing list
>>>>>> >> [hidden email]
>>>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> [hidden email]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>   Cheers,
>>>>>   --MarkM
>>>
>>>
>>>
>>> --
>>>   Cheers,
>>>   --MarkM
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Isiah Meadows-2
In reply to this post by Claude Pache
I like `String.cooked`, especially considering `String.raw` already
basically does this, just using `template.raw` instead of `template`.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Thu, Dec 13, 2018 at 3:23 AM Claude Pache <[hidden email]> wrote:

>
> Random suggestions:
>
> * `String.cooked`, which pairs well with already existing `String.raw`
> * `String.vanilla`
> * `String.plain`
> * `null`, i.e., using a null (or undefined) value as tag before a template literal is equivalent to using no tag. (Con: not polyfillable)
>
> —Claude
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

T.J. Crowder-2
In general, I think method names should be verbs in the imperative
tense (okay, *mood* if you like linguistic distinctions), which would
argue for `cook` rather than `cooked`. (`String.raw` is an unfortunate
exception to this rule, which has largely been used throughout the
standard library. Another exception is `Reflect.ownKeys`. There are
probably others as well, but they are exceptions, not the norm.)

I like `cook`. It's `assemble`, but with more flavor.

The good news here, though, is we're all talking about a name, which
suggests that in general people like the taste of the idea. There
don't seem to be concerns that it's half-baked.

(I'll stop now.)

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Andrea Giammarchi-2
FWIW, I've used same logic for something like a no-op for i18n`strings` [1] so, considering it has easily use cases with mapped interpolations too, I think it's more than natural to have that in core.

It's also backward compatible/polyfillable so this is kinda a no-brainer, name a part, of course.

On Thu, Dec 13, 2018 at 6:15 PM T.J. Crowder <[hidden email]> wrote:
In general, I think method names should be verbs in the imperative
tense (okay, *mood* if you like linguistic distinctions), which would
argue for `cook` rather than `cooked`. (`String.raw` is an unfortunate
exception to this rule, which has largely been used throughout the
standard library. Another exception is `Reflect.ownKeys`. There are
probably others as well, but they are exceptions, not the norm.)

I like `cook`. It's `assemble`, but with more flavor.

The good news here, though, is we're all talking about a name, which
suggests that in general people like the taste of the idea. There
don't seem to be concerns that it's half-baked.

(I'll stop now.)

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

kai zhu
In reply to this post by T.J. Crowder-2
why not copy python's list-zip static-function (https://www.programiz.com/python-programming/methods/built-in/zip)?

i'm also against the spread-operator signature.

```javascript
// python-inspired list-zip static-function
// List.zip(list1, list2)
str = List.zip(
    templateList,
    argList
// slice-out argList-padded undefined
).slice(0, -1).join("\n");



// List.zip only zips up to length of list1
// padding with undefined

List.zip([1, 2, 3], ["one", "two"]);
// [1, "one", 2, "two", 3, undefined]

List.zip([1, 2], ["one", "two", "three"]);
// [1, "one", 2, "two"]
```


On Thu, Dec 13, 2018, 04:15 T.J. Crowder <[hidden email]> wrote:
In general, I think method names should be verbs in the imperative
tense (okay, *mood* if you like linguistic distinctions), which would
argue for `cook` rather than `cooked`. (`String.raw` is an unfortunate
exception to this rule, which has largely been used throughout the
standard library. Another exception is `Reflect.ownKeys`. There are
probably others as well, but they are exceptions, not the norm.)

I like `cook`. It's `assemble`, but with more flavor.

The good news here, though, is we're all talking about a name, which
suggests that in general people like the taste of the idea. There
don't seem to be concerns that it's half-baked.

(I'll stop now.)

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

T.J. Crowder-2
On Thu, Dec 13, 2018 at 1:03 PM kai zhu
> 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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: String identity template tag

Mark Miller-2
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 <[hidden email]> wrote:
On Thu, Dec 13, 2018 at 1:03 PM kai zhu
> 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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12