> 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
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 wrote:
>
>> No, what is required is
>>
>> (() => {...whatever...})()
>>
>> Arrow function expressions are an AssignmentExpression.
>
>
> Right, I m
>
>
> 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-discu
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
On Jan 9, 2014, at 6:21 AM, Andreas Rossberg wrote:
> On 8 January 2014 18:04, Allen Wirfs-Brock 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 tha
>
>
> 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 Thu, Jan 9, 2014 at 6:18 AM, Andreas Rossberg wrote:
> On 8 January 2014 17:32, Mark S. Miller wrote:
> > On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg
> > wrote:
> >> On 7 January 2014 20:44, Allen Wirfs-Brock
> wrote:
> >> > Unless we can identify real implementation issues, the semanti
>
>
> 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 { awai
On 8 January 2014 18:04, Allen Wirfs-Brock 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 Block.
Except for
On 8 January 2014 17:32, Mark S. Miller wrote:
> On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg
> wrote:
>> On 7 January 2014 20:44, Allen Wirfs-Brock wrote:
>> > Unless we can identify real implementation issues, the semantics of
>> >do { }
>> >
>> > should simply be those of a blocks.
>>
> 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
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 }` w
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 comp
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 repair
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 Proxy({}
On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg wrote:
> On 7 January 2014 20:44, Allen Wirfs-Brock 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
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 wrote:
> Since "do-as-IIFE" carries with it a subset of the semantics carried by
> "do--as-blo
On 7 January 2014 20:44, Allen Wirfs-Brock 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 declarations would hoist
On Jan 7, 2014, at 8:22 AM, Andreas Rossberg wrote:
> On 7 January 2014 17:19, Andreas Rossberg 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 re
On 7 January 2014 17:19, Andreas Rossberg 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 would refer to the
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 wrote:
> Andreas Rossberg wrote:
>>
>> - YAGNI -- I have a hard time coming up with a use case that isn't
>> obfusca
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
On 6 January 2014 17:59, Allen Wirfs-Brock 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,
> do-expressions where still
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 e
On Jan 6, 2014, at 8:10 AM, Brendan Eich wrote:
> David Herman wrote:
>> On Dec 20, 2013, at 5:32 AM, Andreas Rossberg 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-champ
David Herman wrote:
On Jan 6, 2014, at 8:10 AM, Brendan Eich 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
On Jan 6, 2014, at 8:10 AM, Brendan Eich 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
> these, given do e
David Herman wrote:
On Dec 20, 2013, at 5:32 AM, Andreas Rossberg 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 championship ;-).
To further
On Dec 20, 2013, at 5:32 AM, Andreas Rossberg 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. The
const-initializer use case is a good one, but it's also extremely valuable for
code
One of the last (the last?) use cases for IIFEs. Shame it’s too late for ES6,
they will be great to have in ES7.
Axel
On Dec 20, 2013, at 23:39 , Brendan Eich wrote:
> On Dec 20, 2013, at 5:29 PM, Andrea Giammarchi
> wrote:
>> Anyway, got it, nothing will change, it would be very cool to thi
On Dec 20, 2013, at 5:29 PM, Andrea Giammarchi
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
_
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 thi
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 att
On Fri, Dec 20, 2013 at 2:25 PM, Dean Landolt 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 the exam
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 w
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 =
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
No
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
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
exper
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 wo
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 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 wrote:
>
>> On 20 Decembe
Your C comparison was apples-to-oranges, #ifdef is evaluated at compile
time.
On Fri, Dec 20, 2013 at 8:32 AM, Andreas Rossberg wrote:
> On 20 December 2013 04:05, Brendan Eich wrote:
> > Andrea Giammarchi wrote:
> >>
> >> why is this not possible, giving the ability to understand through
> typ
On 20 December 2013 04:05, Brendan Eich 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 WHATE
Le 20 déc. 2013 à 08:36, Andrea Giammarchi 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 client/server library author .
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 platform
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 prefix
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;
/
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! c
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 eva
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
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 d
On Thu, Dec 19, 2013 at 5:34 PM, Rick Waldron wrote:
>
>
>
> 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:
>>
>> ```javascri
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
53 matches
Mail list logo