Re: Generalize do-expressions to statements in general?
All you are proposing is to allow the braces to be dropped from a
do-expression, right? That's an obvious tweak, although I'm not sure if it
really improves readability. (Other than that, do-expressions are already
intended to work as you describe, using the completion value of the
statement list. That's their whole point, after all.)
I had something else in mind. Once we have do expressions, we can introduce
syntactic sugar that effectively makes any statement syntax into legal
expressions. E.g.:
throw expr ~ do { throw expr; }
try expr catch (pat) expr ~ do { try { expr; } catch (pat) { expr; } }
if (expr) expr else expr ~ do { if (expr) expr; else expr; }
etc
At least for those statements for which it makes sense. To avoid ambiguity,
all you need to do is extend the existing restriction that none of the
initial keywords may start an expression statement.
But I intend to propose that separately from (or as an optional part of)
the do-expressions proposal, since it might be more controversial.
/Andreas
On 14 July 2015 at 00:47, Isiah Meadows impinb...@gmail.com wrote:
I was reading a recent thread
https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value where
do-expressions simplified a common try-catch use case, and I was wondering
if `do` could be simplified to an expression? It would allow for this to be
solved very easily, but also add a lot more flexibility in this proposal,
as well as avoiding some ugly nested braces.
I know it would cause an ambiguity with `do-while` loops, but that could
be resolved with a single token lookahead of if the next token is the
keyword `while`, then the block body is the body of a do-while loop, else
it is the body of the block statement in a `do` expression.
As for the EBNF, do-expressions could be parsed with a goal symbol of
either `+While` or `-While`, with do-while statements spec-wise effectively
being treated as do-expressions without an init part run repetitively, but
mandated to be statements.
```js
// Do expression
let foo = do {
foo(0)
};
let tried = do try {
foo(0)
} catch (e) {
throw e
};
// Do-while statement
let i = 0;
do {
foo(i)
} while (i++ 10);
// Combined:
let i = 0;
let foo9 = do do {
foo(i) // can have side effects, foo9 = foo(9)
} while (i++ 10);
```
Another example of where this could come in handy: simplifying
asynchronous code.
```js
function readConfig() {
fs.readFileAsync('config.json', 'utf8')
.then(JSON.parse)
.then(contents = do if (contents.unexpectedProperty) {
throw new Error('Bad property') // rejects the promise
} else {
doSomething(contents)
})
.catch(err = process.domain.emit('err', error))
}
// With only block statement
function readConfig() {
fs.readFileAsync('config.json', 'utf8')
.then(JSON.parse)
.then(contents = do {
if (contents.unexpectedProperty) {
throw new Error('Bad property') // rejects the promise
} else {
doSomething(contents)
}
})
.catch(err = process.domain.emit('err', error))
}
// Without do-expressions
function readConfig() {
fs.readFileAsync('config.json', 'utf8')
.then(JSON.parse)
.then(contents = {
if (contents.unexpectedProperty) {
throw new Error('Bad property') // rejects the promise
} else {
doSomething(contents)
}
})
.catch(err = process.domain.emit('err', error))
}
```
As you can see, the more general version does simplify things a little.
Also, if-statements look better than long ternaries IMHO, and are less
repetitive than their counterpart, repeated assignment (us lazy typists...):
```js
let foo = do if (someCondition) {
value
} else if (someOtherCondition) {
value + 1
} else if (someEdgeCase) {
addressEdgeCase(value)
} else {
value
}
```
--
Isiah Meadows
___
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: Generalize do-expressions to statements in general?
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call do
expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow all
these forms to be expressions. As with {, function, or class, if you
want to state such an expression in expression-statement position, surround
it with parens.
Because all these new forms will look bizarre and confusing, at least at
first, let's say these always need surrounding parens to be expressions. I
think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object literal
expression. This proposal gives us no straightforward way to express an
block expression. function and class are less odd, since their existing
expression forms mean what you almost might expect by this new rule -- even
though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It would
even be consistent enough with the existing semantics of paren-surrounded
function and class expressions: Someone who sees these as a function or
class declaration within its own nested scope, whose value was the value
being declared, would rarely be surprised by the subtle difference between
that story and the current semantics.
Having parens accept a list of declarations and statements rather than
just an expressions seems like a radical change that must break something,
but I can't find a problem. Am I missing something?
Examples inline:
On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows impinb...@gmail.com
wrote:
I was reading a recent thread
https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value where
do-expressions simplified a common try-catch use case, and I was wondering
if `do` could be simplified to an expression? It would allow for this to be
solved very easily, but also add a lot more flexibility in this proposal,
as well as avoiding some ugly nested braces.
I know it would cause an ambiguity with `do-while` loops, but that could
be resolved with a single token lookahead of if the next token is the
keyword `while`, then the block body is the body of a do-while loop, else
it is the body of the block statement in a `do` expression.
As for the EBNF, do-expressions could be parsed with a goal symbol of
either `+While` or `-While`, with do-while statements spec-wise effectively
being treated as do-expressions without an init part run repetitively, but
mandated to be statements.
```js
// Do expression
let foo = do {
foo(0)
};
let foo = (foo(0));
This seems as broken as the original. In both cases, unless I'm missing
something, this is a TDZ violation when the right side evaluates foo.
Mistake?
let tried = do try {
foo(0)
} catch (e) {
throw e
};
let tried = (try { foo(0) } catch (e) { throw e });
// Do-while statement
let i = 0;
do {
foo(i)
} while (i++ 10);
// Combined:
let i = 0;
let foo9 = do do {
Re: for statement with index and value
Unless you have a specific requirement I am missing, your use case is more
elegantly resolved IMO using a custom generator that yields exactly the
information you need per iteration.
A functional approach using a function that has the information you need is
also another valid solution.
div 元のメール /divdiv送信元： Tingan Ho tinga...@gmail.com
/divdiv日時:2015/07/14 PM1:32 (GMT+09:00) /divdiv宛先： Edwin Reynoso
eor...@gmail.com /divdivCc： es-discuss es-discuss@mozilla.org
/divdiv件名: Re: for statement with index and value /divdiv
/divYes the proposed syntax is a special case for arrays.
tis 14 juli 2015 kl 12:23 skrev Edwin Reynoso eor...@gmail.com:
Something wrong with server that doesn't let me edit.
But what I meant by the first code snippet was:
```JS
for(let a, b of new Set([1,2])) // what would `a` and `b` be here? How would it
know what to extract??
```
Would `b` just be `undefined`, yet for an array it returns the `index` how does
it determine that unless again this is special to Arrays?? because `b/index`
could be anything else, that's not obvious compare to destructuring.
On Tue, Jul 14, 2015 at 12:13 AM, Edwin Reynoso eor...@gmail.com wrote:
So I'm assuming this would be special to arrays??
because destructuring works fine for anything that's iterable:
meaning how would it know what to take out for Sets??
```JS
for(let value, index of [1,2]) {
// do something
}
```
With destructuring we at least know what's being extracted (not sure if
destructured would be the right word, clueless on that):
```JS
let it = [1,2].entries();
let [index, value] = it.next();
// same as:
let [index, value] = [0, 1];
// the matching is obvious
```
With your suggestion it's not obvious:
```JS
for(let value, index of [1,2]) // how does it know what value and index would
be??
```
I don't think this would be done if it's only for Arrays.
On Tue, Jul 14, 2015 at 12:04 AM, Tingan Ho tinga...@gmail.com wrote:
Unfortunately we can't have both...
```
for (let [index, value] of values){
```
I was suggesting the syntax:
```
for (let value, index of values){
```
`value` comes first and no `[ ... ]`.
On Tue, Jul 14, 2015 at 11:52 AM, Logan Smyth loganfsm...@gmail.com wrote:
Unfortunately we can't have both
```
for (let value of values){
```
and
```
for (let [index, value] of values){
```
Over all, the first one is the more likely one on a day-to-day basis.
The `[]` are needed because the `for...of` follows the standard rules for
assignment, so it uses standard destructuring, and JS array destructuring
requires `[]`.
```
for (let [index, value] of values.entries()){
```
is essentially is the same as
```
for (let pair of values.entries()){
let [index, value] = pair;
```
As for your last question, `.entries` returns an iterator, so it will not
create a copy of the array.
On Mon, Jul 13, 2015 at 7:43 PM, Tingan Ho tinga...@gmail.com wrote:
for (let [index, value] of [1, 2, 3].entries())
console.log(index + : + value)
I still think most people will write:
```
for (let value of values) { ... }
```
and then rewrite the whole expression inside the `for-loop` when they find out
that they need the index too:
```
for (let [index, value] of [1, 2, 3].entries())
console.log(index + : + value)
```
`for (let value, index of values) { ... }` is still much easier to type than
`for (let [index, value] of [1, 2, 3].entries())` and also more readable.
Also, doesn't that makes a copy of the `[1, 2, 3]`?
--
Sincerely,
Tingan Ho
@tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sincerely,
Tingan Ho
@tingan87
___
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 Paramters
Seems everybody is pessimistic about this. But using optional `labels`
would solve any problem with the minifiers.
```javascript
// Not minified (Labels are optional, default are the variable names)
function foo (bar = 1, baz = 2, bak = 3) {
console.log(baz);
}
foo (baz: 2);
// Minified
function foo(bar:a=1,baz:b=2,bak:c=3){console.log(b)}
foo(baz:2);
// Explicit Label
function foo (bar = 1, baz: myVar = 2, bak = 3) {
console.log(myVar);
}
foo (baz: 2);
// Minified (same)
function foo(bar:a=1,baz:b=2,bak:c=3){console.log(b)}
foo(baz:2);
```
And when talking about static analysis, then it is really not always
possible to determine the global function variables, but within the
scope(s) it shouldn't be the problem. But anyway, the labels will cover all
the cases.
Sorry for bothering, if I miss something,
Alex
On 13 July 2015 at 14:54, Benjamin Gruenbaum benjami...@gmail.com wrote:
If we _wanted_ to add named parameters, we would _probably_ have a
_different_ name for the named parameter inside the function and outside
the function.
```js
function foo(x as y){
}
foo(y = 5);
```
Or something like that. That said, I'm not convinced we _need_ named
parameters, that they justify the additional cost or the overhead, that
current solutions like destructing aren't enough and so on. Even if we all
agreed that we want named parameters, and we agreed in general lines how it
should be done, and we convinced the TC, there would still be a lot of work
to actually decide' they should make it to ES.
So I suggest we close this thread and anyone who feel strongly about
including named parameters should work on a concrete proposal :)
Cheers,
Benjamin
On Mon, Jul 13, 2015 at 3:50 PM, Michał Wadas michalwa...@gmail.com
wrote:
In fact, it's impossible.
And when the arguments are renamed during the minification, all
the labels in function calls can be minified accordingly too.
You can't statically determine which function will be called. Minifier
CAN'T know in general case if your $(selector='wow') calls jQuery or
some other function at minify time.
So: you can't rely on optional parameters in any CDN-distributed file
(because your minifier doesn't know about it's pre-minification
identifiers), minifier have to avoid any parameters names clash at any
cost.
Possible solution: add gramar explicitly declare optional parameters
by keyword to avoid minifaction of their names names.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Paramters
There are a couple of people tossing around named parameter ideas that have
different identifiers than the argument identifier. What is wrong with what
Gary Guo originally said with `foo(bar: 5)`, it uses `:` for mapping
similar to an object literal, but does not require having contextual
knowledge and breaking changes like `=` would; it also does not require
having multiple identifiers for the same variable.
Perhaps I may be wrong here, but having multiple identifiers/bindings to
the same variable seems fraught with confusion.
On Tue, Jul 14, 2015 at 6:03 AM, Alexander Kit alex@atmajs.com wrote:
Seems everybody is pessimistic about this. But using optional `labels`
would solve any problem with the minifiers.
```javascript
// Not minified (Labels are optional, default are the variable names)
function foo (bar = 1, baz = 2, bak = 3) {
console.log(baz);
}
foo (baz: 2);
// Minified
function foo(bar:a=1,baz:b=2,bak:c=3){console.log(b)}
foo(baz:2);
// Explicit Label
function foo (bar = 1, baz: myVar = 2, bak = 3) {
console.log(myVar);
}
foo (baz: 2);
// Minified (same)
function foo(bar:a=1,baz:b=2,bak:c=3){console.log(b)}
foo(baz:2);
```
And when talking about static analysis, then it is really not always
possible to determine the global function variables, but within the
scope(s) it shouldn't be the problem. But anyway, the labels will cover all
the cases.
Sorry for bothering, if I miss something,
Alex
On 13 July 2015 at 14:54, Benjamin Gruenbaum benjami...@gmail.com wrote:
If we _wanted_ to add named parameters, we would _probably_ have a
_different_ name for the named parameter inside the function and outside
the function.
```js
function foo(x as y){
}
foo(y = 5);
```
Or something like that. That said, I'm not convinced we _need_ named
parameters, that they justify the additional cost or the overhead, that
current solutions like destructing aren't enough and so on. Even if we all
agreed that we want named parameters, and we agreed in general lines how it
should be done, and we convinced the TC, there would still be a lot of work
to actually decide' they should make it to ES.
So I suggest we close this thread and anyone who feel strongly about
including named parameters should work on a concrete proposal :)
Cheers,
Benjamin
On Mon, Jul 13, 2015 at 3:50 PM, Michał Wadas michalwa...@gmail.com
wrote:
In fact, it's impossible.
And when the arguments are renamed during the minification, all
the labels in function calls can be minified accordingly too.
You can't statically determine which function will be called. Minifier
CAN'T know in general case if your $(selector='wow') calls jQuery or
some other function at minify time.
So: you can't rely on optional parameters in any CDN-distributed file
(because your minifier doesn't know about it's pre-minification
identifiers), minifier have to avoid any parameters names clash at any
cost.
Possible solution: add gramar explicitly declare optional parameters
by keyword to avoid minifaction of their names names.
___
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: for statement with index and value
Why not use the new meta syntax?
for (let value of values) {
console.log(for.index);
}
- Matthew Robb
On Tue, Jul 14, 2015 at 7:45 AM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Mon Jul 13 10:22 PM, Kevin Smith wrote:
Destructuring is here to help:
for (let [index, value] of [1, 2, 3].entries())
console.log(index + : + value)
The entries method returns an iterator of [index, value] pairs.
Can't there be a 'key iterator' syntax?
for (let value, index of [1, 2, 3])
console.log(index + : + value)
let value = itOfValues.next().value;
let index= itOfKeys.next().value;
- An array has an implicit 'key iterator' cause there's a key for each
value.
- Everything else has a 'keyIteratorFrom0ToInifinity'
So you have a 'value iterator' and a 'key iterator' for each thing on the
RHS.
Doesn't seem like much of an issue, engines just need a
keyIteratorFrom0ToInifinity for non-array things cases.
___
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: for statement with index and value
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? This is pretty ingenious. If I thought this was a real problem that needed solving, I'd definitely go this route. (But, I think that using .entries() and destructuring is fine, and there's no need to add new syntax to save people a few characters.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: for statement with index and value
On Mon Jul 13 10:22 PM, Kevin Smith wrote: Destructuring is here to help: for (let [index, value] of [1, 2, 3].entries()) console.log(index + : + value) The entries method returns an iterator of [index, value] pairs. Can't there be a 'key iterator' syntax? for (let value, index of [1, 2, 3]) console.log(index + : + value) let value = itOfValues.next().value; let index= itOfKeys.next().value; - An array has an implicit 'key iterator' cause there's a key for each value. - Everything else has a 'keyIteratorFrom0ToInifinity' So you have a 'value iterator' and a 'key iterator' for each thing on the RHS. Doesn't seem like much of an issue, engines just need a keyIteratorFrom0ToInifinity for non-array things cases. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generalize do-expressions to statements in general?
The only gripes I have with do expressions is the inability to specify the
value produced in an obvious and uniform way, also are do expressions
capable of being labelled?
- Matthew Robb
On Tue, Jul 14, 2015 at 3:31 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call do
expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow all
these forms to be expressions. As with {, function, or class, if you
want to state such an expression in expression-statement position, surround
it with parens.
Because all these new forms will look bizarre and confusing, at least at
first, let's say these always need surrounding parens to be expressions. I
think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object literal
expression. This proposal gives us no straightforward way to express an
block expression. function and class are less odd, since their existing
expression forms mean what you almost might expect by this new rule -- even
though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It would
even be consistent enough with the existing semantics of paren-surrounded
function and class expressions: Someone who sees these as a function or
class declaration within its own nested scope, whose value was the value
being declared, would rarely be surprised by the subtle difference between
that story and the current semantics.
Having parens accept a list of declarations and statements rather than
just an expressions seems like a radical change that must break something,
but I can't find a problem. Am I missing something?
Examples inline:
On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows impinb...@gmail.com
wrote:
I was reading a recent thread
https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value where
do-expressions simplified a common try-catch use case, and I was wondering
if `do` could be simplified to an expression? It would allow for this to be
solved very easily, but also add a lot more flexibility in this proposal,
as well as avoiding some ugly nested braces.
I know it would cause an ambiguity with `do-while` loops, but that could
be resolved with a single token lookahead of if the next token is the
keyword `while`, then the block body is the body of a do-while loop, else
it is the body of the block statement in a `do` expression.
As for the EBNF, do-expressions could be parsed with a goal symbol of
either `+While` or `-While`, with do-while statements spec-wise effectively
being treated as do-expressions without an init part run repetitively, but
mandated to be statements.
```js
// Do expression
let foo = do {
foo(0)
};
let foo = (foo(0));
This seems as broken as the original. In both cases, unless I'm missing
something, this is a TDZ violation when the right
Re: Generalize do-expressions to statements in general?
On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
Ah. Take a look at my full proposal. The bizarre observation is that
extending the syntax of parens to contain approx a block-body, and
extending its meaning to creating a block-like scope for evaluating that
block-body, in addition to returning a value. In that case, we simply don't
need the do expression at all. Don't propose something unnecessarily
complex just because you expect that something simpler would be too
controversial. If it actually is too controversial, that's another matter.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
Between Gedanken, Smalltalk, and Actors, almost everything we do in oo
dynamic language design was already conceived right by the early '70s.
Retrofitting without breaking things takes much longer than invention ;)
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call do
expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow all
these forms to be expressions. As with {, function, or class, if you
want to state such an expression in expression-statement position, surround
it with parens.
Because all these new forms will look bizarre and confusing, at least at
first, let's say these always need surrounding parens to be expressions. I
think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object literal
expression. This proposal gives us no straightforward way to express an
block expression. function and class are less odd, since their existing
expression forms mean what you almost might expect by this new rule -- even
though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It would
even be consistent enough with the existing semantics of paren-surrounded
function and class expressions: Someone who sees these as a function or
class declaration within its own nested scope, whose value was the value
being declared, would rarely be surprised by the subtle difference between
that story and the current semantics.
Having parens accept a list of declarations and statements rather than
just an expressions seems like a radical change that must break something,
but I can't find a problem. Am I missing something?
Examples inline:
On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows impinb...@gmail.com
wrote:
I was reading a recent thread
https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value where
do-expressions simplified a common try-catch use case, and I was wondering
if `do` could be simplified to an expression? It would allow for this to be
solved very easily, but also add a lot more flexibility in this proposal,
as well as avoiding some ugly nested braces.
I know it would cause an ambiguity with `do-while` loops, but that could
be resolved with a single token lookahead of if the next token is the
keyword `while`, then the block body is the body of a
RE: for statement with index and value
From: Tingan Ho [mailto:tinga...@gmail.com] But they aren't clean solutions to a wildly popular problem. I disagree. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for statement with index and value
On 14 July 2015 at 15:41, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: On Tue Jul 14 09:27 AM, Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? If I thought this was a real problem that needed solving, Disagree As early as the mid-1980’s, it was observed that programming language research and funding emphasized technical aspects of the domain and neglected psychological aspects: The human and computer parts of programming languages have developed in radical asymmetry http://repository.cmu.edu/cgi/viewcontent.cgi?article=1805context=isr Bias of Engineering problems Psychology You might want to catch up on the recent discussion we just had here: https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html Complexity is very much a psychological aspect. And random special cases, syntactic additions, and irregularities eat into the complexity budget quickly. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for statement with index and value
This is pretty ingenious. If I thought this was a real problem that needed solving I'm not sure how I should interpret this. But I'm pretty sure you also need the current index of array in a for loop. Since I can access the index and value directly in `.forEach(value, index, array)`, why isn't there a for-loop-statement/control-flow-statement for doing the same thing? And yes I heard it can be solved with different methods. We can go on discuss different way to loop through an array, recursive functions, while-loops, iterators, generators, meta syntax etc. But they aren't clean solutions to a wildly popular problem. All these counter arguments. Can you explain why even `.forEach(value, index, array)` made the deal also? tis 14 juli 2015 kl 21:41 skrev Jonathan Bond-Caron jbo...@gdesolutions.com : On Tue Jul 14 09:27 AM, Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? If I thought this was a real problem that needed solving, Disagree As early as the mid-1980’s, it was observed that programming language research and funding emphasized technical aspects of the domain and neglected psychological aspects: The human and computer parts of programming languages have developed in radical asymmetry http://repository.cmu.edu/cgi/viewcontent.cgi?article=1805context=isr Bias of Engineering problems Psychology ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: for statement with index and value
On Tue Jul 14 09:27 AM, Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? If I thought this was a real problem that needed solving, Disagree As early as the mid-1980’s, it was observed that programming language research and funding emphasized technical aspects of the domain and neglected psychological aspects: The human and computer parts of programming languages have developed in radical asymmetry http://repository.cmu.edu/cgi/viewcontent.cgi?article=1805context=isr Bias of Engineering problems Psychology ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generalize do-expressions to statements in general?
On 14 July 2015 at 15:04, Matthew Robb matthewwr...@gmail.com wrote:
The only gripes I have with do expressions is the inability to specify the
value produced in an obvious and uniform way,
Well, the completion value is fairly uniform. You mean an analogue to a
return in a function body?
also are do expressions capable of being labelled?
No, but they can of course contain a labelled statement, which is
equivalently expressive.
/Andreas
On Tue, Jul 14, 2015 at 3:31 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call do
expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow all
these forms to be expressions. As with {, function, or class, if you
want to state such an expression in expression-statement position, surround
it with parens.
Because all these new forms will look bizarre and confusing, at least at
first, let's say these always need surrounding parens to be expressions. I
think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object literal
expression. This proposal gives us no straightforward way to express an
block expression. function and class are less odd, since their existing
expression forms mean what you almost might expect by this new rule -- even
though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It would
even be consistent enough with the existing semantics of paren-surrounded
function and class expressions: Someone who sees these as a function or
class declaration within its own nested scope, whose value was the value
being declared, would rarely be surprised by the subtle difference between
that story and the current semantics.
Having parens accept a list of declarations and statements rather than
just an expressions seems like a radical change that must break something,
but I can't find a problem. Am I missing something?
Examples inline:
On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows impinb...@gmail.com
wrote:
I was reading a recent thread
https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value
where
do-expressions simplified a common try-catch use case, and I was wondering
if `do` could be simplified to an expression? It would allow for this to be
solved very easily, but also add a lot more flexibility in this proposal,
as well as avoiding some ugly nested braces.
I know it would cause an ambiguity with `do-while` loops, but that
could be resolved with a single token lookahead of if the next token is
the keyword `while`, then the block body is the body of a do-while loop,
else it is the body of the block statement in a `do` expression.
As for the EBNF, do-expressions could be parsed with a goal symbol of
either `+While` or `-While`, with do-while statements spec-wise effectively
being treated as do-expressions without
Re: Generalize do-expressions to statements in general?
On 14 July 2015 at 16:48, Mark S. Miller erig...@google.com wrote:
On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
Ah. Take a look at my full proposal. The bizarre observation is that
extending the syntax of parens to contain approx a block-body, and
extending its meaning to creating a block-like scope for evaluating that
block-body, in addition to returning a value. In that case, we simply don't
need the do expression at all. Don't propose something unnecessarily
complex just because you expect that something simpler would be too
controversial. If it actually is too controversial, that's another matter.
I would very much dislike introducing a second syntax for blocks, though --
which is essentially what you are suggesting. Especially when curly braces
provide a much better visual clue for the extent of a scope than innocent
plain parens do. It's the natural expectation for a C-like language, too.
In the design of any modern language the whole notion of block of course is
totally obsolete. But JavaScript has its C heritage, and I doubt bolting on
something alien would make it a prettier language.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
Between Gedanken, Smalltalk, and Actors, almost everything we do in oo
dynamic language design was already conceived right by the early '70s.
Retrofitting without breaking things takes much longer than invention ;)
Well, statements vs expressions was already found unnecessary before OO, in
the early 60s -- consider Algol 68. (Let alone Lisp, which is late 50s.)
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call do
expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow all
these forms to be expressions. As with {, function, or class, if you
want to state such an expression in expression-statement position, surround
it with parens.
Because all these new forms will look bizarre and confusing, at least at
first, let's say these always need surrounding parens to be expressions. I
think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object literal
expression. This proposal gives us no straightforward way to express an
block expression. function and class are less odd, since their existing
expression forms mean what you almost might expect by this new rule -- even
though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It would
even be consistent enough with the existing semantics of paren-surrounded
function and class expressions: Someone who sees these as a function or
class declaration within its own nested scope, whose value was the value
being declared, would rarely be surprised by the subtle difference between
that story and the current semantics.
Having parens accept a list of declarations and statements rather than
just an expressions seems like a radical change that must break something,
but I can't
Re: Generalize do-expressions to statements in general?
On Tue, Jul 14, 2015 at 10:59 AM, Andreas Rossberg rossb...@google.com
wrote:
On 14 July 2015 at 16:48, Mark S. Miller erig...@google.com wrote:
On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.
Ah. Take a look at my full proposal. The bizarre observation is that
extending the syntax of parens to contain approx a block-body, and
extending its meaning to creating a block-like scope for evaluating that
block-body, in addition to returning a value. In that case, we simply don't
need the do expression at all. Don't propose something unnecessarily
complex just because you expect that something simpler would be too
controversial. If it actually is too controversial, that's another matter.
I would very much dislike introducing a second syntax for blocks, though
-- which is essentially what you are suggesting. Especially when curly
braces provide a much better visual clue for the extent of a scope than
innocent plain parens do. It's the natural expectation for a C-like
language, too.
I can see that. I'm torn.
In the design of any modern language the whole notion of block of course
is totally obsolete. But JavaScript has its C heritage, and I doubt bolting
on something alien would make it a prettier language.
...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)
Between Gedanken, Smalltalk, and Actors, almost everything we do in oo
dynamic language design was already conceived right by the early '70s.
Retrofitting without breaking things takes much longer than invention ;)
Well, statements vs expressions was already found unnecessary before OO,
in the early 60s -- consider Algol 68. (Let alone Lisp, which is late 50s.)
For that part specifically, sure. Gedanken also had full indefinite extent
lexical closures. It might have been the first to do so -- Lisp was
dynamically scoped at the time and Actors had not yet been invented. I've
always been puzzled why Gedanken has not gotten more attention --
especially since it was mainly by John Reynolds. Check it out -- you'll be
impressed.
/Andreas
On 14 July 2015 at 01:33, Mark S. Miller erig...@google.com wrote:
Interesting. Got me thinking. Here's an alternate proposal I'll call
do expressions without the 'do'.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement
we have the syntax of the expression statement. Ignoring sloppy let
nonsense, this says that an expression statement cannot begin with {,
function, or class.
At
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
are the legal ES6 statements. Note that most of these begin with a keyword
that cannot possibly be legal at the beginning of an expression. Therefore,
adding all these initial-statement-keywords to the list of things that
cannot begin an expression statement would break nothing. They already
cannot begin an expression statement.
With the expression statement prohibition in place, now we can allow
all these forms to be expressions. As with {, function, or class, if
you want to state such an expression in expression-statement position,
surround it with parens.
Because all these new forms will look bizarre and confusing, at least
at first, let's say these always need surrounding parens to be expressions.
I think that would help minimize confusion.
If we do this, the oddest duck is {, since it begins an object
literal expression. This proposal gives us no straightforward way to
express an block expression. function and class are less odd, since
their existing expression forms mean what you almost might expect by this
new rule -- even though they are initial-declaration-keywords rather than
initial-statement-keywords.
The remaining initial-declaration-keywords are let and const. We
already made let insane regarding these issues in sloppy mode, so I'm
going to ignore that. But let's consider const and strict let. These
already cannot appear at the beginning of an expression, so it would not
break anything to add them to the prohibition list for the beginning of
expression statements.
No current expression can add any binding to the scope in which the
expression appears. Let's examine the consequences of having parens --
rather than containing a {-block to create a nested scope with a value
(which would conflict with object literals), instead simply define a
block-like nested scope with a value. This would allow declarations and
statements within the parens, much like the current do proposal. It
Clarification for derived promises
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived class. Consider this:
```
class MyPromise extends Promise {}
var p1 = new Promise(function(resolve, reject) {
resolve(42);
});
var p2 = MyPromise.resolve(p1);
p2.then(function(value) {
console.log(value);
});
```
Am I correct in believing that:
1. `p1` is resolved upon being passed to `MyPromise.resolve()`? I
believe this is what happens in 25.4.4.5 Step 6
(http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve)
2. `p2` is an instance of `MyPromise` that is resolved with a promise
value of 42.
Thanks!
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Clarification for derived promises
Yes.
On Tue, Jul 14, 2015 at 10:10 AM -0700, Nicholas C. Zakas
standa...@nczconsulting.commailto:standa...@nczconsulting.com wrote:
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived class. Consider this:
```
class MyPromise extends Promise {}
var p1 = new Promise(function(resolve, reject) {
resolve(42);
});
var p2 = MyPromise.resolve(p1);
p2.then(function(value) {
console.log(value);
});
```
Am I correct in believing that:
1. `p1` is resolved upon being passed to `MyPromise.resolve()`? I
believe this is what happens in 25.4.4.5 Step 6
(http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve)
2. `p2` is an instance of `MyPromise` that is resolved with a promise
value of 42.
Thanks!
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
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: Clarification for derived promises
Awesome, thank you!
-N
On 7/14/2015 10:12 AM, Domenic Denicola wrote:
Yes.
On Tue, Jul 14, 2015 at 10:10 AM -0700, Nicholas C. Zakas
standa...@nczconsulting.com mailto:standa...@nczconsulting.com wrote:
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived class. Consider this:
```
class MyPromise extends Promise {}
var p1 = new Promise(function(resolve, reject) {
resolve(42);
});
var p2 = MyPromise.resolve(p1);
p2.then(function(value) {
console.log(value);
});
```
Am I correct in believing that:
1. `p1` is resolved upon being passed to `MyPromise.resolve()`? I
believe this is what happens in 25.4.4.5 Step 6
(http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve)
2. `p2` is an instance of `MyPromise` that is resolved with a promise
value of 42.
Thanks!
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for statement with index and value
Hi,
And it's called zipWithIndex in Scala:
```scala
for ((value, i) - someTraversable.zipWithIndex) {
// do stuff
}
```
And, in Ruby, it's each_with_index:
```ruby
for value, i in someArray.each_with_index
# do stuff
end
```
I see a pattern, here. It seems several other languages are pretty fine
with a simple method that bundles elements of a collection with their
indices, and then rely on destructuring on the left-hand-side of their for
loop to extract them again, instead of adding additional syntax for this
use case. IMO, that's a strong argument for doing the same thing in ES.
Cheers,
Sébastien
I think there's something
On Tue, Jul 14, 2015 at 8:49 PM, Alexander Jones a...@weej.com wrote:
It's called `enumerate` in Python. And it's trivial to implement:
```js
for (let [i, value] of enumerate(someIterable)) {
// behold...
}
```
On Tuesday, July 14, 2015, Domenic Denicola d...@domenic.me wrote:
From: Tingan Ho [mailto:tinga...@gmail.com]
But they aren't clean solutions to a wildly popular problem.
I disagree.
___
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: for statement with index and value
On Mon, Jul 13, 2015 at 7:13 PM, Tingan Ho tinga...@gmail.com wrote:
Just following a discussion we had on TypeScript
https://github.com/Microsoft/TypeScript/issues/3835
In most times, I just need the value in an array, so I use a for..of loop.
But then, I find out that I need the index too, then I need to rewrite my
whole for loop expression. Happens all the time for me.
I have to ask why there doesn't exist a `for statement` where I can get the
index and value of an array directly? Or for that matter property and value
of an object?
`.forEach` is not ideal since you can't break, break to outer loop and
continue cleanly. Even though you can achieve this with other array methods,
I don't think they are as productive as a for-statement.
What I'm suggesting is augmenting the current syntax for `for..of` loops.
And support an overloading pattern so that we don't need to rewrite the
whole for loop expression to just to get the index when we already getting
the value.
```
// overloads
for (let value, index of values) { ... }
for (let value of values) { ... }
```
PS. Sorry if this has already discussed. Couldn't find any on Google and the
esdiscuss.org page doesn't have any search capabilities.
Kevin provided the built-in answer for arrays, but for arbitrary
iterables, the Python solution is trivial:
function* enumerate(iter) {
let i = 0;
for(let value of iter) {
yield [i, value];
i++
}
}
for(let [i, v] of enumerate(values)) {
...
}
I expect there's already libraries that duplicate all of Python's
itertools and more; the iterator algebra is really trivially hackable.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Clarification for derived promises
And --- apologies for continuing to beat this drum --- you can look at the `prfun` package on npm for a practical example of this use of Promise subclasses and `resolve`. If other folks know of other libraries using these features, let me know so I can recommend other people's code as well as my own. ;) --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fwd: Object.observe deep tree topic
Hi all, Not sure how to start it, so posting here, please correct me if it's misuse of this list. I've looked into a threads of the last year and didn't find any discussion regarding deep Object.observe feature (as well as something like setPath/getPath functionality), and would like to raise it anew or read previous material on it if any. Any advises? Regards, Guller Yuri. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for statement with index and value
If you need the _index of_ a value in an array, there is always...
indexOf ;)
for (let value of values) {
let index = values.indexOf(value);
}
Rick
On Tue, Jul 14, 2015 at 4:16 PM Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jul 13, 2015 at 7:13 PM, Tingan Ho tinga...@gmail.com wrote:
Just following a discussion we had on TypeScript
https://github.com/Microsoft/TypeScript/issues/3835
In most times, I just need the value in an array, so I use a for..of
loop.
But then, I find out that I need the index too, then I need to rewrite my
whole for loop expression. Happens all the time for me.
I have to ask why there doesn't exist a `for statement` where I can get
the
index and value of an array directly? Or for that matter property and
value
of an object?
`.forEach` is not ideal since you can't break, break to outer loop and
continue cleanly. Even though you can achieve this with other array
methods,
I don't think they are as productive as a for-statement.
What I'm suggesting is augmenting the current syntax for `for..of` loops.
And support an overloading pattern so that we don't need to rewrite the
whole for loop expression to just to get the index when we already
getting
the value.
```
// overloads
for (let value, index of values) { ... }
for (let value of values) { ... }
```
PS. Sorry if this has already discussed. Couldn't find any on Google and
the
esdiscuss.org page doesn't have any search capabilities.
Kevin provided the built-in answer for arrays, but for arbitrary
iterables, the Python solution is trivial:
function* enumerate(iter) {
let i = 0;
for(let value of iter) {
yield [i, value];
i++
}
}
for(let [i, v] of enumerate(values)) {
...
}
I expect there's already libraries that duplicate all of Python's
itertools and more; the iterator algebra is really trivially hackable.
~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: for statement with index and value
Thanks for all the suggestion. I think since not many languages supports
this it would be very hard to convince you.
I think I can live with the `for (let [index, value] of arr.entries()) {}`
solution.
One
ons 15 juli 2015 kl 09:02 skrev Rick Waldron waldron.r...@gmail.com:
If you need the _index of_ a value in an array, there is always...
indexOf ;)
for (let value of values) {
let index = values.indexOf(value);
}
Rick
On Tue, Jul 14, 2015 at 4:16 PM Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Jul 13, 2015 at 7:13 PM, Tingan Ho tinga...@gmail.com wrote:
Just following a discussion we had on TypeScript
https://github.com/Microsoft/TypeScript/issues/3835
In most times, I just need the value in an array, so I use a for..of
loop.
But then, I find out that I need the index too, then I need to rewrite
my
whole for loop expression. Happens all the time for me.
I have to ask why there doesn't exist a `for statement` where I can get
the
index and value of an array directly? Or for that matter property and
value
of an object?
`.forEach` is not ideal since you can't break, break to outer loop and
continue cleanly. Even though you can achieve this with other array
methods,
I don't think they are as productive as a for-statement.
What I'm suggesting is augmenting the current syntax for `for..of`
loops.
And support an overloading pattern so that we don't need to rewrite the
whole for loop expression to just to get the index when we already
getting
the value.
```
// overloads
for (let value, index of values) { ... }
for (let value of values) { ... }
```
PS. Sorry if this has already discussed. Couldn't find any on Google
and the
esdiscuss.org page doesn't have any search capabilities.
Kevin provided the built-in answer for arrays, but for arbitrary
iterables, the Python solution is trivial:
function* enumerate(iter) {
let i = 0;
for(let value of iter) {
yield [i, value];
i++
}
}
for(let [i, v] of enumerate(values)) {
...
}
I expect there's already libraries that duplicate all of Python's
itertools and more; the iterator algebra is really trivially hackable.
~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: for statement with index and value
It's called `enumerate` in Python. And it's trivial to implement:
```js
for (let [i, value] of enumerate(someIterable)) {
// behold...
}
```
On Tuesday, July 14, 2015, Domenic Denicola d...@domenic.me wrote:
From: Tingan Ho [mailto:tinga...@gmail.com javascript:;]
But they aren't clean solutions to a wildly popular problem.
I disagree.
___
es-discuss mailing list
es-discuss@mozilla.org javascript:;
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
