aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
-Message d'origine-
From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 8:54 AM
To: David Herman
Cc: es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 11:43
Soshnikov
Sent: Friday, November 11, 2011 8:54 AM
To: David Herman
Cc: es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 11:43, David Herman wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by
the grammar (though, have to check more precisely
everything is expression approach for JS. After Erlang I very often
miss this possibility.
The idea is to make most of current complex statements as expressions.
Dave mentioned the proposal with `do { ... }` -- yeah, it's fine, but
much nicer is to have all of them as expressions. CoffeeScript
adopted
: Friday, November 11, 2011 10:42 AM
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 13:26, François REMY wrote:
aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
I noted
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message,
there seems to be an ambiguity with object initializers (not only visual but
,
(unfortunately Twitter is again doesn't fit for a more than 140 ch
discussion, so moving here)
I'd like to still notice the possibility of accepting the almost
everything is expression approach for JS. After Erlang I very often
miss this possibility.
The idea is to make most of current complex
);
Dmitry.
-Message d'origine- From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 10:42 AM
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 13:26, François REMY wrote:
aside note
let x = q ? 10 : 20;
Why we're
On 11.11.2011 14:52, Axel Rauschmayer wrote:
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message, there
seems to be an ambiguity with object
IIRC: Block lambdas.
var C = {|| // note the double pipe
let something;
// |this| is the global object
// ...
return something;
}
This contradicts TCP though. E.g. Ruby supports it and there we can't
`return` from blocks, since block wrapping should not be treated
: (Almost) everything is expression
On 11.11.2011 14:44, François REMY wrote:
I didn't read your first mail, I've to acknowledge. That doesn't change
the fact the sample was reinventing the wheel.
I still don't see how your this sentence helps taking into account that
I myself noted this case
11/11/2011 08:07, Dmitry Soshnikov :
Hi,
(unfortunately Twitter is again doesn't fit for a more than 140 ch
discussion, so moving here)
I'd like to still notice the possibility of accepting the almost
everything is expression approach for JS. After Erlang I very often miss
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 14:44, François REMY wrote:
I didn't read your first mail, I've to acknowledge. That doesn't
change the fact the sample was reinventing the wheel.
I still don't see how your
On 11 November 2011 12:48, François REMY fremycompany_...@yahoo.fr wrote:
I think you strongly underestimate the distinction problem. It's *not*
possible to make any difference between the foo statement and the print
statement of your sample, from the compiler point of view. Why would the
foo
On 11.11.2011 16:03, gaz Heyes wrote:
11/11/2011 08:07, Dmitry Soshnikov :
Hi,
(unfortunately Twitter is again doesn't fit for a more than
140 ch discussion, so moving here)
I'd like to still notice the possibility of accepting the
almost everything
2011/11/11 David Herman dher...@mozilla.com:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
It's a serious price, though. Today if I write:
if (q) { ... }
else { ... }
(f())
On Nov 11, 2011, at 3:48 AM, François REMY wrote:
I think you strongly underestimate the distinction problem. ... It's
completelty unclear to me. If there's no way to tell what the return
statement of the block is, there's no way to implement your proposal.
It's actually quite easy to
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = (switch (foo) {
case 10: 100;
default: 200;
});
2. If-expression:
let a = (if (foo) {
print('a is foo');
foo;
} else {
// do some longer stuff
});
3. Try-expressions:
let a = (try {
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = ({
print('doing stuff');
100;
});
Even the last is now easily unambiguous.
And is this not clearer than
let a = {||
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block statement and a object
literal? Surely it becomes an expression once an assignment occurs anyway.
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block statement and a
object literal? Surely it becomes
On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
No, it is a runtime incompatibility that shifts meaning, without errors.
switch (x)
On Nov 11, 2011, at 2:52 AM, Axel Rauschmayer wrote:
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message,
there seems to be an ambiguity with
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block
On Nov 11, 2011, at 7:39 AM, Neil Eades wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = ({
print('doing stuff');
100;
});
Even the last is now easily unambiguous.
On Fri, Nov 11, 2011 at 9:13 AM, David Herman dher...@mozilla.com wrote:
[...]
Hence my do-expressions:
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
or Brendan's subtly-disambiguated-block-statement-expressions:
On Nov 11, 2011, at 9:13 AM, David Herman wrote:
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
On 11.11.2011 20:36, Brendan Eich wrote:
On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the grammar
(though, have to check more precisely), but it can be acceptable price.
No, it is a runtime incompatibility that
On Nov 11, 2011, at 9:50 AM, Allen Wirfs-Brock wrote:
do-expression is a very good solution
Why thank you! ;-)
How gorgeous is that?
not very...
but if I see any of:
let a = do {...
let a = {|| ...
let a = { ...
I immediately know what follows. That is gorgeous...
I'm not
On 11 November 2011 17:13, David Herman dher...@mozilla.com wrote:
Your idea of mandatory parens is still valid (if, IMO, a bit
unsatisfyingly verbose) for most statement forms. It's only the
block-statement-expression that doesn't work. Hence my do-expressions
It should also apply to
On 11 November 2011 18:01, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to work
within expressions since you'd probably want to do:
x=loop:for(i=0;i10;i++){
}
but then what if you do:
On 11.11.2011 21:13, David Herman wrote:
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com
mailto:gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
On 11.11.2011 22:25, gaz Heyes wrote:
On 11 November 2011 18:01, Dmitry Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to
work within
On 11 November 2011 18:29, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
This is why the topic is called *(Almost)* everything In general
case we may not include this case with label-statement into proposal, since
the construction you wrote isn't practice IMO. But, we should consider
On 11.11.2011 22:48, gaz Heyes wrote:
On 11 November 2011 18:29, Dmitry Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
This is why the topic is called *(Almost)* everything In
general case we may not include this case with label-statement
into
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a rhetorical question
meaning that's gorgeous!
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On 11.11.2011 23:44, David Herman wrote:
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a rhetorical question meaning
that's gorgeous!
offtopic
And what does it mean? :) I translated it as how do you like
I would translate How X is that? as that is very X! :)
Dave
On Nov 11, 2011, at 12:26 PM, Dmitry Soshnikov wrote:
On 11.11.2011 23:44, David Herman wrote:
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a
2011/11/11 David Herman dher...@mozilla.com:
On Nov 11, 2011, at 3:48 AM, François REMY wrote:
I think you strongly underestimate the distinction problem. ... It's
completelty unclear to me. If there's no way to tell what the return
statement of the block is, there's no way to implement
On Nov 11, 2011, at 2:51 PM, Mike Samuel wrote:
If statements as expressions goes forward, we should look into
tweaking completion values.
IMHO, a code maintainer who sees
resource = ..., foo(resource)
would expect to be able to wrap the use of resource in a try finally thus
On Nov 11, 2011, at 10:22 AM, gaz Heyes wrote:
On 11 November 2011 17:13, David Herman dher...@mozilla.com wrote:
Your idea of mandatory parens is still valid (if, IMO, a bit unsatisfyingly
verbose) for most statement forms. It's only the block-statement-expression
that doesn't work. Hence
On Nov 11, 2011, at 10:25 AM, gaz Heyes wrote:
On 11 November 2011 18:01, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to work
within expressions since you'd probably want to
Hi,
(unfortunately Twitter is again doesn't fit for a more than 140 ch
discussion, so moving here)
I'd like to still notice the possibility of accepting the almost
everything is expression approach for JS. After Erlang I very often
miss this possibility.
The idea is to make most
On 11.11.2011 11:07, Dmitry Soshnikov wrote:
P.S:
Regarding Dave's `do { .. }` -- we may omit `do` and just evaluate the
block.
let a = {
print('doing stuff');
100;
};
It's of course seems ambiguous with an object initialiser (at first
glance), but it's only at first glance. Obviously
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
It's a serious price, though. Today if I write:
if (q) { ... }
else { ... }
(f())
then ASI kicks in after the else body. If we
On 11.11.2011 11:43, David Herman wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the grammar
(though, have to check more precisely), but it can be acceptable price.
It's a serious price, though. Today if I write:
if (q) { ... }
else { ... }
(f())
45 matches
Mail list logo
