Russell Leggett wrote:
On Sat, Mar 10, 2012 at 3:10 PM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Hello,
to see the problem various syntaxes can bring, various crazy code
samples should be written in each of them to see if and how hard can
they be used, and
Add such examples. I made it editable for anyone exactly for that reason - to
add code samples they see as relevant.
Will do
- Russ
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
Herby Vojčík wrote:
It's easy to get on thin ice without the arrow, due to destructuring
parameters vs. array literal expression bodies, unary +/-, leading [ vs.
[] as indexing operator, and of course /. Consider
:x = default_x [x,x*x]
That [ indexes into the default_x
Russell Leggett wrote:
I know it's just bikeshedding, but do you need the - arrow (it is
better visually)? You can as well take arrowless approach but
putting : before every parameter (as I suggested):
// ':' is the clue that this is the start of a short function
Brendan Eich wrote:
Herby Vojčík wrote:
Herby Vojčík wrote:
Possible Smalltalk-inspired precedent is also:
(:x, y) x+y
(:x) (:y) z
(:x) (y) z
(:x) (y) (z)
I think I like this most...
Herby
We've talked about these variations, but they all seem grawlixy or worse
(the C++ pre-11x bug with
On Mar 9, 2012, at 9:45 PM, Brendan Eich wrote:
I originally wrote up
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
and
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
as mutually exclusive alternatives, but changed the framing for the
Jorge wrote:
If short function syntax and block lambdas are mutually exclusive, then the
block lambdas' syntax should be considered as an alternative for short function
syntax, that is, {| params | /* body */ } is a perfectly valid candidate for
short functions, without TCP.
And given that
If Expression covers FormalParameterList then LR(1) is enough -- we'll
know when we see that arrow (or { on same line as the ) before it). This is
considered somewhat future-hostile by some on TC39.
I need to think about cover grammars some more...
(x,y) = {p:x*y} // return an object
Jorge wrote:
If short function syntax and block lambdas are mutually exclusive, then the
block lambdas' syntax should be considered as an alternative for short function
syntax, that is, {| params | /* body */ } is a perfectly valid candidate for
short functions, without TCP.
No, based on
I don't know about implicit return. TC39 wants to avoid it in anything
that looks like a function (body). Does the = distinguish this case
enough? Consider a large body-block.
I can see the problem. I would personally rate this as less potentially
confusing than () = expr, though.
The
Surveying other libraries would be helpful.
Yes - enough guessing - I'll do my best to do some counting with different
libraries (both for DOM and for nodejs) and report back some numbers. Erg
- busy work : )
Surveying is useful in the sense of visually comparing code versions
with/without
I doubt that (simple) statistics are equally useful here, though: the
current
syntax is sufficiently awkward that programmers actively avoid using the
very code patterns that short functions would help to make readable.
Thanks Claus - I understand but I think you're overstating. In any
Like many others, I would like to have very lightweight function definition
and call syntax, because those are the cornerstones of functional
abstraction.
This transcends classical functions, and would ideally include the ability
to
*define*, in userland, many of the control-flow constructs
Honestly, I'm starting to believe that most nay-sayers would get over
block-lambda looking weird at first and learn to really love the benefit it
provides. Sure they might say it looks really bizarre, but they will also
say remember when we had to assign var that = this; or use bind()? The
This may of been beaten to death, so sorry to bring it up again :)
Whenever I've thought of shorter function syntax, I think of a shorter word
for function, nothing else. I honestly don't care what it is, rubyish like
`def` or `fn` or `func` or your pick. I'm mixed about the goal of
shortening
Hello,
to see the problem various syntaxes can bring, various crazy code
samples should be written in each of them to see if and how hard can
they be used, and how it is readable.
I created a little gallery of a few code samples written in a few
proposals presented here, it's in
This may of been beaten to death, so sorry to bring it up again :)
To the extent that design rationales are not recorded on the wiki,
repetition is hard to avoid. There have been just too many variations
in the mailing list archives to make catching up just from there realistic.
Whenever I've
I updated the tool so that it doesn't count function expressions that
reference this (as those aren't suitable for = functions).
http://www.khs4473.com/function-expr-count/
For most of the libraries that I've ran through it, 60-75% of the functions
it scans are of the block type. I haven't run
On Sat, Mar 10, 2012 at 3:10 PM, Herby Vojčík he...@mailbox.sk wrote:
Hello,
to see the problem various syntaxes can bring, various crazy code samples
should be written in each of them to see if and how hard can they be used,
and how it is readable.
I created a little gallery of a few code
Isaac Schlueter wrote:
So, assuming that these two are valid function expressions that mean
roughly the same thing:
a: (x) { return x }
b: function (x) x
and then you might conclude that this is as well:
c: (x) x
So far, so good, I think.
What about these?
d: (x)
Herby Vojčík wrote:
Possible Smalltalk-inspired precedent is also:
(:x, y) x+y
(:x) (:y) z
(:x) (y) z
(:x) (y) (z)
I think I like this most...
Herby
Maybe this could even be competely paren-free (tell me where it breaks):
:x, :y x+y
:x :y z
:x (y) z
:x (y) (z)
Imagine the code
We could add such an ad-hoc-GLR-like algorithm to ECMA-262, but we would
lose the LR(1) (modulo ASI and lookahead restrictions, and the
conventional shift-reduce conflict resolution for dangling else)
validation I wrote about. That's considered unacceptable by TC39 members
who spoke up last
LR(1) is for granddads ; )
This is really sexy.
Question: for ShortFunctionExpression, do we need an additional = form
for this-binding a function body?
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here] {
FunctionBody }
Identifier_opt (
You want non-this-bound callback, too... or do you want to force them to
use function?
Herby
P.S.: I would even see place for non-this bound, InitialValue-based
ones, like fetchers of value, shortcuts for
function () { return this.r; }
Kevin Smith wrote:
LR(1) is for granddads ; )
This
Herby Vojčík wrote:
Herby Vojčík wrote:
Possible Smalltalk-inspired precedent is also:
(:x, y) x+y
(:x) (:y) z
(:x) (y) z
(:x) (y) (z)
I think I like this most...
Herby
We've talked about these variations, but they all seem grawlixy or worse
(the C++ pre-11x bug with template instantiation
Kevin Smith wrote:
LR(1) is for granddads ; )
Knuth. Respect.
This is really sexy.
Question: for ShortFunctionExpression, do we need an additional =
form for this-binding a function body?
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here]
{
Kevin Smith wrote:
InitialValue :
AssignmentExpression
ShortFunctionExpression
This avoids precedence inversion and restricts short function
expressions to appearing unparenthesized only where initial values may
occur today (in array and object literals, in argument lists, on the
right
If the shorter syntax is derived from function's body-plan we do not
want arbitrary TCP creep. I think Alex Russell made this point at a TC39
meeting last year (regarding HoBD hash functions). Shorter syntax is
just syntax, anything novel (=) can change semantics too, with more
novelty or
Knuth. Respect.
For sure - LR parsing still blows my mind (looks for his trusty dragon book
- here it is!).
We could do that and leave the arrow-free form with unbound |this|. Better
by my argument that anything based on today's function body-plan should not
start adding TCP conformance --
Kevin Smith wrote:
Knuth. Respect.
For sure - LR parsing still blows my mind (looks for his trusty dragon
book - here it is!).
We could do that and leave the arrow-free form with unbound
|this|. Better by my argument that anything based on today's
function body-plan should
Thanks for throwing out alternative syntaxes. We should keep beating on
this anvil, shorter function syntax is well worth it. But we need a non-GLR
parsing procedure that rejects ambiguous grammars.
So here's my pitch - I've been thinking over a lot of the different
syntaxes that have been
Anyway, I'm still trying to get something for shorter function syntax into
ES6. I think TC39 can yet make an exception if we have our validation story
figured out. That is where to focus fire.
Must it be LR(1), then? I don't think an LR parser can handle short
functions (or arrows) as we've
Sorry for the tl;dr - last post for today...
It occurs to me that we might be able to prove that the language is
something like non-deterministic LR(1). A non-deterministic LR parser
could have shift entries in it's parsing table pointing to more than one
state. When it hits a cell like that,
Kevin Smith wrote:
Anyway, I'm still trying to get something for shorter function
syntax into ES6. I think TC39 can yet make an exception if we have
our validation story figured out. That is where to focus fire.
Must it be LR(1), then? I don't think an LR parser can handle short
Russell Leggett wrote:
Thanks for throwing out alternative syntaxes. We should keep beating
on this anvil, shorter function syntax is well worth it. But we need
a non-GLR parsing procedure that rejects ambiguous grammars.
So here's my pitch - I've been thinking over a lot of the
Brendan Eich wrote:
If we buy into the cover grammar approach, used so far in ES6 drafts
(see Supplemental Syntax), then we still have some trouble if we want
to prefer
(x,y) = {p:x*y} // return an object literal
over parsing the body as a block statement. The problem is that the p:
looks
I know it's just bikeshedding, but do you need the - arrow (it is better
visually)? You can as well take arrowless approach but putting : before
every parameter (as I suggested):
// ':' is the clue that this is the start of a short function
coll.map(:x - x*x) //function(x){ return
Herby Vojčík wrote:
Russell Leggett wrote:
Thanks for throwing out alternative syntaxes. We should keep beating
on this anvil, shorter function syntax is well worth it. But we need
a non-GLR parsing procedure that rejects ambiguous grammars.
So here's my pitch - I've been
Another lingering objection to arrows is this-binding (= vs. -).
*If* it is possible to make 'function'-free functions work, then how
about dropping the implicit bindings for 'arguments' and 'this' for
the short form? Then the 'function' keyword would be a modifier
on the short form, to
Claus Reinke wrote:
*If* it is possible to make 'function'-free functions work, then how
about dropping the implicit bindings for 'arguments' and 'this' for
the short form? Then the 'function' keyword would be a modifier
on the short form, to re-introduce these implicit bindings.
That would
Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close with
anonymous functions, you'll never get there, because someone will want to
use 'return' or 'break' or 'throw' and the behavior is all screwed up (as
we
Russell Leggett wrote:
Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close
with anonymous functions, you'll never get there, because someone will
want to use 'return' or 'break' or 'throw' and the
On Thu, Mar 8, 2012 at 8:43 AM, Herby Vojčík he...@mailbox.sk wrote:
Russell Leggett wrote:
Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close
with anonymous functions, you'll never get there,
Thank you for the explanations. Block lambda syntax with pipes makes more
sense to me now. Given that most of the stuff I do is asynchronous though,
I personally would prioritize the semantics this way:
1. Short function syntax with lexical this.
4. Block lambdas with TCP return.
Thanks
I was thinking and playing with something similar ... here an example:
http://www.3site.eu/functionize/
Looks like the function keyword could actually be dropped easily without
compromising the syntax too much.
That is just a test, but it looks OKish to me
br
On Thu, Mar 8, 2012 at 9:35 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I was thinking and playing with something similar ... here an example:
http://www.3site.eu/functionize/
Looks like the function keyword could actually be dropped easily without
compromising the syntax too
On Wed, Mar 7, 2012 at 8:31 PM, Kevin Smith khs4...@gmail.com wrote:
// Or
() = expr
You don't need TCP here, since there is no return. Bound this would be
nice, since it is a new form that can't break existing code.
--
John A. Tamplin
Software Engineer (GWT), Google
Bound this would be nice, since it is a new form that can't break existing
code.
Yes - I think this could be pretty excellent - no pun intended. I think
think it would be a great compromise between current functions and full TCP.
- Russ
--
John A. Tamplin
Software Engineer (GWT),
If I understand correctly, it's still an open question whether parsing ()
= {} is feasible or not using a recursive top-down parser.
Is that right?
kevin
On Thu, Mar 8, 2012 at 10:46 AM, Russell Leggett
russell.legg...@gmail.comwrote:
Bound this would be nice, since it is a new form that
Russell Leggett wrote:
Bound this would be nice, since it is a new form that can't break
existing code.
Yes - I think this could be pretty excellent - no pun intended. I
think think it would be a great compromise between current functions
and full TCP.
Again, it's a bad idea to
IIRC, fn for functions (as a breaking change) was in the running, at some
point. Is it still?
On Mar 8, 2012, at 18:59 , Brendan Eich wrote:
Russell Leggett wrote:
Bound this would be nice, since it is a new form that can't break
existing code.
Yes - I think this could be pretty
Kevin Smith wrote:
If I understand correctly, it's still an open question whether parsing
() = {} is feasible or not using a recursive top-down parser.
Is that right?
No. Top down parsers can be hacked to do a great many things. What we
seek is a grammar that can be parsed by a
Then you really have three somewhat modest proposals:
1. optional function.
2. braceless functions that auto-return the completion value of the
expression and exhibit TCP freakdeekness.
3. do-expressions blocks that evaluate to their completion value.
These three seem to combine to let you do
Aymeric Vitte wrote:
Indeed it looks more intuitive than block lambdas (IMHO).
Intuitions vary, but why does
function huh(a, b) {
let toss = () do{return a*b};
downward(toss);
return 42;
}
where downward, if it calls its argument, forces a return of a*b from
huh, and control never
On Thu, Mar 8, 2012 at 1:08 PM, Brendan Eich bren...@mozilla.org wrote:
Another which I cited just a few messages back: parsing ( params ) as (
expr ), as any top down parser must until it gets to an arrow or other
distinguishing token ({ on same line as ), e.g.), can be considered
I forgot to mention that the call to () do {...} should work as written
in 11.1.7 in block_lambda_revival (if not my second example does not
work), so the behavior is supposed to be the same (if
[[FormalParameters]] is empty), I was more focused on the this stuff
(do examples 1 and 3 look
Thanks for the clear explanation, Brendan - I think I understand the
concerns now. And if not, I don't mind looking foolish : )
I just looked at the code for the Dart parser and it basically queues
tokens until it finds the matching right paren (recursively counting nested
parens). It peeks at
I think we can use a modification of the Dart technique to parse =
functions:
On encountering ( in a context where an expression is acceptable, you can
try to parse it as ( Expression ) or as ( FormalParameterList ).
Attempt to parse it as a formal parameter list, enqueuing each token
So, assuming that these two are valid function expressions that mean
roughly the same thing:
a: (x) { return x }
b: function (x) x
and then you might conclude that this is as well:
c: (x) x
So far, so good, I think.
What about these?
d: (x) (y)
e: (x) (y) { return z }
I'm a little bit confused here. Wasn't arrow syntax (args) - expr
shot down earlier because it is too difficult to parse for both human
and machine? I don't understand how (args) expr can possibly be any
better in this regard. (And I don't believe that a mandatory function
name in front, like
On Wed, Mar 7, 2012 at 4:41 AM, Andreas Rossberg rossb...@google.comwrote:
I'm a little bit confused here. Wasn't arrow syntax (args) - expr
shot down earlier because it is too difficult to parse for both human
and machine? I don't understand how (args) expr can possibly be any
better in this
David Herman wrote:
To be clear: what I'm suggesting is that expression closures would
*not* be syntactic sugar for statement bodies, but rather would be
TCP-respecting. Most of the time this wouldn't even be noticeable,
until you use do-expressions.
I'm not sure do expression syntax is
On Wed, Mar 7, 2012 at 11:11 AM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
To be clear: what I'm suggesting is that expression closures would *not*
be syntactic sugar for statement bodies, but rather would be
TCP-respecting. Most of the time this wouldn't even be
Gavin Barraclough wrote:
On Mar 7, 2012, at 8:35 AM, Rick Waldron wrote:
Honestly, I'm starting to believe that most nay-sayers would get over block-lambda looking weird at
first and learn to really love the benefit it provides. Sure they might say it looks really
bizarre, but they will also
This might be a dumb question: TCP = this-context preservation?
(Sorry, my brain has that acronym hard-linked to Transport Control
Protocol and I keep getting confused.)
On Wed, Mar 7, 2012 at 13:01, Gavin Barraclough barraclo...@apple.com wrote:
But (modulo separate do TCP proposal of
On Wed, Mar 7, 2012 at 4:56 PM, Isaac Schlueter i...@izs.me wrote:
This might be a dumb question: TCP = this-context preservation?
(Sorry, my brain has that acronym hard-linked to Transport Control
Protocol and I keep getting confused.)
TCP = Tennent's Correspondence Principle
Yehuda Katz
(weighing in just as a developer...)
So this is pretty consistent with the language and would be easy to explain
to current and future developers:
// Short function, familiar rules:
() {
// ..
}
// Lexical this, tcp and all that
() = {
// ..
}
// Or
() = expr
Pipes are fine in and of
I believe is has effectively been added under the more constrained object
literal extensions
http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
On Tue, Mar 6, 2012 at 12:50 PM, Isaac Schlueter i...@izs.me wrote:
A great many letters have been typed regarding the number of letters
On Tue, Mar 6, 2012 at 6:50 PM, Isaac Schlueter i...@izs.me wrote:
A great many letters have been typed regarding the number of letters in the
word function.
What if we just made the keyword function entirely optional, dart-style?
ShortNamedFunctionDeclaration :Identifier no_linebreak (
On Tue, Mar 6, 2012 at 10:07, Thaddee Tyl thaddee@gmail.com wrote:
An interesting property of this syntax is that anonymous functions can
be written this way:
myList.forEach(λ (item) { doWith(item) })
(it can also be `lambda (item) { ... }`)
Yes, any valid function identifier could
This approach requires a restriction: [no LineTerminator here] between
the ) and the {:
js function f(a,b,c){return a*b+c}
js var x=2,y=3,z=4,w
js f(x,y,z) {
typein:3: SyntaxError: missing ; before statement:
typein:3: f(x,y,z) {
typein:3: .^
js eval(w=f(x,y,z)\n{print(w)})
10
(That
On Tue, Mar 6, 2012 at 10:53, Brendan Eich bren...@mozilla.org wrote:
This approach requires a restriction: [no LineTerminator here] between the
) and the {:
Yes, I did put that in the OP, but it looks like my mail client helpfully
wrapped at that point, which is a bit confusing :)
Leaving
Isaac Schlueter wrote:
On Tue, Mar 6, 2012 at 10:53, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
This approach requires a restriction: [no LineTerminator here]
between the ) and the {:
Yes, I did put that in the OP, but it looks like my mail client
helpfully
On Tue, Mar 6, 2012 at 12:06, Brendan Eich bren...@mozilla.org wrote:
Yes, an identifier is required. It would not be possible to define an
unnamed function in this way.
Why not express an anonymous function, though? Definition != expression. As
usual, an expression *statement* could not
Brendan Eich wrote:
Yes, an identifier is required. It would not be possible to define
an unnamed function in this way.
Why not express an anonymous function, though? Definition !=
expression. As usual, an expression *statement* could not start with (
and consist entirely of a
A few months ago, I made this same suggestion, here:
http://www.mail-archive.com/es-discuss@mozilla.org/msg07021.html
And David Herman very succintly explained here:
http://www.mail-archive.com/es-discuss@mozilla.org/msg07031.html
Rick
On Tue, Mar 6, 2012 at 3:21 PM, Brendan Eich
Isaac Schlueter wrote:
I see. So, you'd be suggesting using:
( args ) { functionBody }
as an anonymous function expression, though not a function expression
statement?
Right, see followup. The grammar without lookahead restrictions is
ambiguous. See ES5,
12.4 Expression Statement
I know, that's why I wrote that a [no LineTerminator here] restricted
production would be required (which I just forgot to include in my
mini-grammar sent to Isaac, guh).
Dave assumed we wouldn't add such a restriction. But if we do, then
there's no backward incompatibility because right now
Brendan Eich wrote:
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) { FunctionBody }
Identifier_opt ( FormalParameterList_opt ) IniitialValue
Let's try that again:
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here]
{
I'd suggest dropping the
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here]
IniitialValue
production. Wouldn't that mean that you could have something like this?
var allA = list.map(() a)
I think the curly braces are ok here. Hated keywords should be
attacked one at a
Isaac Schlueter wrote:
I'd suggest dropping the
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here]
IniitialValue
production. Wouldn't that mean that you could have something like this?
var allA = list.map(() a)
I think the curly braces are ok here. Hated keywords
On Mar 6, 2012, at 12:37 PM, Brendan Eich wrote:
Isaac Schlueter wrote:
Certainly, this is quite nice:
myList.forEach((item) { .. })
Less nice for map because of the hated six-letter keyword, but yeah.
What if the anonymous form didn't require `return`, i.e., used the body's
Just replied to Isaac on this. We run into the completion-value leak
objection and I do not see a way around it.
/be
David Herman wrote:
On Mar 6, 2012, at 12:37 PM, Brendan Eich wrote:
Isaac Schlueter wrote:
Certainly, this is quite nice:
myList.forEach((item) { .. })
Less nice
On Mar 6, 2012, at 1:50 PM, Brendan Eich wrote:
Just replied to Isaac on this. We run into the completion-value leak
objection and I do not see a way around it.
One way around it is to question the hazard. :)
Seriously, whether
{|x| f() }
or
(x) { f() }
is more likely to be an
David Herman wrote:
On Mar 6, 2012, at 1:50 PM, Brendan Eich wrote:
Just replied to Isaac on this. We run into the completion-value leak objection
and I do not see a way around it.
One way around it is to question the hazard. :)
Seriously, whether
{|x| f() }
or
(x) { f() }
is
From: Brendan Eich
From: Isaac Schlueter
Yes, an identifier is required. It would not be possible to define an
unnamed function in this way.
Why not express an anonymous function, though? Definition != expression. As
usual, an expression *statement* could not start with ( and consist
On Mar 6, 2012, at 1:55 PM, Brendan Eich wrote:
The risk here may be small but people have run into it before in CL and other
LISPs and expression languages. It's a bit scary in JS, what with OCAP the
fundamental security model. So I don't think we should treat it lightly and
TC39 has not,
Thaddee Tyl wrote:
From: Brendan Eich
From: Isaac Schlueter
Yes, an identifier is required. It would not be possible to define an
unnamed function in this way.
Why not express an anonymous function, though? Definition != expression. As
usual, an expression *statement* could not start with (
On Tue, Mar 6, 2012 at 5:14 PM, David Herman dher...@mozilla.com wrote:
On Mar 6, 2012, at 1:55 PM, Brendan Eich wrote:
The risk here may be small but people have run into it before in CL and
other LISPs and expression languages. It's a bit scary in JS, what with
OCAP the fundamental
David Herman wrote:
On Mar 6, 2012, at 1:55 PM, Brendan Eich wrote:
The risk here may be small but people have run into it before in CL and other
LISPs and expression languages. It's a bit scary in JS, what with OCAP the
fundamental security model. So I don't think we should treat it lightly
On Mar 6, 2012, at 2:30 PM, Rick Waldron wrote:
Here's where the foot goes in the mouth... Why couldn't ()[no
LineTerminatorHere]{} be used with block lambda's semantics?
I'm sayin'. :)
Seriously, though, Brendan's objecting (as MarkM has in the past) that
(x) { f(x); }
is more likely
On Mar 6, 2012, at 2:37 PM, Brendan Eich wrote:
You didn't show the expression-bodied variant:
myList.map((x) x + 1)
which is even shorter, if it's doable at all (I haven't worked out a good
grammar yet).
That's actually a pretty good space to aim at, IMO. I conjecture the majority
David Herman wrote:
On Mar 6, 2012, at 2:37 PM, Brendan Eich wrote:
You didn't show the expression-bodied variant:
myList.map((x) x + 1)
which is even shorter, if it's doable at all (I haven't worked out a good
grammar yet).
That's actually a pretty good space to aim at, IMO. I
On Mar 6, 2012, at 2:56 PM, Brendan Eich wrote:
David Herman wrote:
Moreover, if you wanted to do some control along with an expression, you
could use do-expressions:
myList.map((x) do { for (...) { ... } f(x) })
Note that combination (expression closures + do-expressions) brings
](...args));
},
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of David Herman
Sent: Tuesday, March 06, 2012 17:58
To: Brendan Eich
Cc: es-discuss
Subject: Re: optional function keyword
On Mar 6, 2012, at 2:56 PM, Brendan Eich wrote:
David Herman wrote
95 matches
Mail list logo
