> I don't think this flies anyway. It has to be more like a function body,
otherwise var and function declarations would hoist out of it, which would
be insane IMO.
Agreed.
> Also, I really would want to avoid examples like [..]
Agreed.
> IIUC, the goal here is to allow a sequence of statements to
Kevin Smith wrote:
We should adapt Crock's recommended paren style to arrow IIFEs, to
whit (()={...whatever...}()), even though this looses a bit more
brevity.
I believe this is required by the grammar anyway.
No, what is required is
(() = {...whatever...})()
Arrow function
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
Right, I misread Mark's code sample.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
You read my sample right. The mistake was mine, and the parens should be
places where Brendan shows.
On Fri, Jan 10, 2014 at 5:48 PM, Kevin Smith zenpars...@gmail.com wrote:
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
On 8 January 2014 17:32, Mark S. Miller erig...@google.com wrote:
On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg rossb...@google.com
wrote:
On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Unless we can identify real implementation issues, the semantics of
do { }
On 8 January 2014 18:04, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You should be able to put a 'do' in front of any BlockStatement and turn it
into an ExpressionStatement.
I don't think we should have a new expression level scoping construct that
doesn't have the exact semantics of a
I may warm up to the extra complexity more easily if somebody could
present at least some compelling use cases. :)
Mark's mention of yield got me thinking about await expressions. Hopefully
I'm using this correctly:
// stat is null or a Stat object
const stat = do { try { await
On Thu, Jan 9, 2014 at 6:18 AM, Andreas Rossberg rossb...@google.comwrote:
On 8 January 2014 17:32, Mark S. Miller erig...@google.com wrote:
On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg rossb...@google.com
wrote:
On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I do have one usability concern with arrow IIFEs. I hate when I see them
written as ()={...whatever...}() because you don't know that it's an IIFE
until the end. Function expressions have the same issue. We should adapt
Crock's recommended paren style to arrow IIFEs, to whit
On Jan 9, 2014, at 6:21 AM, Andreas Rossberg wrote:
On 8 January 2014 18:04, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You should be able to put a 'do' in front of any BlockStatement and turn it
into an ExpressionStatement.
I don't think we should have a new expression level scoping
On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Unless we can identify real implementation issues, the semantics of
do { }
should simply be those of a blocks.
I don't think this flies anyway. It has to be more like a function
body, otherwise var and function
If all you want is a non verbose IIFE, use an arrow function. We should
consider do expressions only if they avoid the TCP violations of strict
arrow IIFEs.
On Wed, Jan 8, 2014 at 6:51 AM, Kevin Smith zenpars...@gmail.com wrote:
Since do-as-IIFE carries with it a subset of the semantics
On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg rossb...@google.comwrote:
On 7 January 2014 20:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Unless we can identify real implementation issues, the semantics of
do { }
should simply be those of a blocks.
I don't think this flies
arrow function works by accident better than just function thanks to its
trapped context. Still bugs me by design we need to create garbage,
including one-shot functions, in order to inline a try/catch to assign to a
single pointer
```javascript
const ES6_PROXY = ()={
try {
new
On Jan 8, 2014, at 8:32 AM, Mark S. Miller wrote:
If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions,
IIFEs are already a lot shorter. The extra brevity of do expressions is not
worth it.
What would make do expressions worthy of consideration is if they repaired
Please note that you do not really create a one-shot function and garbage in
this case, at least if the compiler does his job well. The F# compiler, and
probably many functional language compilers, would correctly inline the lambda
function here.
There’s probably no reason a JavaScript
I still need to think in terms of creating garbage ... being unaware of
optimizations behind the scene.
I like to believe compilers should help optimizing for me instead of me
developing to simplify compilers job so despite how complicated would be
behind the scene I meant a `do { try/catch }`
If all you want is a non verbose IIFE, use an arrow function. We should
consider do expressions only if they avoid the TCP violations of strict
arrow IIFEs.
One could say that they are verbose:
var x = (_= { /* some statements, with a return statement somewhere */
})();
vs.
var x =
On 6 January 2014 17:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The major new complication of do-expressions is that they allow for the
occurrence of break/continue/return abrupt completions in contexts such as
for loop heads where they could not perviously occur. However,
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
Always a good reason in the abstract, but concrete use cases have
arisen, even in this thread. As you noted just last month (!),
For ES7 I would
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
/Andreas
On 7 January 2014 17:10, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that
On 7 January 2014 17:19, Andreas Rossberg rossb...@google.com wrote:
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
And just to be extra-clear: by that I'm only referring to free
occurrences of those, that
On Jan 7, 2014, at 8:22 AM, Andreas Rossberg wrote:
On 7 January 2014 17:19, Andreas Rossberg rossb...@google.com wrote:
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
And just to be extra-clear: by that
David Herman wrote:
On Dec 20, 2013, at 5:32 AM, Andreas Rossbergrossb...@google.com wrote:
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting)
Glad to hear you're in favor! I'll be happy to co-champion.
I will support your prospective
On Jan 6, 2014, at 8:10 AM, Brendan Eich bren...@mozilla.com wrote:
To further constrain design (since design is mostly about leaving things
out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let
blocks and let expressions, which came up recently. We should not revive
David Herman wrote:
On Jan 6, 2014, at 8:10 AM, Brendan Eichbren...@mozilla.com wrote:
To further constrain design (since design is mostly about leaving things
out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let blocks
and let expressions, which came up recently. We
On Jan 6, 2014, at 8:10 AM, Brendan Eich wrote:
David Herman wrote:
On Dec 20, 2013, at 5:32 AM, Andreas Rossbergrossb...@google.com wrote:
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting)
Glad to hear you're in favor! I'll be happy to
Allen Wirfs-Brock wrote:
I had been considering purging that handling from the ES6 spec. but maybe I'll
leave it in.
Please do! This dates from block-lambda future-proofing days? I dimly
recall ES1 drafts having full completion-type abstraction (over all
forms, not just statements but also
Le 20 déc. 2013 à 08:36, Andrea Giammarchi andrea.giammar...@gmail.com a
écrit :
as side note: in node.js using --harmony flag ... what a developer should do
there to understand that a partially non standard version of Proxy is there
instead of the real one?
Let's imagine I am a
On 20 December 2013 04:05, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
why is this not possible, giving the ability to understand through typeof
if there is a value or not?
```javascript
// defined as const
// reserved in this scope
// but not assigned yet
const
Your C comparison was apples-to-oranges, #ifdef is evaluated at compile
time.
On Fri, Dec 20, 2013 at 8:32 AM, Andreas Rossberg rossb...@google.comwrote:
On 20 December 2013 04:05, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
why is this not possible, giving the
No, that was to underline it is possible to define this twice
static int const NAME =
On Fri, Dec 20, 2013 at 8:49 AM, J B por...@gmail.com wrote:
Your C comparison was apples-to-oranges, #ifdef is evaluated at compile
time.
On Fri, Dec 20, 2013 at 8:32 AM, Andreas Rossberg
early send ... again:
That was to underline it is possible to define the constant twice, in two
blocks, and use that later on as defined in one of those blocks.
In current specs this is not possible.
As Brendan mentioned about runtime checking for an uninitialized (not
same as undefined), I
many launches --harmony by default with node, many others surf the web on
the edge. I don't want to tell anyone what to do in order to use a library,
they know experimental is experimental, and as Developer I would like to be
able to feature-detect experiments or at least know that I am in an
As far as the compiler is concerned it is only defined once. The
preprocessor strips the second const out before the compilation phase.
Let me correct my earlier statement: Your C comparison was
apples-to-oranges, #ifdef is evaluated before compilation.
On Fri, Dec 20, 2013 at 1:02 PM, Andrea
This is not helping ... yeah, apples-to-orange, as you wish .. now to
imagine you have a flexible understanding of the issue and the example I
was proposing so that:
if (stuff) {
const WHATEVER = 1;
} else {
const WHATEVER = 2;
}
two blocks, one const assigned with possibly only one value
On Fri, Dec 20, 2013 at 2:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This is not helping ... yeah, apples-to-orange, as you wish .. now to
imagine you have a flexible understanding of the issue and the example I
was proposing so that:
if (stuff) {
const WHATEVER = 1;
}
I am suggesting that const should:
1. reserve the const name for the whole scope (similar to var)
2. if assigned, keep that value and throw if re-assigned
3. if not assigned, having the very first assignment seal the deal and
throw to any other re-assignment attempt
In JS code, so we
On Fri, Dec 20, 2013 at 2:25 PM, Dean Landolt d...@deanlandolt.com wrote:
On Fri, Dec 20, 2013 at 2:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
This is not helping ... yeah, apples-to-orange, as you wish .. now to
imagine you have a flexible understanding of the issue and
Andrea Giammarchi wrote:
I am suggesting that const should:
1. reserve the const name for the whole scope (similar to var)
2. if assigned, keep that value and throw if re-assigned
3. if not assigned, having the very first assignment seal the deal
and throw to any other re-assignment
I know SpiderMonkey was doing that and yes, too many topics here, apologies.
I just wanted to understand the rational for not having that behavior since
I would not define a const inside a for loop but maybe somebody would do
that.
Anyway, got it, nothing will change, it would be very cool to
On Dec 20, 2013, at 5:29 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Anyway, got it, nothing will change, it would be very cool to think about
improving try/catch logic in any case, but that's another topic.
It is a good use-case for do expressions, for sure.
/be
On Thu, Dec 19, 2013 at 3:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
It seems that I need to create N amount of garbage by design.
This does not work, the const has already been defined:
```javascript
try {
new Proxy({},{});
const ES6_PROXY = true;
} catch(o_O) {
On Thu, Dec 19, 2013 at 5:34 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Dec 19, 2013 at 3:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
It seems that I need to create N amount of garbage by design.
This does not work, the const has already been defined:
Rick thanks but I wasn't strictly asking for solutions because I have one,
I was rather pointing at the fact that there is no solution and by design
we need to create garbage.
Your last example talks itself ... why do we need to define another
variable in that scope? That is annoying, imho ... I
On Thu, Dec 19, 2013 at 6:18 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Rick thanks but I wasn't strictly asking for solutions because I have one,
I was rather pointing at the fact that there is no solution and by design
we need to create garbage.
Your last example talks
it's not invalind, it's what I am talking about.
There is no way to conditionally define constants if not through an inline
ternary or a returned value from a closure otherwise, by design, a second
variable (garbage, pointless hoisting pollution) is mandatory.
The only way to avoid this is to
quick recap:
why is this not possible, giving the ability to understand through typeof
if there is a value or not?
```javascript
// defined as const
// reserved in this scope
// but not assigned yet
const WHATEVER;
if (condition) {
// first come, first serves
WHATEVER = 123;
// that's it!
Andrea Giammarchi wrote:
why is this not possible, giving the ability to understand through
typeof if there is a value or not?
```javascript
// defined as const
// reserved in this scope
// but not assigned yet
const WHATEVER;
if (condition) {
// first come, first serves
WHATEVER = 123;
thanks for the exhaustive answer, useful and more than appreciated.
The example was addressing one problem, the need for an extra variable, and
was not meant to represent the best way to detect if the Proxy was the
meant one.
About this, since you pointed that out, I'll come back on vendor
as side note: in node.js using --harmony flag ... what a developer should
do there to understand that a partially non standard version of Proxy is
there instead of the real one?
Let's imagine I am a client/server library author ... just for a second,
I'd like to grant one behaviour across
51 matches
Mail list logo
