Kai, that there may be some tenuous connection to ux-workflow does not
support your sweeping claims. Also please stop with the personal attacks.
On Wed, Dec 19, 2018, 10:40 AM kai zhu *everything* using javascript is ultimately meant to solve a UX-workflow
> problem (including js-code in
*everything* using javascript is ultimately meant to solve a UX-workflow
problem (including js-code in servers, IoT, satellites, etc.). if you're
so caught up in low-level js library-code that you can't see how the piece
fits/integrates into that big-picture, then you should go back to
Could you bring that up in a different thread instead of driving this
off-topic? Also, please don't forget that a *very* significant chunk
of JS doesn't even run in a GUI environment (consider: servers, IoT,
satellites, etc.).
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On
> I could go with an iterator equivalent, but I'd like to defer that to
> the seemingly-planned "iterlib" thing that's been considered since
> before ES2015 was released.
i'm against iterator-based design-patterns and libraries, as they lack a clear
fit in most javascript solutions. the vast
Fair enough.
On Tue, Dec 18, 2018, 5:29 PM Isiah Meadows I could go with an iterator equivalent, but I'd like to defer that to
> the seemingly-planned "iterlib" thing that's been considered since
> before ES2015 was released. Something that works with arrays is good
> enough for now.
>
> BTW,
I could go with an iterator equivalent, but I'd like to defer that to
the seemingly-planned "iterlib" thing that's been considered since
before ES2015 was released. Something that works with arrays is good
enough for now.
BTW, your `ziperator` isn't really the same as my `Array.interpolate`
On Fri, Dec 14, 2018 at 2:26 PM Isiah Meadows
wrote:
> The main difference with that loop is that it's generalized to any number
> of arrays, not just two with the second array having length one less than
> the first. Otherwise, it'd look exactly the same. BTW, I like this route
>
The main difference with that loop is that it's generalized to any number
of arrays, not just two with the second array having length one less than
the first. Otherwise, it'd look exactly the same. BTW, I like this route
(`Array.interleave`) better since it doesn't have to result in just a
single
On Fri, Dec 14, 2018 at 12:51 PM Isiah Meadows
wrote:
> I'll point out Kai could be on to something, although I disagree `zip`
> would be the right abstraction. Maybe `Array.interleave(...arrays)`? You
> could do `Array.interleave(template, args).map(String).join("")` for
> similar effect, and
I'll point out Kai could be on to something, although I disagree `zip`
would be the right abstraction. Maybe `Array.interleave(...arrays)`? You
could do `Array.interleave(template, args).map(String).join("")` for
similar effect, and it'd be more generally useful.
The key here is that iteration
I'll admit that HTML escaping tag was probably a bad example. It was just
for show, nothing more, and obviously I wouldn't recommend it for
production.
On Thu, Dec 13, 2018 at 14:00 Mark Miller wrote:
> As a completely separate point, this way of escaping html is not context
> sensitive, and
On Thu, Dec 13, 2018 at 7:00 PM Mark Miller
wrote:
> As for the optional mapping function, there's nothing about that
> which is more relevant to cooked base strings than to raw base
> strings. We should be able to apply mapping functions to either,
> as well as to other base tags, in a similar
I think this is the right question. I agree that String.cook or whatever it
is called with typically be called explicitly rather than used
syntactically as a tag. However, putting the optional mapping function
aside for a moment, if the job it is doing is equivalent to that done by a
tag function,
> On Dec 13, 2018, at 10:37 AM, T.J. Crowder
> wrote:
>
> Fair enough, but the primary use of this function is *not* using it as a tag
> function, but rather as a normal function. It doesn't make sense to use it as
> a tag function, the result is the same as an untagged template. The only
On Thu, Dec 13, 2018 at 6:37 PM T.J. Crowder
wrote:
>
> But called normally, it's a useful helper, for instance in
> Isiah's `escape`...
Going through the process of the example for my message just now made me
think more about this function. Suppose it:
1. Accepted an array of substitutions
On Thu, Dec 13, 2018 at 5:56 PM Mark Miller
wrote:
>
> 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.
Fair enough, but the primary use of this function is *not* using it as a
tag
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
On Thu, Dec 13, 2018 at 1:03 PM kai zhu
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
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
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
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.
I like `String.cooked`, especially considering `String.raw` already
basically does this, just using `template.raw` instead of `template`.
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Thu, Dec 13, 2018 at 3:23 AM Claude Pache wrote:
>
> Random suggestions:
>
> *
To me, `String.tag` seems more descriptive of the syntactic location
(the template *tag*) than the semantics it carries.
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Thu, Dec 13, 2018 at 2:53 AM Andrea Giammarchi
wrote:
>
> I agree with Mark, and I wonder why
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
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 wrote:
>
> On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows
> wrote:
>
>> The template is being expanded as if the template itself is
On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows
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
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 wrote:
> What is the
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
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
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
> wrote:
>>
>> Those names a little too generic for my liking here. What about
>> `String.expand(template, ...params)`?
>
> I like it.
>
>> And
On Wed, Dec 12, 2018 at 6:59 AM Isiah Meadows
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
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
cont...@isiahmeadows.com
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
I'm not married to `identity`, and I agree the name is probably not
ideal. I'm more concerned about functionality, though.
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
wrote:
>
> On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>
On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
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
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 +
35 matches
Mail list logo
