Re: String.substitute
Template literals evaluate to simple strings, there is no way to pass a
reference to an un-evaluated template literal. The function method is the
only way. Programmatically
```
String.substitute({ year: 2015}, `Last year was ${year-1}`);
```
is identical to
```
var str = `Last year was ${year-1}`
String.substitute({ year: 2015}, str);
```
How would it ever know that it was supposed to skip evaluating the template
string first before calling the function?
On Wed, Aug 12, 2015 at 7:55 AM, Edwin Reynoso eor...@gmail.com wrote:
With `String.substitute()` you'd still be able to evaluate expressions,
it's kind of like changing scope, or passing an object to use for scoped
variables, which is not possible:
```JS
substitute({ year: 2015 }, 'Last year was year ${year-1}'); // Will throw
an error
```
You can't evaluate with your function
With `String.substitute()` you would be able to:
```JS
String.substitute({ year: 2015}, `Last year was ${year-1}`);
```
You also miss **New Lines** which is another thing template literals
solved, so yes you could just add `\n` but that's the point of why template
literals take care of that for you
On Wed, Aug 12, 2015 at 10:49 AM, Elie Rotenberg e...@rotenberg.io
wrote:
```
function substitute(obj, str) {
return str.replace(/\${([^}]*)}/g, (m, p) = obj[p]);
}
substitute({ year: 2015 }, 'This is year ${year}'); // === 'This is year
2015'
```
On Wed, Aug 12, 2015 at 4:42 PM, Nathaniel Higgins n...@nath.is wrote:
Am I being naive or could this just be written in user space?
Sent from my iPhone
On 12 Aug 2015, at 15:31, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
On Wed, Aug 12, 2015 at 10:19 AM, Claude Pache claude.pa...@gmail.com
wrote:
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way
to do it, since template literals are evaluated with the current scope,
also tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); //
Returns This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the
time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the
point is to have a template literal evaluate as a pass reference and not
right away.
You can't make your own function and pass in a template literal
that's not evaluated when passed as a reference, I'm not sure if anyone
will actually want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template
literal or of anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
let yearSentence = ({year:2015}=`This year is ${year}`)();
Enclosing the template string inside of a function is the way to go. Let's
call this one done.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
@logan that's an interesting thought, which is why I posted this for
discussion, Thinking of that, I'm kind of doubting most will like the
function to only be able to take the literal instead as a variable because
that's just messing with the way Javascript itself.
Could be possible to pass a string with instead of \`\`
```JS
String.substitute({year: 2015}, This year is ${year});
```
Which is giving javascript a way to allow writing a Template Literal
without evaluating by using instead of \`\`
@Tab atkin
Your still making a function yourself. You may ask what's wrong with that?
Well then I'd say what's the point of `ES6` having `Hi.includes(H)`
when we could of just did:
```JS
function includes(str, included) {
return str.indexOf(included) -1;
}
```
On Wed, Aug 12, 2015 at 11:08 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Aug 12, 2015 at 7:31 AM, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
let yearSentence = ({year:2015}=`This year is ${year}`)();
should work, or
let yearSentence = (year=`This year is ${year}`)(2015);
You don't *have* to save the templates in variables. You can just call
them immediately.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way to do
it, since template literals are evaluated with the current scope, also tried
with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns This
year is 2015
```
If you look closely, `String.substitute` is just the `with` statement
resurrected:
```js
with ({ year: 2015 }) {
`This year is ${year}`
}
```
At first glance, the `with` statement looked like a great idea, but in fact, it
makes static analysis difficult for both human and machines: In short: What do
you expect from:
```js
let shift = 1;
String.substitute( obj, `This year is ${year + shift}` );
```
when you don’t know a priori whether `obj` has a `year` property, and whether
it has a `shift` property?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
Could be possible to pass a string with instead of \`\`
At that point, you are implementing a templating language that happens to
match up syntactically with template literals. You'd also then be moving
parsing of the template to runtime instead of compile time, which will slow
things down. It would also only be possible to implement using `eval`.
You can certainly do that, but it doesn't seem like something that should
be included in the language. It's no different from using Handlebars or
Mustache at that point. The primary benefit of template literals is that
they have access to variables in-scope, which seems to be what you are
trying to avoid.
On Wed, Aug 12, 2015 at 8:19 AM, Edwin Reynoso eor...@gmail.com wrote:
@logan that's an interesting thought, which is why I posted this for
discussion, Thinking of that, I'm kind of doubting most will like the
function to only be able to take the literal instead as a variable because
that's just messing with the way Javascript itself.
Could be possible to pass a string with instead of \`\`
```JS
String.substitute({year: 2015}, This year is ${year});
```
Which is giving javascript a way to allow writing a Template Literal
without evaluating by using instead of \`\`
@Tab atkin
Your still making a function yourself. You may ask what's wrong with that?
Well then I'd say what's the point of `ES6` having `Hi.includes(H)`
when we could of just did:
```JS
function includes(str, included) {
return str.indexOf(included) -1;
}
```
On Wed, Aug 12, 2015 at 11:08 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Aug 12, 2015 at 7:31 AM, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
let yearSentence = ({year:2015}=`This year is ${year}`)();
should work, or
let yearSentence = (year=`This year is ${year}`)(2015);
You don't *have* to save the templates in variables. You can just call
them immediately.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
AFAIK, this wont work because what clearTimeout() is actually expecting is
the id returned by setTimeout().
El 12/8/2015 16:00, Nick Krempel ndkrem...@google.com escribió:
On 12 August 2015 at 02:56, Isiah Meadows isiahmead...@gmail.com wrote:
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(handler = {
onNotNeeded(() = clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethingAsync(err = {
if (err != null) return reject(err)
else return resolve();
});
}));
```
This doesn't work as the function passed to clearTimeout does not === the
function passed to setTimeout.
In fact, they're not even behaviorally equal as the function passed to
setTimeout is expecting no parameters and the function passed to
clearTimeout is expecting one parameter - i.e. this is not even correct in
lambda calculus.
A lambda-calculus-correct version could be:
```
setTimeout((x=(y=()=x(y(y)))(y=()=x(y(y(handler = {...}));
```
But this would still suffer from the object identity problem mentioned
above. A final JS-correct version could be:
```
setTimeout((x = {const y = () = x(y); return y;})(handler = {...}));
```
Nick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
```
function substitute(obj, str) {
return str.replace(/\${([^}]*)}/g, (m, p) = obj[p]);
}
substitute({ year: 2015 }, 'This is year ${year}'); // === 'This is year
2015'
```
On Wed, Aug 12, 2015 at 4:42 PM, Nathaniel Higgins n...@nath.is wrote:
Am I being naive or could this just be written in user space?
Sent from my iPhone
On 12 Aug 2015, at 15:31, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
On Wed, Aug 12, 2015 at 10:19 AM, Claude Pache claude.pa...@gmail.com
wrote:
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way to
do it, since template literals are evaluated with the current scope, also
tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns
This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the
time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the
point is to have a template literal evaluate as a pass reference and not
right away.
You can't make your own function and pass in a template literal that's
not evaluated when passed as a reference, I'm not sure if anyone will
actually want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template literal
or of anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
With `String.substitute()` you'd still be able to evaluate expressions,
it's kind of like changing scope, or passing an object to use for scoped
variables, which is not possible:
```JS
substitute({ year: 2015 }, 'Last year was year ${year-1}'); // Will throw
an error
```
You can't evaluate with your function
With `String.substitute()` you would be able to:
```JS
String.substitute({ year: 2015}, `Last year was ${year-1}`);
```
You also miss **New Lines** which is another thing template literals
solved, so yes you could just add `\n` but that's the point of why template
literals take care of that for you
On Wed, Aug 12, 2015 at 10:49 AM, Elie Rotenberg e...@rotenberg.io wrote:
```
function substitute(obj, str) {
return str.replace(/\${([^}]*)}/g, (m, p) = obj[p]);
}
substitute({ year: 2015 }, 'This is year ${year}'); // === 'This is year
2015'
```
On Wed, Aug 12, 2015 at 4:42 PM, Nathaniel Higgins n...@nath.is wrote:
Am I being naive or could this just be written in user space?
Sent from my iPhone
On 12 Aug 2015, at 15:31, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
On Wed, Aug 12, 2015 at 10:19 AM, Claude Pache claude.pa...@gmail.com
wrote:
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way
to do it, since template literals are evaluated with the current scope,
also tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); //
Returns This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the
time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the
point is to have a template literal evaluate as a pass reference and not
right away.
You can't make your own function and pass in a template literal that's
not evaluated when passed as a reference, I'm not sure if anyone will
actually want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template literal
or of anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is ${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
On Wed, Aug 12, 2015 at 10:19 AM, Claude Pache claude.pa...@gmail.com
wrote:
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way to
do it, since template literals are evaluated with the current scope, also
tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns
This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the point
is to have a template literal evaluate as a pass reference and not right
away.
You can't make your own function and pass in a template literal that's
not evaluated when passed as a reference, I'm not sure if anyone will
actually want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template literal
or of anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
Am I being naive or could this just be written in user space?
Sent from my iPhone
On 12 Aug 2015, at 15:31, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for each
type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is ${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
On Wed, Aug 12, 2015 at 10:19 AM, Claude Pache claude.pa...@gmail.com
wrote:
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way to do
it, since template literals are evaluated with the current scope, also
tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns
This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the point
is to have a template literal evaluate as a pass reference and not right
away.
You can't make your own function and pass in a template literal that's not
evaluated when passed as a reference, I'm not sure if anyone will actually
want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template literal or
of anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
This was assuming an API like addEventListener/removeEventListener, not the
standard DOM setTimeout/clearTimeout, sorry for the confusion.
On 12 August 2015 at 15:46, Salvador de la Puente González
sa...@unoyunodiez.com wrote:
AFAIK, this wont work because what clearTimeout() is actually expecting is
the id returned by setTimeout().
El 12/8/2015 16:00, Nick Krempel ndkrem...@google.com escribió:
On 12 August 2015 at 02:56, Isiah Meadows isiahmead...@gmail.com wrote:
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(handler = {
onNotNeeded(() = clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethingAsync(err = {
if (err != null) return reject(err)
else return resolve();
});
}));
```
This doesn't work as the function passed to clearTimeout does not === the
function passed to setTimeout.
In fact, they're not even behaviorally equal as the function passed to
setTimeout is expecting no parameters and the function passed to
clearTimeout is expecting one parameter - i.e. this is not even correct in
lambda calculus.
A lambda-calculus-correct version could be:
```
setTimeout((x=(y=()=x(y(y)))(y=()=x(y(y(handler = {...}));
```
But this would still suffer from the object identity problem mentioned
above. A final JS-correct version could be:
```
setTimeout((x = {const y = () = x(y); return y;})(handler = {...}));
```
Nick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
On Wed, Aug 12, 2015 at 7:31 AM, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is ${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
let yearSentence = ({year:2015}=`This year is ${year}`)();
should work, or
let yearSentence = (year=`This year is ${year}`)(2015);
You don't *have* to save the templates in variables. You can just call
them immediately.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.substitute
Yes I'm aware @claude that its kind of like the `with` statement
@Logan instead it would allow a way for a developer to parse the template
on call.
What's wrong with that?
And also will allow me to not use **Handlebars** or **Mustache**
I don't see anything wrong with having a method to do this and this
discussion led me to know that this could allow a way to interact with the
parser on call, which IMO could be useful.
On Wed, Aug 12, 2015 at 11:27 AM, Logan Smyth loganfsm...@gmail.com wrote:
Could be possible to pass a string with instead of \`\`
At that point, you are implementing a templating language that happens to
match up syntactically with template literals. You'd also then be moving
parsing of the template to runtime instead of compile time, which will slow
things down. It would also only be possible to implement using `eval`.
You can certainly do that, but it doesn't seem like something that should
be included in the language. It's no different from using Handlebars or
Mustache at that point. The primary benefit of template literals is that
they have access to variables in-scope, which seems to be what you are
trying to avoid.
On Wed, Aug 12, 2015 at 8:19 AM, Edwin Reynoso eor...@gmail.com wrote:
@logan that's an interesting thought, which is why I posted this for
discussion, Thinking of that, I'm kind of doubting most will like the
function to only be able to take the literal instead as a variable because
that's just messing with the way Javascript itself.
Could be possible to pass a string with instead of \`\`
```JS
String.substitute({year: 2015}, This year is ${year});
```
Which is giving javascript a way to allow writing a Template Literal
without evaluating by using instead of \`\`
@Tab atkin
Your still making a function yourself. You may ask what's wrong with that?
Well then I'd say what's the point of `ES6` having `Hi.includes(H)`
when we could of just did:
```JS
function includes(str, included) {
return str.indexOf(included) -1;
}
```
On Wed, Aug 12, 2015 at 11:08 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Aug 12, 2015 at 7:31 AM, Edwin Reynoso eor...@gmail.com wrote:
Yes of course, still requires 1.Destructuring, and making a function
for
each type of string to return. Defeats the purpose.
I'd have to make different functions for each template:
```JS
const yearTemplate = ({ year }) = `This year is ${year}`;
const ageTemplate = ({ age}) = `I'm ${age} yrs old`;
```
Compare to:
```JS
let yearSentence = String.substitute({ year: 2015}, `This year is
${year}`);
let ageSentence = String.substitute({ age:100 }, `I'm ${age} yrs old`);
```
let yearSentence = ({year:2015}=`This year is ${year}`)();
should work, or
let yearSentence = (year=`This year is ${year}`)(2015);
You don't *have* to save the templates in variables. You can just call
them immediately.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
Oops... Used to Node world. I didn't really test it, since I replied by
phone.
On Wed, Aug 12, 2015, 10:46 Salvador de la Puente González
sa...@unoyunodiez.com wrote:
AFAIK, this wont work because what clearTimeout() is actually expecting is
the id returned by setTimeout().
El 12/8/2015 16:00, Nick Krempel ndkrem...@google.com escribió:
On 12 August 2015 at 02:56, Isiah Meadows isiahmead...@gmail.com wrote:
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(handler = {
onNotNeeded(() = clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethingAsync(err = {
if (err != null) return reject(err)
else return resolve();
});
}));
```
This doesn't work as the function passed to clearTimeout does not === the
function passed to setTimeout.
In fact, they're not even behaviorally equal as the function passed to
setTimeout is expecting no parameters and the function passed to
clearTimeout is expecting one parameter - i.e. this is not even correct in
lambda calculus.
A lambda-calculus-correct version could be:
```
setTimeout((x=(y=()=x(y(y)))(y=()=x(y(y(handler = {...}));
```
But this would still suffer from the object identity problem mentioned
above. A final JS-correct version could be:
```
setTimeout((x = {const y = () = x(y); return y;})(handler = {...}));
```
Nick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it. Breaking the Web would be an understatement. On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. No operator proposal has included property access, not so much for reasons you give (which are good ones) but for separation of concerns. Allen did propose: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation This was controversial in the committee when last considered. Just sayin'! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Oh. Pardon my ignorance. Misunderstood the idea. On Wed, Aug 12, 2015, 23:19 Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 12, 2015, at 7:30 PM, Isiah Meadows wrote: I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it. Breaking the Web would be an understatement. Not so clear. The proposed default default for an indexed access would be exactly the same as for legacy property access. It is pretty much just providing a signal to the meta level that opens the possibility of newly defined object treating [ ] member accesses differently from . member accesses. Allen On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. No operator proposal has included property access, not so much for reasons you give (which are good ones) but for separation of concerns. Allen did propose: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation This was controversial in the committee when last considered. Just sayin'! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
For use cases that require named Functions (e.g. recursion), surely it's
not a such a big deal to either assign an Array Function to a variable
first, or use the good old trusty named Function expression or Function
statement.
var recurseExample = () = { recurseExample(); }
var recurseExample = function recurseExample () { recurseExample(); }
function recurseExample () { recurseExample(); }
I wonder if it's even a good idea to use Arrow Functions in places that do
not benefit from the new `this` behaviour? Just because code takes up fewer
characters does not necessarily mean it is easier to understand.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
Ups, I answered only to Jacob but I think this is a real simple solution:
var factorial;
x.map(factorial = x = x 1 ? 1 : x * factorial(x-1));
Or simply:
var factorial = x = x 1 ? 1 : x * factorial(x-1);
x.map(factorial);
As you said, this is ocassionally needed. And for event handlers:
var once = evt = { button.onclick = null; onClick(evt) };
button.onclick = once;
And yes, this solution was already provided:
https://esdiscuss.org/topic/self-recursion-and-arrow-functions#content-10
On Wed, Aug 12, 2015 at 4:00 AM, Isiah Meadows isiahmead...@gmail.com
wrote:
And as Kevin said, it has been mentioned before (with event handlers and
timeouts as the initial driving force).
https://esdiscuss.org/topic/self-recursion-and-arrow-functions
On Tue, Aug 11, 2015, 21:57 Isiah Meadows isiahmead...@gmail.com wrote:
Sent this too early... Corrected inline.
On Tue, Aug 11, 2015, 21:56 Isiah Meadows isiahmead...@gmail.com wrote:
The real reason people need named arrow functions, the biggest use case
is for event handlers.
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(handler = {
onNotNeeded(() = clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethingAsync(err = {
if (err != null) return reject(err)
else return resolve();
});
}));
```
By the way, the way I created a self reference is a complete lambda
calculus hack.
deviation
If you'd like your eyes to bleed, here's one that is purely out if
lambdas. I couldn't help myself.
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(h =
x = y = y(x()))(
onNotNeeded(() = clearTimeout(h)))(
doSomethingAsync(e =
e
!= null
?
reject(err)
:
resolve()
)))
);
```
On Tue, Aug 11, 2015, 20:45 Leonardo Wolter leocwol...@gmail.com wrote:
Well, I found out arguments is actually a reserved word too haha
About that:
If they're not from the tiny set of remaining reserved words
(enum, anyone?), they can be users' identifiers, and have to be based
contextually on some enclosing syntax, like yield is.
That could be it, right? Since it would be only available at arrow
functions(anon functions too?)
2015-08-11 21:42 GMT-03:00 Leonardo Wolter leocwol...@gmail.com:
Yeah., that's what I meant.
My proposal is not a keyword, but an hidden variable included at
functions (e.g. arguments).
Does arrow functions have any limitations about that?
2015-08-11 21:35 GMT-03:00 Daniel Ehrenberg dehrenb...@chromium.org:
I assume you mean more like this (without factorial):
x.map((x) = do {
if (x = 1) {
1;
} else {
x * recur(x - 1)
}
});
One issue is that it's hard to add keywords to JavaScript at this
point. If they're not from the tiny set of remaining reserved words
(enum, anyone?), they can be users' identifiers, and have to be based
contextually on some enclosing syntax, like yield is.
Another downside is that then, arrow functions have a distinct and
less powerful method of recursing (e.g., nested functions won't be
able to see the binding to the outer one).
Dan
On Tue, Aug 11, 2015 at 5:30 PM, Leonardo Wolter leocwol...@gmail.com
wrote:
What about a clojure like recur hidden variable binded to the
bottom-level
function?
x.map(factorial(x) = do {
if (x = 1) {
1;
} else {
x * recur(x - 1)
}
});
2015-08-11 21:26 GMT-03:00 Daniel Ehrenberg dehrenb...@chromium.org:
In addition to being hard to parse in general, I don't think this
would play very well with the async/await proposal
https://tc39.github.io/ecmascript-asyncawait/ , which wants to have
arrow functions like
async (x) = ...
Because we can't count on async as a keyword, your proposal would
create an ambiguity.
On Tue, Aug 11, 2015 at 1:49 PM, Jacob Parker
jacobparker1...@gmail.com
wrote:
I did look, but couldn’t find anything on named arrow functions were
not
included. I do sometimes find cases where I want recursion inside a
class
function definition, and still need access to `this`. Was it just
seen as
syntax bloat, or were there any complications to implementing it?
Obviously a contrived example, but something like this (using do
syntax
too)
x.map(factorial(x) = do {
if (x = 1) {
1;
} else {
x * factorial(x - 1)
}
});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
Re: String.substitute
Le 12 août 2015 à 17:35, Edwin Reynoso eor...@gmail.com a écrit : (...) and this discussion led me to know that this could allow a way to interact with the parser on call, which IMO could be useful. JavaScript has already a built-in feature for interacting with the parser at runtime: It’s called `eval`. (And note that, since placeholders in template literals can contain arbitrary code, you do need the full power of `eval`.) —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Oh, forgot to add a bit to those snippets to divide the bytes_per_element into
bits, but yeah
On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
SIMD types appear almost as limited in size as using numbers. Often I need to
manipulate thousands or millions of bits efficiently so fumbling around with
numbers is messy.
I've looked at several implementations on npm but none seemed very mature or
standard.
I guess it's philosophical as much as anything. In my mind the heart of
programming is bits and bytes so I find it odd that most programming
languages treat bits and bytes as strange uncles. In my mind all other data
types are derived from bits and bytes so it should be possible to easily
derive my own types this way or see the bits behind the types that are
built-in.
In this case I'm implementing a bit index (which is something I use a lot)
for quickly finding relationships in complex data. Often I want to mess with
bits for working with specifics of file formats and network protocols. When
working with large numbers it's nice to not worry about limits. And I work
directly with bits when doing electronics.
I'm not surprised that it's not supported but it seemed to go with the idea
of a byte array so I was hopeful. And it seems more generally useful than
things like SIMD types.
Thanks,
Michael McGlothlin
Sent from my iPhone
On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org wrote:
SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
vectors that are optimized to what hardware can optimize certain
operations for. A future extension (the long SIMD API) may operate
on whole arrays. I wouldn't recommend using SIMD.js unless you really
feel like you're taking advantage of the better performance, and the
particular vector size works for your requirements.
The point of SIMD is to expose higher-performance hardware features to
users. You may want to use this for implementing bitwise operations in
user code. However, if you don't need that, it may be enough for you
to use existing operators | ^ ~ etc, in a loop. A search on npm
yields tons of bitarray libraries which probably do this already,
though I haven't assessed how good they are.
If you were getting at operator overloading in particular, operators
are already well-defined on things like Uint8Array: Roughly speaking,
they will call .valueOf() and, if that results in a Number they will
do the operation on the underlying Number. There's no built-in valueOf
method for that object, but you can always monkeypatch one in. Here's
an example session in the V8 command-line shell:
d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
function () { return 1 }
d8 new Uint8ClampedArray([1, 2]) 3
8
The downside of doing anything beyond existing npm packages and
changing the language is that it increases complexity. What is the
upside you have in mind to building it into the language?
Have fun!
Dan
On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
Would there be a downside to extending Bitwise operators to work with
typed arrays such as UInt8ClampedArray? To me it seems natural to want to
perform bit operations on these. Or is there a better way to make a BitSet
that I'm missing?
Thanks,
Michael McGlothlin
Sent from my iPhone
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Well, you could just use typed arrays for this, and add a helper function which
retrieves the bit at a specific index. Like, something like this:
```
function bitset_get(ta, i) {
var e = (i / ta.BYTES_PER_ELEMENT) | 0;
i = i % ta.BYTES_PER_ELEMENT;
return (ta[e] i) 1;
}
```
You could do similar stuff for manipulation, like
```
function bitset_flip(ta, i) {
var e = (i / ta.BYTES_PER_ELEMENT) | 0;
i = i % ta.BYTES_PER_ELEMENT;
ta[e] ^= (1 i);
return (ta[e] i) 1;
}
```
If your typed array is of a smallish type, like unsigned 16 bits, you should be
able to predictably use SMI integrals when manipulating them, which might
prevent some accidental floating point bugs.
And you could even make these robust by ensuring they match the bitwise and
bytewise endianness of the underlying architecture, with some simple tests.
Operator overloading or value types might make it look a lot prettier some day
(though iirc element assessor overloading was off limits), but you could get
pretty far by baking it into a compile-to-js language.
If people were using stuff like that commonly, it might end up in the standard
lib some day.
Apologies for any typos or nonsense grammar, Swype is bad
On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
SIMD types appear almost as limited in size as using numbers. Often I need to
manipulate thousands or millions of bits efficiently so fumbling around with
numbers is messy.
I've looked at several implementations on npm but none seemed very mature or
standard.
I guess it's philosophical as much as anything. In my mind the heart of
programming is bits and bytes so I find it odd that most programming
languages treat bits and bytes as strange uncles. In my mind all other data
types are derived from bits and bytes so it should be possible to easily
derive my own types this way or see the bits behind the types that are
built-in.
In this case I'm implementing a bit index (which is something I use a lot)
for quickly finding relationships in complex data. Often I want to mess with
bits for working with specifics of file formats and network protocols. When
working with large numbers it's nice to not worry about limits. And I work
directly with bits when doing electronics.
I'm not surprised that it's not supported but it seemed to go with the idea
of a byte array so I was hopeful. And it seems more generally useful than
things like SIMD types.
Thanks,
Michael McGlothlin
Sent from my iPhone
On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org wrote:
SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
vectors that are optimized to what hardware can optimize certain
operations for. A future extension (the long SIMD API) may operate
on whole arrays. I wouldn't recommend using SIMD.js unless you really
feel like you're taking advantage of the better performance, and the
particular vector size works for your requirements.
The point of SIMD is to expose higher-performance hardware features to
users. You may want to use this for implementing bitwise operations in
user code. However, if you don't need that, it may be enough for you
to use existing operators | ^ ~ etc, in a loop. A search on npm
yields tons of bitarray libraries which probably do this already,
though I haven't assessed how good they are.
If you were getting at operator overloading in particular, operators
are already well-defined on things like Uint8Array: Roughly speaking,
they will call .valueOf() and, if that results in a Number they will
do the operation on the underlying Number. There's no built-in valueOf
method for that object, but you can always monkeypatch one in. Here's
an example session in the V8 command-line shell:
d8 Uint8ClampedArray.prototype.valueOf = function() { return 1 }
function () { return 1 }
d8 new Uint8ClampedArray([1, 2]) 3
8
The downside of doing anything beyond existing npm packages and
changing the language is that it increases complexity. What is the
upside you have in mind to building it into the language?
Have fun!
Dan
On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
Would there be a downside to extending Bitwise operators to work with
typed arrays such as UInt8ClampedArray? To me it seems natural to want to
perform bit operations on these. Or is there a better way to make a BitSet
that I'm missing?
Thanks,
Michael McGlothlin
Sent from my iPhone
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
Re: String.substitute
Le 12 août 2015 à 15:41, Edwin Reynoso eor...@gmail.com a écrit :
Could we make the following possible, I can't seem to think of a way to do
it, since template literals are evaluated with the current scope, also tried
with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns This
year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the point is
to have a template literal evaluate as a pass reference and not right away.
You can't make your own function and pass in a template literal that's not
evaluated when passed as a reference, I'm not sure if anyone will actually
want this but me. Please let me know. Thanks
There is a general trick for deferring evaluation (of a template literal or of
anything else): enclosing it in a function.
```js
const myTemplate = ({ year }) = `This year is ${year}`
myTemplate({ year: 2015 })
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Arrow Functions
On 12 August 2015 at 02:56, Isiah Meadows isiahmead...@gmail.com wrote:
```js
let p = new Promise((resolve, reject) =
setTimeout((x = () = x(x))(handler = {
onNotNeeded(() = clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethingAsync(err = {
if (err != null) return reject(err)
else return resolve();
});
}));
```
This doesn't work as the function passed to clearTimeout does not === the
function passed to setTimeout.
In fact, they're not even behaviorally equal as the function passed to
setTimeout is expecting no parameters and the function passed to
clearTimeout is expecting one parameter - i.e. this is not even correct in
lambda calculus.
A lambda-calculus-correct version could be:
```
setTimeout((x=(y=()=x(y(y)))(y=()=x(y(y(handler = {...}));
```
But this would still suffer from the object identity problem mentioned
above. A final JS-correct version could be:
```
setTimeout((x = {const y = () = x(y); return y;})(handler = {...}));
```
Nick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
String.substitute
Could we make the following possible, I can't seem to think of a way to do
it, since template literals are evaluated with the current scope, also
tried with `eval` but shouldn't even use that at all:
```JS
String.substitute( { year: 2015 }, `This year is ${year}` ); // Returns
This year is 2015
```
Yes I'm aware I could do the following:
```JS
var obj = { year:2015 }
`This year is ${obj.year}`
```
The point is to get rid of the part where I reference `obj` all the time.
I could just use destructuring:
```JS
var { year } = { year: 2015 }
`This year is ${year}`
```
So yes destructuring takes care of most of this just fine, but the point is
to have a template literal evaluate as a pass reference and not right away.
You can't make your own function and pass in a template literal that's not
evaluated when passed as a reference, I'm not sure if anyone will actually
want this but me. Please let me know. Thanks
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. On Aug 12, 2015, at 1:44 PM, Daniel Ehrenberg dehrenb...@chromium.org wrote: On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: Operator overloading or value types might make it look a lot prettier some day (though iirc element assessor overloading was off limits), but you could get pretty far by baking it into a compile-to-js language. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: Operator overloading or value types might make it look a lot prettier some day (though iirc element assessor overloading was off limits), but you could get pretty far by baking it into a compile-to-js language. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Also `instanceof` overloading via `Symbol.hasInstance` On Wed, Aug 12, 2015 at 10:44 AM, Daniel Ehrenberg dehrenb...@chromium.org wrote: On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: Operator overloading or value types might make it look a lot prettier some day (though iirc element assessor overloading was off limits), but you could get pretty far by baking it into a compile-to-js language. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
