Re: Block lambda is cool, its syntax isn't
As well as pragmas, macro-expansion would be a possibility!define fn functionundef fnG.On Jan 20, 2012, at 6:40 PM, Brendan Eich wrote: Allen Wirfs-Brock January 20, 2012 5:41 PM At the TC39 meeting we were trying to think of pragma candidates.It wouldn't surprise me if JS programmer would happily trade one:use fn;per file in exchange for being able to use "fn" as a synonym for "function". In terms of character counts, you come out ahead starting with the second function definition.Allen I have considered this in the past. It always seemed too little, due to return. If it enabled another production: AssignmentExpression : fn Identifieropt ( FormalParameterListopt ) AssignmentExpression (or we just added this unconditionally, without the pragma -- but the pragma is good too) then I'd be happy, finally. /be ___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
About 'ƒ': on my keyboard, there's no way to type it. I have to use ALT+its
UTF8 keycode, and it doesn't work in all programs. BTW, since the default
file format on Windows is not UTF8, expect many developers to use ISO-8859-1
for their JS files. Personnaly, I use Notepad++ which allow me to use UTF8
as default encoding, but I don't expect all devs to do that.
About the 'fn' proposal, I'm happy with it. Asking a 'use' statement just
for that feature may prove a little excessive but if it can be merged with
other can-be-breaking syntax reforms ('use es6'), why not. But, seriously,
what really makes it impossible to use # or @? Those would have no compat
issues, would require no header. Even if @ would be used in private-name, it
would be in a completely different context. It's like the SQL guys who used
'%' as wildchar in LIKE strings because '*' was already used as a shortcut
in the SELECT operand; those use of the '*' symbol were completely
orthogonal, and it would have been possible to allow both.
François
-Message d'origine-
From: Jorge
Sent: Saturday, January 21, 2012 4:01 AM
To: es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 02:34, Axel Rauschmayer wrote:
how about ƒ (which has been mentioned many times)? It seems very
appropriate and is even easy to type on a Mac (easier than square brackets
on a German keyboard!).
setTimeout( ƒ () { ... }, 1e3)
setTimeout( `() { ... }, 1e3)
setTimeout( ƒ name () { ... }, 1e3)
setTimeout( `name () { ... }, 1e3)
ƒ name () { ... }
`name () { ... }
--
Jorge.
___
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: Block lambda is cool, its syntax isn't
This seems pretty easy to enforce to me.
function a(x) {
let count = 0;
[
(x+1)^(x-1),
(x*x),
(2*x-1)
];
arr.forEach({|x|
if((x1)==0) count++;
});
return count;
}
-Message d'origine-
From: Brendan Eich
Sent: Saturday, January 21, 2012 2:08 AM
To: François REMY
Cc: es-discuss
Subject: Re: Block lambda is cool, its syntax isn't
Rust is a static language with many guarantees. It's not really
comparable to JS here.
JS extended with block-lambdas has no way to force downward-funarg-only
contract on functions called with block-lambda arguments. And indeed,
nothing goes wrong if those block-lambdas escape via the heap and are
called after the enclosing function's activation, which passed the
block-lambda down, has returned. Only if the block-lambda does a control
effect that would propagate to the enclosing function's activation is
there a dynamic error.
JS is a dynamic language. When you write it should only be allowed,
are you seriously proposing a checkable syntax and static check of some
kind? How would that work?
(Aside: I wish I had used fn instead of function in 1995!)
/be
François REMY mailto:fremycompany_...@yahoo.fr
January 20, 2012 1:38 PM
Just to add weight to my previous mail, you may find it interesting to
notice that my proposed syntax match nearly exactly the proposed syntax of
the new Mozilla-editored Rust programming language:
http://doc.rust-lang.org/doc/tutorial.html#closure-compatibility
call_twice({|| I am a stack closure; });
call_twice(fn@() { I am a boxed closure; });
It confirms my feeling about {|| ...}: it should only be allowed in a
context where the function still exists; it's a way to return the control
back to the calling function when you need to call a callback-able
function for some reason. At every other place, you should use 'normal'
closures (the language-agnostic equivalent of ECMAScript functions), for
which we should have a simplified syntax (aka syntaxic sugar). I don't
bother if it has to start by @, #, %, µ, § or anyting else, but I feel
strongly about the fact we need it.
Now, I think everyone got my point, I leave the final discussion to group
members. But, at least, my message was sent. ;-)
Best regards,
François
François REMY mailto:fremycompany_...@yahoo.fr
January 19, 2012 12:19 PM
It may be just a personnal taste, but I've to agree the current proposal
(#() ...) seems very appealing to me. I did not respond to your mail
proposing to use the Arrow syntax because it seems obscure to me. The
distinction between normal and fat arrow is thin, does not make sense.
You either need a function-object (which doesn't have 'this' mapping, has
expandos) or a local-function (which has 'this' mapping, just need to be a
[Call] target). If you need the first, you need a traditionnal function
since you need something not-frozen that can be added to objects as a
property at a later time. If you want 'this' mapping, you need something
that only makes sense in a local context.
Additionnaly, the arrow syntax is illogical. You usually say I want a
function of (X,Y) which returns X+Y or I want to transform X in
X.toString, not From X, I want to get X.toString().
Freezing a local function seems as acceptable to me as it seemed to
others. A LF should only be used in a controlled context where the
function itself is just used as a function, not an object. But if it's not
acceptable to other members, I'm not against a @(x) syntax that does not
offer frozen functions (but I think it's a missed optimization
opportunity). The point about Conditionnal Compiling in IE is not valid
anymore since Microsoft has deleted HTML Conditionnal Comments because
they were not standards (even if they were used a lot), so I don't think
the obscure and fewly used JScript CC are meant to stay, especially if it
hurts another proposal.
In my view of the thing, a local function should be used as a function in
the mathematical sense of the term: you give a parameter, it returns its
image by the function.
The cases we are trying to solve:
var inc=#(x) x+1;
array.map(#(x) x.toString());
array.filter(#(x) isValid(x));
array.map(#(x) {
while(x.previousSibling) x=x.previousSibling;
return x;
});
For example, I don't see this as a good use-case of a LocalFunction :
...
refreshLayout: function(e) {
...
requestAnimationFrame(#(e) this.refreshLayout(e));
}
...
It should be a block lambda instead, because it's meant to 'continue' the
current function in a sort of async while(true) loop.
...
refreshLayout: function(e) {
...
requestAnimationFrame({|e| this.refreshLayout(e) });
}
...
For all of the use cases where a mathematical function is requied, you
just need some valid [Call]-able item. You will never add expandos on an
function you don't know (ie that you received as a parameter). You'll wrap
it before
Re: Block lambda is cool, its syntax isn't
(sorry, last mail was sent by mistake)
This seems pretty easy to enforce to me.
function a(x) {
let count = 0;
let arr = [
(x+1)^(x-1),
(x*x),
(2*x-1)
]
arr.forEach({|x|
if((x1)==0) count++;
});
return count;
}
can be compiled as :
function a(x) {
let count=0;
let arr = [...];
let $lambda = {
[Call]: {||
...
}
};
arr.forEach($lambda);
$lambda.[Call] = function() { throw new InvalidTargetException(); }
return count;
}
So, if the 'Array.prototype.forEach' function of has been modified to call
the iter function asynchronously, it will not work.
As a plus, it allows a very powerful optimisation (block-lambda running in
the same frame as the function itself).
Regards,
François
-Message d'origine-
From: Brendan Eich
Sent: Saturday, January 21, 2012 7:17 AM
To: Axel Rauschmayer
Cc: es-discuss
Subject: Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 20, 2012 9:24 PM
- Hard to type: reading is far more important than typing, it is very easy
to adapt tools to help with typing.
ƒ is not particularly readable IMHO. It's florin, not mathematical
notation I've ever seen. Anyway we can't assume the compatibility break
is ok since it can occur in operand context in any expression.
- Not ASCII: I hardy every encounter non-UTF text files, any more.
Non-ASCII seems to work well for Fortress.
Fortress, please. I invite @samth to comment now. I admire Fortress, but
it is not an exemplar or nearby language for JS.
I think use fn; (real pragma syntax), with the low-precedence
assignment-expression fn (params) assign-expr production, wins. What do
you think?
Having fn would be sweet. For many kinds of pragmas, it would be great if
one could configure these per project (or per directory). Then one could
put legacy code in one directory and ES6 code in another. And the weight
of the pragmas would be negligible. Not sure how to do this, though;
reminds me very loosely of CSS (centralized management of style).
You make a good point: use fn; may be too much to require in every
script element content.
Would fn make sense as an ES6 breaking change? I’d expect many people to
be strongly in favor, possibly as many strongly opposed.
Don't forget that JQuery uses fn as an identifier (and not just
following a dot) all over.
Possible research (applies to ƒ, too):
- Poll people for their opinion
These are not decisive. I've been straw-polling audiences for a while.
Block-lambdas are doing well, but one must ask nothing, just
'function' and usually get a stronger response than any new syntax.
- Search JS code bases for how often the identifier fn is used (how?).
See JQuery sources. Unconditionally reserving 'fn' is a non-starter
IMHO. Recall also that we are trying to hew to One JavaScript -- few
to no refactoring woes moving code in and out of a module {...}
container or use strict; code block.
/be
___
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: Block lambda is cool, its syntax isn't
François REMY wrote:
About the 'fn' proposal, I'm happy with it. Asking a 'use' statement
just for that feature may prove a little excessive but if it can be
merged with other can-be-breaking syntax reforms ('use es6'), why not.
But, seriously, what really makes it impossible to use # or @? Those
would have no compat issues, would require no header. Even if @ would be
used in private-name, it would be in a completely different context.
It's like the SQL guys who used '%' as wildchar [and may have used *].
True for @, but not so for #. The latter is used to specify freeze. That
is, you probably can write #@(x) {x+1}, but ##(x) {x+1} would be ridiculous.
François
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
I think use fn; (real pragma syntax), with the low-precedence assignment-expression fn (params) assign-expr production, wins. What do you think? Having fn would be sweet. For many kinds of pragmas, it would be great if one could configure these per project (or per directory). Then one could put legacy code in one directory and ES6 code in another. And the weight of the pragmas would be negligible. Not sure how to do this, though; reminds me very loosely of CSS (centralized management of style). You make a good point: use fn; may be too much to require in every script element content. From the Haskell experience again: there, one can have language feature options - as pragmas in source code [1] - as options in package descriptor files [2] The former is better for source readability, and for being specific about which files depend on which extensions. The latter is better for avoiding repetition if every source in a package uses the same set of options, and for package readability (making package feature dependencies obvious without having to scan source files). In-source pragmas override package-wide options. One thing that Haskell doesn't have, which I have often wanted, is the ability to define extension groups on a per-project basis: if I always use the same sets of extensions (eg, yield and block scoping, or modules and classes, or ..), then it would be nice to define pragma groups in the package file, and just refer to the group pragma in the source files. That way, use of language features would be explicit in the source, but without repetitive details. However, this is less of an issue in JS than in Haskell (the latter has far more language extensions, with a very conservative base standard, while all ES extensions currently under discussion will be grouped in ES6). Claus [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html [2] extensions: identifier list A list of Haskell extensions used by every module. Extension names are the constructors of the Extension type. http://hackage.haskell.org/packages/archive/Cabal/1.6.0.3/doc/html/Language-Haskell-Extension.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
(sorry, last mail was sent by mistake)
This seems pretty easy to enforce to me.
function a(x) {
let count = 0;
let arr = [
(x+1)^(x-1),
(x*x),
(2*x-1)
];
arr.forEach({|x|
if((x1)==0) count++;
});
return count;
}
can be compiled as :
function a(x) {
let count=0;
let arr = [...];
let $lambda = {
[Call]: {||
...
}
};
arr.forEach($lambda);
$lambda.[Call] = function() { throw new InvalidTargetException(); }
return count;
}
So, if the 'Array.prototype.forEach' function of has been modified to call
the iter function asynchronously, it will not work.
As a plus, it allows a very powerful optimisation (block-lambda running in
the same frame as the function itself).
Regards,
François
-Message d'origine-
From: Brendan Eich
Sent: Saturday, January 21, 2012 7:17 AM
To: Axel Rauschmayer
Cc: es-discuss
Subject: Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 20, 2012 9:24 PM
- Hard to type: reading is far more important than typing, it is very easy
to adapt tools to help with typing.
ƒ is not particularly readable IMHO. It's florin, not mathematical
notation I've ever seen. Anyway we can't assume the compatibility break
is ok since it can occur in operand context in any expression.
- Not ASCII: I hardy every encounter non-UTF text files, any more.
Non-ASCII seems to work well for Fortress.
Fortress, please. I invite @samth to comment now. I admire Fortress, but
it is not an exemplar or nearby language for JS.
I think use fn; (real pragma syntax), with the low-precedence
assignment-expression fn (params) assign-expr production, wins. What do
you think?
Having fn would be sweet. For many kinds of pragmas, it would be great if
one could configure these per project (or per directory). Then one could
put legacy code in one directory and ES6 code in another. And the weight
of the pragmas would be negligible. Not sure how to do this, though;
reminds me very loosely of CSS (centralized management of style).
You make a good point: use fn; may be too much to require in every
script element content.
Would fn make sense as an ES6 breaking change? I’d expect many people to
be strongly in favor, possibly as many strongly opposed.
Don't forget that JQuery uses fn as an identifier (and not just
following a dot) all over.
Possible research (applies to ƒ, too):
- Poll people for their opinion
These are not decisive. I've been straw-polling audiences for a while.
Block-lambdas are doing well, but one must ask nothing, just
'function' and usually get a stronger response than any new syntax.
- Search JS code bases for how often the identifier fn is used (how?).
See JQuery sources. Unconditionally reserving 'fn' is a non-starter
IMHO. Recall also that we are trying to hew to One JavaScript -- few
to no refactoring woes moving code in and out of a module {...}
container or use strict; code block.
/be
___
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: Block lambda is cool, its syntax isn't
Great stuff. I’m equally intrigued by the `use fn` pragma: It allows one to selectively break compatibility. Caveat: This kind of pragma introduces a lot of new complexity. Pragmas would indeed become less burdensome if one could configure them on a per-project basis. It corresponds to Eclipse setting different Java versions per source directory. Ideas (not sure that they are worth the added complexity, but wanted to mention them): - Meta-tag points to file that configures pragmas based on paths - Custom, user-defined meta-pragmas that group several pragmas - A pragma that points to a file with several pragmas On Jan 21, 2012, at 11:09 , Claus Reinke wrote: From the Haskell experience again: there, one can have language feature options - as pragmas in source code [1] - as options in package descriptor files [2] The former is better for source readability, and for being specific about which files depend on which extensions. The latter is better for avoiding repetition if every source in a package uses the same set of options, and for package readability (making package feature dependencies obvious without having to scan source files). In-source pragmas override package-wide options. One thing that Haskell doesn't have, which I have often wanted, is the ability to define extension groups on a per-project basis: if I always use the same sets of extensions (eg, yield and block scoping, or modules and classes, or ..), then it would be nice to define pragma groups in the package file, and just refer to the group pragma in the source files. That way, use of language features would be explicit in the source, but without repetitive details. However, this is less of an issue in JS than in Haskell (the latter has far more language extensions, with a very conservative base standard, while all ES extensions currently under discussion will be grouped in ES6). Claus [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html [2] extensions: identifier list A list of Haskell extensions used by every module. Extension names are the constructors of the Extension type. http://hackage.haskell.org/packages/archive/Cabal/1.6.0.3/doc/html/Language-Haskell-Extension.html -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 21, 2012 2:14 AM
function a(x) {
let count=0;
let arr = [...];
let $lambda = {
[Call]: {||
...
}
};
arr.forEach($lambda);
$lambda.[Call] = function() { throw new InvalidTargetException(); }
No, we are not specifying dynamic semantics based on a mutation to the
[[Call]] internal property.
I wrote When you write it should only be allowed, are you seriously
proposing a checkable syntax and static check of some kind?
I was alluding to ideas such as Ruby's yield operator, which is the only
way to name the extra downward-funarg-only block argument, preventing
heap escape (but of course, Ruby grew params and so on, so had to deal
with escape anyway).
This is no static check. It is unacceptable both as semantics and in
real implementation costs.
Again, in general a block-lambda that escapes and is called after its
parent function activation has deactivated is not a bug. It should not
be forbidden uncondionally. The only requirement is that control cannot
flow back to the defunct activation. Only such attempts via
break/continue/return will throw.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr January 21, 2012 1:47 AM (sorry, last mail was sent by mistake) You sent your reply twice, to this thread and another. I replied to the other. As a plus, it allows a very powerful optimisation (block-lambda running in the same frame as the function itself). That optimization is possible in any event, and optimizations are not semantics -- they are unobservable. What you are proposing is an unnecessary semantic restriction. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 21, 2012 1:34 AM
About the 'fn' proposal, I'm happy with it. Asking a 'use' statement
just for that feature may prove a little excessive but if it can be
merged with other can-be-breaking syntax reforms ('use es6')
Please read the notes from the tc39 meeting, and the recent threads. We
are not requiring version opt-in. New syntax is its own opt-in.
The problem here is that 'fn' is not new syntax without complex
parsing hacks. It's an unreserved identifier in ES1-5.
why not. But, seriously, what really makes it impossible to use # or @?
We've been over this already. # is for freezing, @ is for private names.
The Matlab precedent of @ for function is quite weak (thanks for
pointing it out).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 05:31, Brendan Eich wrote: Jorge mailto:jo...@jorgechamorro.com January 20, 2012 7:15 PM Sorry, I don't follow, with that you mean something else or the acute accent ? Oh, not ' but the diacritical on é, you mean? Yes, the acute accent. For example. Or something else. You can choose almost any character you want. How do I type that on a US or UK keyboard? I don't know, my keyboard is spanish. Here it's next to the P. We are not going to use non-ASCII characters, so you are still barking up the wrong tree. Aren't you discussing the possibility of using ƒ or λ for functions in this same thread ? Well, the florín is not an ASCII character either. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Jorge mailto:jo...@jorgechamorro.com January 21, 2012 12:14 PM On 21/01/2012, at 05:31, Brendan Eich wrote: We are not going to use non-ASCII characters, so you are still barking up the wrong tree. Aren't you discussing the possibility of using ƒ or λ for functions in this same thread ? No. I shot those down in the thread for several reasons. One is inability to type on many keyboards. Another is incompatibility (these are both identifier characters per ES3-5). Well, the florín is not an ASCII character either. Right! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
-Message d'origine-
From: Brendan Eich
François REMY mailto:fremycompany_...@yahoo.fr
January 21, 2012 1:34 AM
About the 'fn' proposal, I'm happy with it. Asking a 'use' statement
just for that feature may prove a little excessive but if it can be
merged with other can-be-breaking syntax reforms ('use es6')
Please read the notes from the tc39 meeting, and the recent threads. We
are not requiring version opt-in. New syntax is its own opt-in.
The problem here is that 'fn' is not new syntax without complex parsing
hacks. It's an unreserved identifier in ES1-5.
If it's the case, we should avoid that. Avoiding 'use' for the whole syntax
and requiring it just for 'fn' is weird. But I understand we can't use 'fn'
per se since it breaks compat. We should try to find something else (it's
possible, at least).
why not. But, seriously, what really makes it impossible to use # or @?
We've been over this already. # is for freezing, @ is for private names.
The Matlab precedent of @ for function is quite weak (thanks for pointing
it out).
Yes, but you didn't respond about where @ is used in private name, and why
it makes the @() syntax ambiguous with that use. Since the @ is never used
in the private name proposal, I can't check that on my own. My guess is that
they don't collide.
Anyway, there are still other chars left, we should check if they are easy
to type on various keyboards (on my keyboard they are): ['6', '~', 'µ',
'£'].
Regards,
François
(BTW, I got the idea about the un-necessary restriction for out-of-scope {||
...}; instead of making them break, you can restrict them)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 21, 2012 1:00 PM
-Message d'origine- From: Brendan Eich
François REMY mailto:fremycompany_...@yahoo.fr
January 21, 2012 1:34 AM
About the 'fn' proposal, I'm happy with it. Asking a 'use'
statement just for that feature may prove a little excessive but if
it can be merged with other can-be-breaking syntax reforms ('use es6')
Please read the notes from the tc39 meeting, and the recent threads.
We are not requiring version opt-in. New syntax is its own opt-in.
The problem here is that 'fn' is not new syntax without complex
parsing hacks. It's an unreserved identifier in ES1-5.
If it's the case, we should avoid that. Avoiding 'use' for the whole
syntax and requiring it just for 'fn' is weird.
Weird doesn't quite dismiss the idea, since JS has 'function' and a
shorthand for it -- along with a crucial new production adding an
expression-bodied alternative short-function-expression -- is something
users keep requesting. If the goal is to shorten 'function' yet keep a
mnemonic shorter prefix, nothing grawlix will do. Why not 'fn'?
But I understand we can't use 'fn' per se since it breaks compat. We
should try to find something else (it's possible, at least).
Some here are positive on 'fn'. We have been searching for usable
shorter syntax for a while. We should not dismiss 'fn' so quickly.
why not. But, seriously, what really makes it impossible to use #
or @?
We've been over this already. # is for freezing, @ is for private
names. The Matlab precedent of @ for function is quite weak (thanks
for pointing it out).
Yes, but you didn't respond about where @ is used in private name, and
why it makes the @() syntax ambiguous with that use.
You have to follow the strawmen that haven't made it, in particular
http://wiki.ecmascript.org/doku.php?id=strawman:instance_variables
and
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_compositionrev=1305852025#private_state
and es-discuss threads about foo@bar vs. foo.@bar, just @bar for
this-relative addressing, etc.
Since the @ is never used in the private name proposal, I can't check
that on my own. My guess is that they don't collide.
They collide conceptually by overloading @ for two quite different things.
If we want shorter *named* function expression syntax, then they collide
syntactically with a fatal ambiguity absent more restricted productions:
@foo(bar)
{ expr; }
Is this an @-function-expression or a call to private this-relative foo
passing bar?
Anyway, there are still other chars left, we should check if they are
easy to type on various keyboards (on my keyboard they are): ['6',
'~', 'µ', '£'].
Please re-read the recent messages on this thread: no non-ASCII. Also, ~
is in JS already!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
But notice that throughout this, no one advancing a proposal advocated freezing by default. JS developers use function objects as mutable objects. Not just to set .prototype, also to decorate with ad-hoc and meta-data properties. Freezing is not wanted by default. Another example: when defining parser combinators, I've re-defined .toString, to make it easier to identify the parser combination in question during debugging. This would be less of an issue if core JS operations weren't biased towards mutation. If it was easy to create modified function objects without in-place mutation, freezing functions would be more acceptable. Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 19/01/2012, at 22:14, Axel Rauschmayer wrote:
Suggestion: a community-edited page where we collect the rejected syntaxes
(= less running in circles) – simply copying emails (such as yours below)
there would probably suffice.
Has a backtick/accent grave ever been considered and/or rejected ?
Anonymous function expression:
setTimeout( '(){ ... }, 1e3);
Named function expression:
setTimeout( 'name(){ ... }, 1e3);
Declarations:
`(){ ... } // error: can't declare anonymous functions
`name(){ ... }
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
minizers without checking
if ‘this’ is used in the function or not, I guess I can live without that (to
the condition that I can do that: @(this=this, x) this.transform(x)).
I hope I’ve been more clear than in my previous mail,
François
-Message d'origine-
From: Brendan Eich
Sent: Friday, January 20, 2012 12:28 AM
To: François REMY
Cc: Axel Rauschmayer ; Andreas Rossberg ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 19, 2012 12:19 PM
It may be just a personnal taste, but I've to agree the current
proposal (#() ...) seems very appealing to me. I did not respond to
your mail proposing to use the Arrow syntax because it seems obscure
to me. The distinction between normal and fat arrow is thin, does
not make sense.
Agreed, and that is another problem plaguing arrow function syntax as
proposed. But if we rescue it by moving the arrow up front, we may solve
this problem by dropping fat arrow. Shorter function syntax does not
have to include shorter .bind(o) syntax.
You either need a function-object (which doesn't have 'this' mapping,
has expandos) or a local-function (which has 'this' mapping, just need
to be a [Call] target).
We can't guess and I would not assume a local (nested, you mean?)
function wants lexical |this| by default, overridden only by callee-base
|this| when/if the nested function is called as a method. Mark Miller
showed the problem:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018186.html
in reply to
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018183.html
If you need the first, you need a traditionnal function since you need
something not-frozen that can be added to objects as a property at a
later time. If you want 'this' mapping, you need something that only
makes sense in a local context.
You mean a block-lambda? I agree.
Additionnaly, the arrow syntax is illogical. You usually say I want a
function of (X,Y) which returns X+Y or I want to transform X in
X.toString, not From X, I want to get X.toString().
I'm not sure what you mean here by illogical and your verbal
expansions -- are you saying the arrow should come in between params and
body? Yes, that is nicer and Jeremy Ashkenas followed that design (used
in other languages of course) for that reason. But it makes for grammar
trouble for two reasons:
1. (params) looks like a comma expression. We can parse it as such and
then validate it using supplemental syntax as for destructuring, but
it is a bit future-hostile.
2. If we want an expression body alternate syntax that prefers object
literals over body blocks, we have to resolve this conflict:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
Doing so is even more future-hostile in light of the new object literal
extensions in ES6.
Freezing a local function seems as acceptable to me as it seemed to
others. A LF should only be used in a controlled context where the
function itself is just used as a function, not an object. But if it's
not acceptable to other members, I'm not against a @(x) syntax that
does not offer frozen functions (but I think it's a missed
optimization opportunity).
Again, @ is wanted for private names -- all the few unused ASCII
punctuators are wanted. Why are you insisting on @ here? It's not
particularly associated with functions in other languages, or suggestive
of functions.
In my view of the thing, a local function should be used as a function
in the mathematical sense of the term: you give a parameter, it
returns its image by the function.
JS practice varies wildly. No developer consensus on this point.
The cases we are trying to solve:
var inc=#(x) x+1;
array.map(#(x) x.toString());
array.filter(#(x) isValid(x));
array.map(#(x) {
while(x.previousSibling) x=x.previousSibling;
return x;
});
This case is not like the one you showed earlier, and not so clearly bad
for block-lambda. There is only one return, it's at the bottom, so
completion value as implicit return value in a block-lambda wins:
array.map({ |x|
while(x.previousSibling) x=x.previousSibling;
x;
});
It's not a requirement either way, of course.
For example, I don't see this as a good use-case of a LocalFunction :
...
refreshLayout: function(e) {
...
requestAnimationFrame(#(e) this.refreshLayout(e));
}
...
It should be a block lambda instead, because it's meant to 'continue'
the current function in a sort of async while(true) loop.
Oh but here is a case where you advocate a block-lamdba for an async
callback. IIRC earlier you wrote that block-lambdas should be used for
sync callbacks. I may have misread you though.
I dont believe there's a hard and fast rule. Of course, the block-lambda
cannot break/continue/return if the enclosing function activation
Re: Block lambda is cool, its syntax isn't
Jorge mailto:jo...@jorgechamorro.com January 20, 2012 1:22 AM Has a backtick/accent grave ever been considered and/or rejected ? Rejected, that is used by wiki.ecmascript.org/doku.php?id=harmony:quasis already. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Just to add weight to my previous mail, you may find it interesting to
notice that my proposed syntax match nearly exactly the proposed syntax of
the new Mozilla-editored Rust programming language:
http://doc.rust-lang.org/doc/tutorial.html#closure-compatibility
call_twice({|| I am a stack closure; });
call_twice(fn@() { I am a boxed closure; });
It confirms my feeling about {|| ...}: it should only be allowed in a
context where the function still exists; it's a way to return the control
back to the calling function when you need to call a callback-able
function for some reason. At every other place, you should use 'normal'
closures (the language-agnostic equivalent of ECMAScript functions), for
which we should have a simplified syntax (aka syntaxic sugar). I don't
bother if it has to start by @, #, %, µ, § or anyting else, but I feel
strongly about the fact we need it.
Now, I think everyone got my point, I leave the final discussion to group
members. But, at least, my message was sent. ;-)
Best regards,
François
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
to hear more about the specific reasons that led
Arv and Alex think a LF should not be frozen.
Regards,
François
PS: The synax I speak about for LocalFunctions would be:
LocalFunctionExpression:
'#(' argument-list ')' expression
or
'#(' argument-list ') {' statements* '}'
They would be 'bound-this' if there's a 'this' in their body, but can
be left unbounded if there's no since it has no visible effet. If they
don't reference variables of a scope, they should not use reference
scope and may be reused accross function calls.
-Message d'origine- From: Brendan Eich
Sent: Thursday, January 19, 2012 8:27 PM
To: Axel Rauschmayer ; Andreas Rossberg
Cc: François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there is
a completion value leak hazard. TC39 seems to agree the solution there
is something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement. I've
worked on both of these in the context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical issues
that have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable
objects. Not just to set .prototype, also to decorate with ad-hoc and
meta-data properties. Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default.
For merely shorter function syntax, no. Functions are mutable objects
by default in JS. This matters for minifiers, which may not be able to
see all the mutations but would love to use shorter syntax for
'function' syntax, blindly.
/be
Brendan Eich mailto:bren...@mozilla.com
January 19, 2012 11:27 AM
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there
is a completion value leak hazard. TC39 seems to agree the solution
there is something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement.
I've worked on both of these in the context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical
issues that have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable
objects. Not just to set .prototype, also to decorate with ad-hoc and
meta-data properties. Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default.
For merely shorter function syntax, no. Functions are mutable
objects by default in JS. This matters for minifiers, which may not be
able to see all the mutations but would love to use shorter syntax for
'function' syntax, blindly.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98
Re: Block lambda is cool, its syntax isn't
(Aside: I wish I had used fn instead of function in 1995!) How much does the fact that a symbol *could* be used (in theory) matter in practice? Most regexes I see for valid identifiers are still of the ^[a-zA-Z_$][0-9a-zA-Z_$]*$ variety. I’d expect λ to be in use in Greece, but how about ƒ (which has been mentioned many times)? It seems very appropriate and is even easy to type on a Mac (easier than square brackets on a German keyboard!). -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 20, 2012, at 5:08 PM, Brendan Eich wrote: ... (Aside: I wish I had used fn instead of function in 1995!) At the TC39 meeting we were trying to think of pragma candidates. It wouldn't surprise me if JS programmer would happily trade one: use fn; per file in exchange for being able to use fn as a synonym for function. In terms of character counts, you come out ahead starting with the second function definition. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Allen Wirfs-Brock January 20, 2012 5:41 PM At the TC39 meeting we were trying to think of pragma candidates.It wouldn't surprise me if JS programmer would happily trade one:use fn;per file in exchange for being able to use "fn" as a synonym for "function". In terms of character counts, you come out ahead starting with the second function definition.Allen I have considered this in the past. It always seemed too little, due to return. If it enabled another production: AssignmentExpression : fn Identifieropt ( FormalParameterListopt ) AssignmentExpression (or we just added this unconditionally, without the pragma -- but the pragma is good too) then I'd be happy, finally. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 20/01/2012, at 19:17, Brendan Eich wrote:
Jorge mailto:jo...@jorgechamorro.com January 20, 2012 1:22 AM
Has a backtick/accent grave ever been considered and/or rejected ?
Anonymous function expression:
setTimeout( `(){ ... }, 1e3);
Named function expression:
setTimeout( `name(){ ... }, 1e3);
Declarations:
`(){ ... } // error: can't declare anonymous functions
`name(){ ... }
Rejected, that is used by wiki.ecmascript.org/doku.php?id=harmony:quasis
already.
1.- There are not quasi literals in the language yet
2.- quasi literals could as well use something else (the acute accent ?) instead
3.- a shorter function syntax is almost at the top in the programmers' wish
list for ES.next (unlike quasis)
Isn't it -perhaps- too soon to reject ` for functions in favor of quasis ?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Jorge mailto:jo...@jorgechamorro.com January 20, 2012 6:46 PM 1.- There are not quasi literals in the language yet No, quasi-literals are approved for ES6. Already. 2.- quasi literals could as well use something else (the acute accent ?) instead No, that is used for string literals, since JS1 in 1995! 3.- a shorter function syntax is almost at the top in the programmers' wish list for ES.next (unlike quasis) So what? No one except you is asking for ` and quasis won. Please adjust your expecations accordingly. Isn't it -perhaps- too soon to reject ` for functions in favor of quasis ? No. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 02:34, Axel Rauschmayer wrote:
how about ƒ (which has been mentioned many times)? It seems very appropriate
and is even easy to type on a Mac (easier than square brackets on a German
keyboard!).
setTimeout( ƒ () { ... }, 1e3)
setTimeout( `() { ... }, 1e3)
setTimeout( ƒ name () { ... }, 1e3)
setTimeout( `name () { ... }, 1e3)
ƒ name () { ... }
`name () { ... }
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On 21/01/2012, at 03:59, Brendan Eich wrote: 2.- quasi literals could as well use something else (the acute accent ?) instead No, that is used for string literals, since JS1 in 1995! Sorry, I don't follow, with that you mean something else or the acute accent ? str = ´agudo´ Error • message: Invalid character '\u0180' -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Jorge mailto:jo...@jorgechamorro.com
January 20, 2012 7:15 PM
Sorry, I don't follow, with that you mean something else or the
acute accent ?
Oh, not ' but the diacritical on é, you mean?
How do I type that on a US or UK keyboard? We are not going to use
non-ASCII characters, so you are still barking up the wrong tree.
/be
str = ´agudo´
Error
• message: Invalid character '\u0180'
Brendan Eich mailto:bren...@mozilla.org
January 20, 2012 6:59 PM
Jorge mailto:jo...@jorgechamorro.com
January 20, 2012 6:46 PM
1.- There are not quasi literals in the language yet
No, quasi-literals are approved for ES6. Already.
2.- quasi literals could as well use something else (the acute accent
?) instead
No, that is used for string literals, since JS1 in 1995!
3.- a shorter function syntax is almost at the top in the
programmers' wish list for ES.next (unlike quasis)
So what? No one except you is asking for ` and quasis won. Please
adjust your expecations accordingly.
Isn't it -perhaps- too soon to reject ` for functions in favor of
quasis ?
No.
/be
Jorge mailto:jo...@jorgechamorro.com
January 20, 2012 1:22 AM
Has a backtick/accent grave ever been considered and/or rejected ?
Anonymous function expression:
setTimeout( '(){ ... }, 1e3);
Named function expression:
setTimeout( 'name(){ ... }, 1e3);
Declarations:
`(){ ... } // error: can't declare anonymous functions
`name(){ ... }
Brendan Eich mailto:bren...@mozilla.com
January 19, 2012 11:27 AM
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there
is a completion value leak hazard. TC39 seems to agree the solution
there is something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement.
I've worked on both of these in the context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical
issues that have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable
objects. Not just to set .prototype, also to decorate with ad-hoc and
meta-data properties. Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default.
For merely shorter function syntax, no. Functions are mutable
objects by default in JS. This matters for minifiers, which may not be
able to see all the mutations but would love to use shorter syntax for
'function' syntax, blindly.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer January 20, 2012 5:34 PM How much does the fact that a symbol *could* be used (in theory) matter in practice? Most regexes I see for valid identifiers are still of the ^[a-zA-Z_$][0-9a-zA-Z_$]*$ variety.I’d expect λ to be in use in Greece, but how about ƒ (which has been mentioned many times)? It seems very appropriate and is even easy to type on a Mac (easier than square brackets on a German keyboard!). It's hard to type λ on many keyboards. ƒ is easier, but neither is backward-compatible: js ƒ = 1 1 js ƒ 1 js λ = 2 2 js λ 2 We rejected these already for these reasons. I think "use fn;" (real pragma syntax), with the low-precedence assignment-_expression_ fn (params) assign-expr production, wins. What do you think? /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Various thoughts: How much does the fact that a symbol *could* be used (in theory) matter in practice? Most regexes I see for valid identifiers are still of the ^[a-zA-Z_$][0-9a-zA-Z_$]*$ variety. I’d expect λ to be in use in Greece, but how about ƒ (which has been mentioned many times)? It seems very appropriate and is even easy to type on a Mac (easier than square brackets on a German keyboard!). It's hard to type λ on many keyboards. ƒ is easier, but neither is backward-compatible: js ƒ = 1 1 js ƒ 1 js λ = 2 2 js λ 2 We rejected these already for these reasons. My thinking was: If no one ever uses λ as an identifier (not likely in Greece) or ƒ as an identifier (likely, given that most people seem to think JS identifiers must adhere to the regexes shown above) then one would be free to make them reserved tokens in ES6. Counter arguments: - Hard to type: reading is far more important than typing, it is very easy to adapt tools to help with typing. - Not ASCII: I hardy every encounter non-UTF text files, any more. Non-ASCII seems to work well for Fortress. I think use fn; (real pragma syntax), with the low-precedence assignment-expression fn (params) assign-expr production, wins. What do you think? Having fn would be sweet. For many kinds of pragmas, it would be great if one could configure these per project (or per directory). Then one could put legacy code in one directory and ES6 code in another. And the weight of the pragmas would be negligible. Not sure how to do this, though; reminds me very loosely of CSS (centralized management of style). Would fn make sense as an ES6 breaking change? I’d expect many people to be strongly in favor, possibly as many strongly opposed. Possible research (applies to ƒ, too): - Poll people for their opinion - Search JS code bases for how often the identifier fn is used (how?). -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 20, 2012 9:24 PM
- Hard to type: reading is far more important than typing, it is very
easy to adapt tools to help with typing.
ƒ is not particularly readable IMHO. It's florin, not mathematical
notation I've ever seen. Anyway we can't assume the compatibility break
is ok since it can occur in operand context in any expression.
- Not ASCII: I hardy every encounter non-UTF text files, any more.
Non-ASCII seems to work well for Fortress.
Fortress, please. I invite @samth to comment now. I admire Fortress, but
it is not an exemplar or nearby language for JS.
I think use fn; (real pragma syntax), with the low-precedence
assignment-expression fn (params) assign-expr production, wins. What
do you think?
Having fn would be sweet. For many kinds of pragmas, it would be great
if one could configure these per project (or per directory). Then one
could put legacy code in one directory and ES6 code in another. And
the weight of the pragmas would be negligible. Not sure how to do
this, though; reminds me very loosely of CSS (centralized management
of style).
You make a good point: use fn; may be too much to require in every
script element content.
Would fn make sense as an ES6 breaking change? I’d expect many people
to be strongly in favor, possibly as many strongly opposed.
Don't forget that JQuery uses fn as an identifier (and not just
following a dot) all over.
Possible research (applies to ƒ, too):
- Poll people for their opinion
These are not decisive. I've been straw-polling audiences for a while.
Block-lambdas are doing well, but one must ask nothing, just
'function' and usually get a stronger response than any new syntax.
- Search JS code bases for how often the identifier fn is used (how?).
See JQuery sources. Unconditionally reserving 'fn' is a non-starter
IMHO. Recall also that we are trying to hew to One JavaScript -- few
to no refactoring woes moving code in and out of a module {...}
container or use strict; code block.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 19, 2012, at 8:27 , Brendan Eich wrote:
To fix (2), how about reviving arrows and avoiding the non-LR(1) parsing for
grammar validation problem?
Couldn’t one always freeze such a function shorthand and then get syntax such
as:
#(x, y) { x + y }
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 12:06 AM
Couldn’t one always freeze such a function shorthand and then get
syntax such as:
#(x, y) { x + y }
I'm not sure what you mean. I proposed this a while ago (Harmony of My
Dreams) but we don't want frozen by design, and without the # the
result is ambiguous without restricted productions, and hazardous on
that account.
The idea that any grawlixy preifx will do is false. Hash is wanted for
consistent freeze/seal prefixing. Arrow is better and putting it at the
front solves the grammar problems with arrow function syntax as current
drafted.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Couldn’t one always freeze such a function shorthand and then get syntax
such as:
#(x, y) { x + y }
I'm not sure what you mean. I proposed this a while ago (Harmony of My
Dreams) but we don't want frozen by design, and without the # the result is
ambiguous without restricted productions, and hazardous on that account.
The idea that any grawlixy preifx will do is false. Hash is wanted for
consistent freeze/seal prefixing. Arrow is better and putting it at the front
solves the grammar problems with arrow function syntax as current drafted.
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you want
anything else, you can use a traditional function. Then the above syntax as the
only function shorthand would be OK.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Andreas Rossberg wrote: On 19 January 2012 18:31, Axel Rauschmayera...@rauschma.de wrote: Rationale: wouldn’t freezing by default be OK for 98% of the cases? Especially since the cases where you care most about short syntax are throw-away functions. The only sane reason I have seen for mutating a function is to set its prototype property. But who wants to write constructors as short lambdas? Another use case is modelling C-style static variables as properties, but you cannot do that with an anonymous function anyway (I also don't regard it as particularly sane, but who am I to judge). I'd say +1 for frozen shortcut functions. I also don't see the use case where mutating _the_function_ itself would be needed in such cases. It seems to me it is ok for big percentage of uses. If you need mutable one, use function. Only fearful factor is when frozen one is used and in the runtime mutation is needed for something... but I could not find such use... wrapping such function is still possible, that is probably most possibility you need in runtime when monkey-patching or something. Correct me if I am wrong. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Brendan Eich wrote:
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
Well, if #(x, y) {x+y} is not good because of # is used for freezing and
freezing is not good (it is not, metadata is good argument for that),
and if something-like-lambda-block is ok, some variation of lambda-block
could be the shorter replacement for functions. These come to mind:
{*a, b* a+b}
{/a, b/ a+b}
{^a, b^ a+b}
{%a, b% a+b}
and there is still more infix operators...
maybe even {`a, b` a+b} if it does not create conflict in this context.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
It may be just a personnal taste, but I've to agree the current proposal
(#() ...) seems very appealing to me. I did not respond to your mail
proposing to use the Arrow syntax because it seems obscure to me. The
distinction between normal and fat arrow is thin, does not make sense.
You either need a function-object (which doesn't have 'this' mapping, has
expandos) or a local-function (which has 'this' mapping, just need to be a
[Call] target). If you need the first, you need a traditionnal function
since you need something not-frozen that can be added to objects as a
property at a later time. If you want 'this' mapping, you need something
that only makes sense in a local context.
Additionnaly, the arrow syntax is illogical. You usually say I want a
function of (X,Y) which returns X+Y or I want to transform X in
X.toString, not From X, I want to get X.toString().
Freezing a local function seems as acceptable to me as it seemed to others.
A LF should only be used in a controlled context where the function itself
is just used as a function, not an object. But if it's not acceptable to
other members, I'm not against a @(x) syntax that does not offer frozen
functions (but I think it's a missed optimization opportunity). The point
about Conditionnal Compiling in IE is not valid anymore since Microsoft has
deleted HTML Conditionnal Comments because they were not standards (even if
they were used a lot), so I don't think the obscure and fewly used JScript
CC are meant to stay, especially if it hurts another proposal.
In my view of the thing, a local function should be used as a function in
the mathematical sense of the term: you give a parameter, it returns its
image by the function.
The cases we are trying to solve:
var inc=#(x) x+1;
array.map(#(x) x.toString());
array.filter(#(x) isValid(x));
array.map(#(x) {
while(x.previousSibling) x=x.previousSibling;
return x;
});
For example, I don't see this as a good use-case of a LocalFunction :
...
refreshLayout: function(e) {
...
requestAnimationFrame(#(e) this.refreshLayout(e));
}
...
It should be a block lambda instead, because it's meant to 'continue' the
current function in a sort of async while(true) loop.
...
refreshLayout: function(e) {
...
requestAnimationFrame({|e| this.refreshLayout(e) });
}
...
For all of the use cases where a mathematical function is requied, you
just need some valid [Call]-able item. You will never add expandos on an
function you don't know (ie that you received as a parameter). You'll wrap
it before, if you really need that. If you want the full flexibility of a
function-as-an-object, it means you need a 'true function'; LF are not meant
to replace functions in the long run, they are made to serve the case where
you want a short, action-related, contextual function. That means 'this'
binding, if needed, just like it's in languages like dotNET.
However, I would like to hear more about the specific reasons that led Arv
and Alex think a LF should not be frozen.
Regards,
François
PS: The synax I speak about for LocalFunctions would be:
LocalFunctionExpression:
'#(' argument-list ')' expression
or
'#(' argument-list ') {' statements* '}'
They would be 'bound-this' if there's a 'this' in their body, but can be
left unbounded if there's no since it has no visible effet. If they don't
reference variables of a scope, they should not use reference scope and may
be reused accross function calls.
-Message d'origine-
From: Brendan Eich
Sent: Thursday, January 19, 2012 8:27 PM
To: Axel Rauschmayer ; Andreas Rossberg
Cc: François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there is
a completion value leak hazard. TC39 seems to agree the solution there
is something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement. I've
worked on both of these in the context
Re: Block lambda is cool, its syntax isn't
FTR: With block lambdas and object literal extensions, I wouldn’t want/need a
function shorthand. I thought I had seen an opportunity for a more compact
syntax (if and only if function shorthands are needed), but was wrong. Sorry.
Suggestion: a community-edited page where we collect the rejected syntaxes (=
less running in circles) – simply copying emails (such as yours below) there
would probably suffice.
On Jan 19, 2012, at 20:27 , Brendan Eich wrote:
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you
want anything else, you can use a traditional function. Then the above syntax
as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit return
value was part of the proposal. If so, controvery, since there is a
completion value leak hazard. TC39 seems to agree the solution there is
something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still requiring
'return' is not considered enough of a shorthand. A possible cure here is to
support an alternative body syntax: #(params) expr. However, this inverts
precedence if done naively. It also runs into trouble trying to prefer an
object literal over a block statement. I've worked on both of these in the
context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical issues that
have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable objects.
Not just to set .prototype, also to decorate with ad-hoc and meta-data
properties. Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default. For
merely shorter function syntax, no. Functions are mutable objects by
default in JS. This matters for minifiers, which may not be able to see all
the mutations but would love to use shorter syntax for 'function' syntax,
blindly.
/be
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Yet they are cases where a block lambda isn’t suited and where a ‘classic’
function is just too long to type (and would hurt performance as well). Look
back in the thread for a sample. (Mainly: cases involving a ‘return’ in a loop
or in a nested statement can’t be solved well using block-lambda).
Block lambda is not the solution since it wasn’t written to solve the cases
where we traditionnaly use a 'local function’, but to solve new use-cases where
we want our function to continue to run inside a function structure, or
asynchronously. The old cases where we use “function() { ... { ... return; }
... }” are not covered properly by block lambda, nor are intended to.
From: Axel Rauschmayer
Sent: Thursday, January 19, 2012 10:14 PM
To: Brendan Eich
Cc: Andreas Rossberg ; François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
FTR: With block lambdas and object literal extensions, I wouldn’t want/need a
function shorthand. I thought I had seen an opportunity for a more compact
syntax (if and only if function shorthands are needed), but was wrong. Sorry.
Suggestion: a community-edited page where we collect the rejected syntaxes (=
less running in circles) – simply copying emails (such as yours below) there
would probably suffice.
On Jan 19, 2012, at 20:27 , Brendan Eich wrote:
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you
want anything else, you can use a traditional function. Then the above syntax
as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit return
value was part of the proposal. If so, controvery, since there is a completion
value leak hazard. TC39 seems to agree the solution there is something with
different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still requiring
'return' is not considered enough of a shorthand. A possible cure here is to
support an alternative body syntax: #(params) expr. However, this inverts
precedence if done naively. It also runs into trouble trying to prefer an
object literal over a block statement. I've worked on both of these in the
context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical issues that
have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable objects. Not
just to set .prototype, also to decorate with ad-hoc and meta-data properties.
Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default. For
merely shorter function syntax, no. Functions are mutable objects by default
in JS. This matters for minifiers, which may not be able to see all the
mutations but would love to use shorter syntax for 'function' syntax, blindly.
/be
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Now you are forgetting the argument that TCP-conforming block-lambdas
*should* look quite different from ...(params) {body} functions. This
implies that shorter function syntax ought to follow the (params) {body}
plan.
/be
Herby Vojčík mailto:he...@mailbox.sk
January 19, 2012 11:40 AM
Brendan Eich wrote:
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
Well, if #(x, y) {x+y} is not good because of # is used for freezing
and freezing is not good (it is not, metadata is good argument for
that), and if something-like-lambda-block is ok, some variation of
lambda-block could be the shorter replacement for functions. These
come to mind:
{*a, b* a+b}
{/a, b/ a+b}
{^a, b^ a+b}
{%a, b% a+b}
and there is still more infix operators...
maybe even {`a, b` a+b} if it does not create conflict in this context.
/be
Herby
Brendan Eich mailto:bren...@mozilla.com
January 19, 2012 11:27 AM
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there
is a completion value leak hazard. TC39 seems to agree the solution
there is something with different look feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement.
I've worked on both of these in the context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical
issues that have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable
objects. Not just to set .prototype, also to decorate with ad-hoc and
meta-data properties. Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say freeze by default.
For merely shorter function syntax, no. Functions are mutable
objects by default in JS. This matters for minifiers, which may not be
able to see all the mutations but would love to use shorter syntax for
'function' syntax, blindly.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
Brendan Eich mailto:bren...@mozilla.com
January 19, 2012 9:25 AM
I'm not sure what you mean. I proposed this a while ago (Harmony of
My Dreams) but we don't want frozen by design, and without the # the
result is ambiguous without restricted productions, and hazardous on
that account.
The idea that any grawlixy preifx will do is false. Hash is wanted for
consistent freeze/seal prefixing. Arrow is better and putting it at
the front solves the grammar problems with arrow function syntax as
current drafted.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 12:06 AM
Couldn’t one always freeze such a function shorthand and then get
syntax such as:
#(x, y) { x + y }
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 19, 2012 12:19 PM
It may be just a personnal taste, but I've to agree the current
proposal (#() ...) seems very appealing to me. I did not respond to
your mail proposing to use the Arrow syntax because it seems obscure
to me. The distinction between normal and fat arrow is thin, does
not make sense.
Agreed, and that is another problem plaguing arrow function syntax as
proposed. But if we rescue it by moving the arrow up front, we may solve
this problem by dropping fat arrow. Shorter function syntax does not
have to include shorter .bind(o) syntax.
You either need a function-object (which doesn't have 'this' mapping,
has expandos) or a local-function (which has 'this' mapping, just need
to be a [Call] target).
We can't guess and I would not assume a local (nested, you mean?)
function wants lexical |this| by default, overridden only by callee-base
|this| when/if the nested function is called as a method. Mark Miller
showed the problem:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018186.html
in reply to
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018183.html
If you need the first, you need a traditionnal function since you need
something not-frozen that can be added to objects as a property at a
later time. If you want 'this' mapping, you need something that only
makes sense in a local context.
You mean a block-lambda? I agree.
Additionnaly, the arrow syntax is illogical. You usually say I want a
function of (X,Y) which returns X+Y or I want to transform X in
X.toString, not From X, I want to get X.toString().
I'm not sure what you mean here by illogical and your verbal
expansions -- are you saying the arrow should come in between params and
body? Yes, that is nicer and Jeremy Ashkenas followed that design (used
in other languages of course) for that reason. But it makes for grammar
trouble for two reasons:
1. (params) looks like a comma expression. We can parse it as such and
then validate it using supplemental syntax as for destructuring, but
it is a bit future-hostile.
2. If we want an expression body alternate syntax that prefers object
literals over body blocks, we have to resolve this conflict:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
Doing so is even more future-hostile in light of the new object literal
extensions in ES6.
Freezing a local function seems as acceptable to me as it seemed to
others. A LF should only be used in a controlled context where the
function itself is just used as a function, not an object. But if it's
not acceptable to other members, I'm not against a @(x) syntax that
does not offer frozen functions (but I think it's a missed
optimization opportunity).
Again, @ is wanted for private names -- all the few unused ASCII
punctuators are wanted. Why are you insisting on @ here? It's not
particularly associated with functions in other languages, or suggestive
of functions.
In my view of the thing, a local function should be used as a function
in the mathematical sense of the term: you give a parameter, it
returns its image by the function.
JS practice varies wildly. No developer consensus on this point.
The cases we are trying to solve:
var inc=#(x) x+1;
array.map(#(x) x.toString());
array.filter(#(x) isValid(x));
array.map(#(x) {
while(x.previousSibling) x=x.previousSibling;
return x;
});
This case is not like the one you showed earlier, and not so clearly bad
for block-lambda. There is only one return, it's at the bottom, so
completion value as implicit return value in a block-lambda wins:
array.map({ |x|
while(x.previousSibling) x=x.previousSibling;
x;
});
It's not a requirement either way, of course.
For example, I don't see this as a good use-case of a LocalFunction :
...
refreshLayout: function(e) {
...
requestAnimationFrame(#(e) this.refreshLayout(e));
}
...
It should be a block lambda instead, because it's meant to 'continue'
the current function in a sort of async while(true) loop.
Oh but here is a case where you advocate a block-lamdba for an async
callback. IIRC earlier you wrote that block-lambdas should be used for
sync callbacks. I may have misread you though.
I dont believe there's a hard and fast rule. Of course, the block-lambda
cannot break/continue/return if the enclosing function activation is no
more.
...
refreshLayout: function(e) {
...
requestAnimationFrame({|e| this.refreshLayout(e) });
}
...
For all of the use cases where a mathematical function is requied,
you just need some valid [Call]-able item. You will never add expandos
on an function you don't know (ie that you received as a parameter).
No, but local functions are decorated with expandos in their local scope.
You'll wrap it before, if you really need that. If you want the full
Re: Block lambda is cool, its syntax isn't
Just a thought, has a prefix ^ been considered?A lambda that takes no arguments could be: ^{ /*...*/ }And a lambda with some arguments: ^(x,y){ /*...*/ }I just find this really readable, the syntax for lambdas that take no arguments is delightfully minimal (just one extra character!), my brain is well trained to expect argument lists to be delimitedby parentheses so I find this much easier to understand, and I find the ^ character pleasingly evocative ofλ. :-)cheers,G.On Jan 13, 2012, at 3:03 PM, Brendan Eich wrote:
The { and } around the ||
make it pretty clear the || is not a boolean. Also you can put a space
in {| |}. But mainly, as with any alternative bracketing system that
uses an infix operator, we are relying on the leading { to make it clear
that the immediately following delimiter, | in the proposal, cannot
represent its usual infix role (| or ||).
/be
john saylor
January 13, 2012
1:11 PM
yes, i had the same impression [thx to those who supplied code
examples].
one problem i came across in this domain is that a block lambda with
no
arguments is visually identical to a boolean or ['||']. context, i
believe, will clarify this; but from a purely visual perspective, two
adjacent pipe characters are almost archetypal for the boolean or
operator [if i can speak about archetypes in computer programming].
Rick Waldron
January 13, 2012
12:36 PM
FWIW, After working through the
example gists that I created last night, my opinion changed about the
look of Block Lambda's with pipes. As others on the list have said
previously and is now very clear to me, pipes provide a very distinct
visual cue "this is a block lambda, expect X to happen here" where the
{(args) expr } gets lost; these visual cues are important when you're
reading and writing "real world" programs in _javascript_.
Rick
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock
January 13, 2012
10:51 AM
I've updated a
version of my ES.next Smalltalk collections implementation experiment to
use block lambdas.This version ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.jsThe
one that you should compare it to ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.jsAs
you might expect, this new version is even closer in form to the
original Smalltalk code.In particularly, I was able to
eliminate all the artifacts that needed to be introduced because of
function expressions don't have Tennent's Correspondence.In
the source, I've tagged the lines where TCP is using /*TCP*/Allen___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
john saylor
January 13, 2012
6:09 AM
hello world!
i think this would be very helpful too [although, sadly, since i am
overcommitted as it is, it will not be me].
David Herman
January 12, 2012
6:09 PM
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as a statement by itself. If it's the case, it should defined as an _expression_ only, where there's no anonymous block to conflict the syntax. That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for uses of a feature "in the wild." Does some enterprising es-discusser wanna take a big JS program with a bunch of little anonymous functions, swap them out with block lambdas, and make two gists with the two different syntaxes? That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous block in some future revision of ES, that very small edge case could vanish at the same time.
I don't understand what you're referring to here -- what do you mean by "unprefixed anonymous block?"
Does it seems possible/acceptable?
Lovely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Wed, Jan 18, 2012 at 10:28 AM, Gavin Barraclough
barraclo...@apple.comwrote:
Just a thought, has a prefix ^ been considered?
A lambda that takes no arguments could be:
^{ /*...*/ }
And a lambda with some arguments:
^(x,y){ /*...*/ }
I just find this really readable, the syntax for lambdas that take no
arguments is delightfully minimal (just one extra character!), my brain is
well trained to expect argument lists to be delimited by parentheses so I
find this much easier to understand, and I find the ^ character pleasingly
evocative of λ. :-)
This is really a matter of taste.
{ (a, b) ... }
^(a, b) { ... }
{ |a, b| ... }
Of course, some characters are easier to type than others, especially in
non-qwerty keyboards (I'm thinking about the pipe |).
But what matters most is readability, since code is more often read than
written. So far, people seem to think that pipes are more readable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Yes, we've been over many
prefixes, from Greek lowercase lambda to \ to ^. Two problems, one
specific to ^, the other general to the body plan you propose:
1. ^ is taken as the bitwise XOR operator. So there's an "ASI didn't
happen but the user expected it" hazard motivating us to restrict any
operand (vs. operator) context overloading of ^ to start a lambda to
have [no LineTerminator here] on the left of the operand-^. Otherwise
valid JS of the form
x = y
^{z: w}
is too easily confused for an assignment _expression_ statement
(terminated by an automatically inserted semicolon, the mistaken reader
thinks -- there could be comments and lots of blank lines between the
two lines shown above) followed by a lambda.
Even with the above being forbidden by [no LineTerminator here] to the
left of the lambda' productions right hand side, allowing x ^ ^{y}
smells bad. But perhaps not as bad as pipes on the inside -- YMMV.
2. The TCP conformance makes anything like function (params) {body} an
anti-pattern. Changing function to ^ does not avoid this problem. We
want block-lambdas to look different from functions.
(2) is an overriding objection in my view.
/be
Gavin Barraclough
January 18, 2012
1:28 AM
Just a thought, has a prefix ^
been considered?A lambda that takes no arguments
could be: ^{ /*...*/ }And a lambda
with some arguments: ^(x,y){ /*...*/ }I
just find this really readable, the syntax for lambdas that take no
arguments is delightfully minimal (just one extra character!), my brain
is well trained to expect argument lists to be delimited by parentheses
so I find this much easier to understand, and I find the ^ character
pleasingly evocative of λ. :-)cheers,G.___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Brendan Eich
January 13, 2012
3:03 PM
The { and } around the ||
make it pretty clear the || is not a boolean. Also you can put a space
in {| |}. But mainly, as with any alternative bracketing system that
uses an infix operator, we are relying on the leading { to make it clear
that the immediately following delimiter, | in the proposal, cannot
represent its usual infix role (| or ||).
/be
john saylor
January 13, 2012
1:11 PM
yes, i had the same impression [thx to those who supplied code
examples].
one problem i came across in this domain is that a block lambda with
no
arguments is visually identical to a boolean or ['||']. context, i
believe, will clarify this; but from a purely visual perspective, two
adjacent pipe characters are almost archetypal for the boolean or
operator [if i can speak about archetypes in computer programming].
Rick Waldron
January 13, 2012
12:36 PM
FWIW, After working through the
example gists that I created last night, my opinion changed about the
look of Block Lambda's with pipes. As others on the list have said
previously and is now very clear to me, pipes provide a very distinct
visual cue "this is a block lambda, expect X to happen here" where the
{(args) expr } gets lost; these visual cues are important when you're
reading and writing "real world" programs in _javascript_.
Rick
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock
January 13, 2012
10:51 AM
I've updated a
version of my ES.next Smalltalk collections implementation experiment to
use block lambdas.This version is https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.js The
one that you should compare it to is https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.js As
you might expect, this new version is even closer in form to the
original Smalltalk code.In particularly, I was able to
eliminate all the artifacts that needed to be introduced because of
function expressions don't have Tennent's Correspondence. In
the source, I've tagged the lines where TCP is using /*TCP*/Allen___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
x = y
^{z: w}
On Jan 18, 2012, at 9:05 AM, Oliver Hunt wrote:
Alas ^ is syntactically ambiguous in the non-argument case:
foo
^{...}
The ambiguity here doesn't seem particularly troubling. Under ASI this parses
in a sensible fashion.
This seems unlikely to cause any confusion in real usage, since it only effects
an object literal as an operand to a bitwise operator.
On the other hand, reuse of | seems somewhat more awkward. Based on the block
lambda revival proposal, I believe:
{|x = (ab)| x}
{|x = (ab)| x}
{|x = ab| x}
Are all valid block lambdas, but:
{|x = ab| x}
Isn't.
Allowing an arbitrary subset of infix operators in initializer expressions
seems an unfortunate wart, and potentially confusing to users of the language.
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
2. The TCP conformance makes anything like function (params) {body} an
anti-pattern. Changing function to ^ does not avoid this problem. We want
block-lambdas to look different from functions.
(2) is an overriding objection in my view.
That's a fair point.
For my tastes reusing | as delimiters to the parameter lists is a step too far
away from function-like syntax, particularly if it restricts an arbitrary
subset of infix operators from initializers.
I'd suggest changing the terminator for the parameter list to something other
than | ...
{|: foo() }
{|x,y: foo(x,y) }
But I'd hate myself if I did. ;-)
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 18, 2012, at 10:36 AM, Gavin Barraclough wrote:
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
x = y
^{z: w}
On Jan 18, 2012, at 9:05 AM, Oliver Hunt wrote:
Alas ^ is syntactically ambiguous in the non-argument case:
foo
^{...}
The ambiguity here doesn't seem particularly troubling. Under ASI this parses
in a sensible fashion.
It doesn't
a
^
b
does not get any ASI, and is parsed (correctly) as a^b
This seems unlikely to cause any confusion in real usage, since it only
effects an object literal as an operand to a bitwise operator.
I dislike the | mode quite a lot, the only obvious reason for that proposal
existing is some peoples current love of ruby :) Why not use the C++ lambda
syntax? or the MSVC lambda syntax? or the haskell syntax? etc, etc (Obj-C uses
the ^ that we've already demonstrated is ambiguous :D )
On the other hand, reuse of | seems somewhat more awkward. Based on the block
lambda revival proposal, I believe:
{|x = (ab)| x}
{|x = (ab)| x}
{|x = ab| x}
Are all valid block lambdas, but:
{|x = ab| x}
Isn't.
Allowing an arbitrary subset of infix operators in initializer expressions
seems an unfortunate wart, and potentially confusing to users of the language.
On Jan 18, 2012, at 2:09 AM, Brendan Eich wrote:
2. The TCP conformance makes anything like function (params) {body} an
anti-pattern. Changing function to ^ does not avoid this problem. We want
block-lambdas to look different from functions.
(2) is an overriding objection in my view.
That's a fair point.
For my tastes reusing | as delimiters to the parameter lists is a step too
far away from function-like syntax, particularly if it restricts an arbitrary
subset of infix operators from initializers.
I'd suggest changing the terminator for the parameter list to something other
than | ...
{|: foo() }
{|x,y: foo(x,y) }
But I'd hate myself if I did. ;-)
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Oliver Hunt mailto:oli...@apple.com
January 18, 2012 11:37 AM
On Jan 18, 2012, at 10:36 AM, Gavin Barraclough wrote:
This seems unlikely to cause any confusion in real usage, since it
only effects an object literal as an operand to a bitwise operator.
I dislike the | mode quite a lot, the only obvious reason for that
proposal existing is some peoples current love of ruby :)
Not so -- I do not love Ruby. Also, this is essentially an _ad hominem_
argument.
Why not use the C++ lambda syntax?
Because we cannot use (params) { body } without a restricted production
*and* the result looking too much like a function, or run-together
expression and block-statement. We've been over this.
Block-lambdas have significantly different semantics due to TCP
conformance. They ought to look different.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 18, 2012, at 11:41 AM, Brendan Eich wrote:
Oliver Hunt mailto:oli...@apple.com
January 18, 2012 11:37 AM
On Jan 18, 2012, at 10:36 AM, Gavin Barraclough wrote:
This seems unlikely to cause any confusion in real usage, since it only
effects an object literal as an operand to a bitwise operator.
I dislike the | mode quite a lot, the only obvious reason for that proposal
existing is some peoples current love of ruby :)
Not so -- I do not love Ruby. Also, this is essentially an _ad hominem_
argument.
Many apologies, the ':)' was meant to imply that a knew that that wasn't a
valid argument
Why not use the C++ lambda syntax?
Because we cannot use (params) { body } without a restricted production *and*
the result looking too much like a function, or run-together expression and
block-statement. We've been over this.
Block-lambdas have significantly different semantics due to TCP conformance.
They ought to look different.
I guess. Maybe the problem here is that I don't like the block-lambda concept
itself. I'll mull on i, and harass you at whatever magical location where
meeting at tomorrow :D
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Oliver Hunt mailto:oli...@apple.com
January 18, 2012 11:45 AM
On Jan 18, 2012, at 11:41 AM, Brendan Eich wrote:
Not so -- I do not love Ruby. Also, this is essentially an _ad
hominem_ argument.
Many apologies, the ':)' was meant to imply that a knew that that wasn't a
valid argument
Sure, I saw that -- just trying to stick up for myself as a non-lover of
Ruby.
I think TCP is worth including in JS in a new special form. We've been
talking about this since 2008 at least:
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008216.html
Anything we on this front is a new special form. We won't make a
migration barrier or dialect/version fork and inflict TCP on functions.
So then the issue is what concrete syntax might be best.
Looking at other languages is one way to hedge against the proven
ability of any language designer to mistake the original for the good.
Ruby's syntax has some basis in Smalltalk, but not much. Ruby is known
to some JS developers but not all. There's some win here, but not
decisive win.
Independent of Ruby, we've argued about other syntaxes, most recently
{(params) body}, and everyone I saw champion that syntax came back to
pipes to better distinguish the new special form from both functions and
juxtaposed parenthesized expressions and block statements.
The fact that block-lambdas use the same {|params| body} syntax as Ruby
in what I'm proposing is thus not an argument from authority (Matz's or
other Rubyist's). The proposed syntax does not have anything to do with
love of Ruby as in willing the good of Ruby (to use a sound
definition of love). It has everything to do with loving JS *assuming*
we want a TCP-conforming lambda special form.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
To be fair, after a long reflection, I have been concluding that no other
proposal beat {|| ...} for block lambda at this time. Also, I’ve found some use
cases where block-lambda are actually useful (something I was really curious
about before thinking about it). In the future, they may even be used a lot by
transpilers to emulate new language constructs in a ES-friendly way.
The main point I dislike with the current proposal is that it makes
block-lambda used at places where I think they should not. It’s not because
they are useful to solve some problems they are useful to fix all. Most of the
time, when we want a lambda, we don’t want TCP. We want a new function. Just
and only that. Since we want a new function, we are requesting function-like
semantics. It’s logical.
An exemple:
function A() {
let ret = {|x| return x; };
let inc = {|x| x+1 };
let j = 0;
while (true) {
if (j 3) ret(j);
j = inc(j);
}
}
I don’t think “inc” should be a block-lambda. It can be, if someone do that, I
would not bother modifying the code. But it’s not the natural way to think.
What we need here is not an “extension” of the current function (which is a
block lambda is), we need a new function.
The problem is that the current syntax is too long :
let inc = function(x) { return x+1; }
I think (but I don’t say it’s what should be done, it’s up to debate) that
alongside block-lambda, we should introduce a ‘canonical’ lambda proposal, that
would just be syntaxic sugar for plain old functions.
The syntax I propose would be:
‘@(‘ + argument-list + ‘)’ + statement;
// or if too complex
‘@(‘ + argument-list + ‘)’ + ‘{‘ + statement + ‘}’;
That would desugar to:
(function lambda_lineX_colY_fileZ(argument-list) {
return do {
statement
};
}).bind(this);
That would allow the following samples :
let inc = @(x) x+1;
array.map(@(x) x+1);
array.map(@(x) {
if(x.hasKey(‘a’)) {
x.get(‘a’)
} else {
undefined
}
});
and the more complex ones :
array.map(@(x) {
while(x.parentNode) {
x=x.parentNode;
if(x.tagName==’DIV’) { return x; }
}
console.log(‘An element that has no parent DIV has been found.’);
return undefined;
});
Please note that the last one seems very complex to write using a block-lambda :
array.map({|x| let returnValue;
while(x.parentNode) {
x=x.parentNode;
if(x.tagName==’DIV’) { returnValue=x; break; }
}
if(returnValue) {
returnValue;
} else {
console.log(‘An element that has no parent DIV has been found.’);
undefined;
}
});
That proposal does offer some middle ground between
- ‘functions’ (classical functions)
- ‘lambdas’ which are local functions that are not meant to go outside the
scope of an action
- ‘block-lambdas’ which are internal functions that are not meant to go outside
the scope of a function scope.
Anyone can use what’s the most convenient for him, I think there’s room for all
those things.
François
From: Axel Rauschmayer
Sent: Wednesday, January 18, 2012 8:48 PM
To: Oliver Hunt
Cc: Brendan Eich ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
Maybe the problem here is that I don't like the block-lambda concept itself.
I’m curious: What do you dislike?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
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: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 18, 2012 12:54 PM
To be fair, after a long reflection, I have been concluding that no
other proposal beat {|| ...} for block lambda at this time. Also, I’ve
found some use cases where block-lambda are actually useful (something
I was really curious about before thinking about it). In the future,
they may even be used a lot by transpilers to emulate new language
constructs in a ES-friendly way.
Indeed -- and it's good to read this paragraph.
The main point I dislike with the current proposal is that it makes
block-lambda used at places where I think they should not. It’s not
because they are useful to solve some problems they are useful to fix
all. Most of the time, when we want a lambda, we don’t want TCP. We
want a new function.
I'm not sure about most, but you are right that we don't want one
hammer for all nails. We have function already. It wants shorter syntax
(some say). Providing block-lambdas does not help there, and may tempt
misuse of block-lambda where function is better, just because of
block-lambda's conciseness.
Just and only that. Since we want a new function, we are requesting
function-like semantics. It’s logical.
An exemple:
function A() {
let ret = {|x| return x; };
let inc = {|x| x+1 };
let j = 0;
while (true) {
if (j 3) ret(j);
j = inc(j);
}
}
I don’t think “inc” should be a block-lambda. It can be, if someone do
that, I would not bother modifying the code. But it’s not the natural
way to think.
The TCP does help here, IMHO -- no 'return'.
What we need here is not an “extension” of the current function (which
is a block lambda is), we need a new function.
Yet
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax is
in decline. But more below on that.
The problem is that the current syntax is too long :
let inc = function(x) { return x+1; }
It's not just the length -- the 'return' and arguably even the braces
are too much for an expression-bodied function.
I think (/but I don’t say it’s what should be done, it’s up to
debate/) that alongside block-lambda, we should introduce a
‘canonical’ lambda proposal, that would just be syntaxic sugar for
plain old functions.
Let's try not to use lambda two different ways, one of them not TCP.
Lambda calculus and LISP fans want TCP.
The syntax I propose would be:
‘@(‘ + argument-list + ‘)’ + statement;
Two problems:
1. The semicolon can't be required, and if it isn't, then an Expression
or AssignmentExpression statement as body inverts precedence fatally,
because a function expression is a PrimaryExpression (ES6 fix, ES1-5 had
it as MemberExpression, unobservably different and still high
precedence). See
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007883.html
Adapting to your proposal:
function f() {return f}
var x = 3;
g = - (a) a ? f : x++(1);
To fix (1), we want not simply a shorthand for high-precedence
FunctionExpression, rather a new low-precedence production, as in
arrow_function_syntax:
AssignmentExpression :
ArrowFunctionExpression
...
Parenthesization will be required to use this kind of expression with
higher precedence operators than , and = but those are rare operators
with which to join any kind of function expression to other operators,
with the possible exception of ( Arguments ) to invoke immediately.
Immediate invocation would require parenthesizing the callee.
2. @ is wanted for private names. The precedent in Ruby and CoffeeScript
for instance variables is strong.
// or if too complex
‘@(‘ + argument-list + ‘)’ + ‘{‘ + statement + ‘}’;
Definitely no ; at end here -- but this one is ok because the braces
avoid precedence inversion.
To fix (2), how about reviving arrows and avoiding the non-LR(1) parsing
for grammar validation problem?
ArrowFunctionExpression :
- ArrowFormalParameters_opt AssignmentExpression
- ArrowFormalParameters_opt ArrowBodyBlock_opt
ArrowFormalParameters :
( FormalParameterList_opt )
( this Initialiser_opt )
( this Initialiser_opt , FormalParameterList )
Someone with nick satyr mentioned this to me on irc.mozilla.org #jslang
just recently, referencing Ruby 1.9 and Perl6.
If this looks good I can edit
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
and remove the words in it that set it up as a mutually exclusive
alternative to
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival.
Please note that the last one seems very complex to write using a
block-lambda :
array.map({|x|let returnValue;
while(x.parentNode) {
x=x.parentNode;
if(x.tagName==’DIV’) { returnValue=x; break; }
}
if(returnValue) {
returnValue;
} else {
console.log(‘An element that has no parent DIV has been
found.’);
undefined;
}
});
Good point.
Re: Block lambda is cool, its syntax isn't
I have an obvious bias towards 1 because I think Unicode symbols
describe much better the underlying intentions and semantics than
their ASCII alternatives (usually), however not many people creates
mappings for these symbols on their .XCompose (or even have a compose
key handy).
I remember you mentioning that the Haskell-ish alternative `\x, y {
body }' or `.\x, y { body }' was not practical, because \ is already a
valid escaping character in identifiers (?)
Given those above, despite my usual disliking of Ruby syntax, I prefer
the pipes over parenthesis, given the latter has an already too
overloaded semantics, such that `{ (foo, bar) (2) }' would look pretty
confusing, at least to me. However, what about `{x, y: body}'? Granted
we don't allow labels immediately following a lambda block (and I'm
not sure labels are used much in the language, I could be wrong
however).
2012/1/13 Brendan Eich bren...@mozilla.org:
We have three coarse-grained alternatives:
1. λ (params) { body }
1a. One problem is what should we use for λ? 'lambda', 'block', etc. are not
reserved the syntax. Whatever the identifier (including Greek lambda: λ),
this is an incompatible change.
1b. Another problem: this form looks like a function expression with a
different introductory keyword, but Tennent's Correspondence Principle makes
the meaning of body elements including |this| and return/break/continue
radically different. Different-enough semantics should have different
syntax.
2. { (params) body }
Putting the parameter list in parentheses is more consistent with function
syntax, while putting the parameters on the inside stresses the block-ness
over function-ness. By block-ness I mean (ignoring let, const, and function
in Harmony) how code and {code} are equivalent.
Of course this cuts against the syntax too: block statements are not
first-class callables whose code bodies are evaluated only if invoked, they
are statements evaluated eagerly when reached. This syntax is arguably too
block-like.
A point that I remember having come up in past TC39 meetings: if we ever
want structuring forms (object literals or destructuring patterns) that use
() for grouping property names, this syntax is future hostile.
3. { |params| body }
This is new-to-JS, idiomatic block-like -- but not too block-statement-like
-- syntax for novel body semantics.
The bars will drive some people to distraction. Others will grok, or already
do via Ruby. This is not to favor Ruby, just to build on the belief that
some precedent in language design is better than none.
We could reject (3) in favor of (2) if we had an overriding non-aesthetic
reason. I don't see one.
Aesthetics vary. The more conventional look of (2) seems like a usability
hazard to me, which trumps aesthetics. Again I'd rather have something more
different-looking to signal the novel application of TCP.
/be
___
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: Block lambda is cool, its syntax isn't
Arrows are not a live
proposal because TC39 wants to keep LR(1) parsing for grammar validation
(checking for ambiguities). We do not have consensus to change and
there's no champion working on a credible alternative.
I could have dredged them up but they really are not happening, whereas
we have recurring and live proposals for the three body-plans I listed.
/be
Sam Ruby
January 13, 2012
3:30 AM
On Fri, Jan 13, 2012 at 12:20 AM, Brendan Eich bren...@mozilla.org wrote:
We have three coarse-grained alternatives:
If you are going to enumerate all potential alternatives (including
ones that you need to be rejected for one reason or another), then a
CoffeeScript inspired syntax should be included:
(params) - {body}
- Sam Ruby
1. λ (params) { body }
1a. One problem is what should we use for λ? 'lambda', 'block', etc. are not
reserved the syntax. Whatever the identifier (including Greek lambda: λ),
this is an incompatible change.
1b. Another problem: this form looks like a function _expression_ with a
different introductory keyword, but Tennent's Correspondence Principle makes
the meaning of body elements including |this| and return/break/continue
radically different. Different-enough semantics should have different
syntax.
2. { (params) body }
Putting the parameter list in parentheses is more consistent with function
syntax, while putting the parameters on the inside stresses the block-ness
over function-ness. By block-ness I mean (ignoring let, const, and function
in Harmony) how code and {code} are equivalent.
Of course this cuts against the syntax too: block statements are not
first-class callables whose code bodies are evaluated only if invoked, they
are statements evaluated eagerly when reached. This syntax is arguably too
block-like.
A point that I remember having come up in past TC39 meetings: if we ever
want structuring forms (object literals or destructuring patterns) that use
() for grouping property names, this syntax is future hostile.
3. { |params| body }
This is new-to-JS, idiomatic block-like -- but not too block-statement-like
-- syntax for novel body semantics.
The bars will drive some people to distraction. Others will grok, or already
do via Ruby. This is not to favor Ruby, just to build on the belief that
some precedent in language design is better than none.
We could reject (3) in favor of (2) if we had an overriding non-aesthetic
reason. I don't see one.
Aesthetics vary. The more conventional look of (2) seems like a usability
hazard to me, which trumps aesthetics. Again I'd rather have something more
different-looking to signal the novel application of TCP.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich
January 12, 2012
9:20 PM
We have three
coarse-grained alternatives:
1. λ (params) { body }
1a. One problem is what should we use for λ?
'lambda', 'block', etc. are not reserved the syntax. Whatever the
identifier (including Greek lambda: λ), this
is an incompatible change.
1b. Another problem: this form looks like a function _expression_ with a
different introductory keyword, but Tennent's Correspondence Principle
makes the meaning of body elements including |this| and
return/break/continue radically different. Different-enough semantics
should have different syntax.
2. { (params) body }
Putting the parameter list in parentheses is more consistent with
function syntax, while putting the parameters on the inside stresses the
block-ness over function-ness. By block-ness I mean (ignoring let,
const, and function in Harmony) how code
and {code} are equivalent.
Of course this cuts against the syntax too: block statements are not
first-class callables whose code bodies are evaluated only if invoked,
they are statements evaluated eagerly when reached. This syntax is
arguably too block-like.
A point that I remember having come up in past TC39 meetings: if we ever
want structuring forms (object literals or destructuring patterns) that
use () for grouping property names, this syntax is future hostile.
3. { |params| body }
This is new-to-JS, idiomatic block-like -- but not too
block-statement-like -- syntax for novel body semantics.
The bars will drive some people to distraction. Others will grok, or
already do via Ruby. This is not to favor Ruby, just to build on the
belief that some precedent in language design is better
than none.
We could reject (3) in favor of (2) if we had an overriding
non-aesthetic reason. I don't see one.
Aesthetics vary. The more conventional look of (2) seems like a
usability hazard to me, which trumps aesthetics. Again I'd rather have
something more different-looking to signal the novel application of TCP.
/be
Brendan Eich
January 12, 2012
7:23 PM
Sigh. Never mind, I'm
thinking of statement not _expression_ context --
Re: Block lambda is cool, its syntax isn't
Quildreen Motta
January 13, 2012
5:30 AM
Given
those above, despite my usual disliking of Ruby syntax, I preferthe
pipes over parenthesis, given the latter has an already toooverloaded
semantics, such that `{ (foo, bar) (2) }' would look prettyconfusing,
at least to me. However, what about `{x, y: body}'?
Parameters have optional guards (in the future), default value
initialisers, destructuring patterns and so on. Using : is no good
because, while we might manage to keep the grammar unambiguous, it is
too visually light and is not a close-bracket. It's already used in ?:
and labels.
Grantedwe don't allow labels immediately following a
lambda block (and I'mnot sure labels are used much in the language, I
could be wronghowever).
Consider { x, y=a?b:c : body }.
/be
Brendan Eich
January 12, 2012
9:20 PM
We have three
coarse-grained alternatives:
1. λ (params) { body }
1a. One problem is what should we use for λ?
'lambda', 'block', etc. are not reserved the syntax. Whatever the
identifier (including Greek lambda: λ), this
is an incompatible change.
1b. Another problem: this form looks like a function _expression_ with a
different introductory keyword, but Tennent's Correspondence Principle
makes the meaning of body elements including |this| and
return/break/continue radically different. Different-enough semantics
should have different syntax.
2. { (params) body }
Putting the parameter list in parentheses is more consistent with
function syntax, while putting the parameters on the inside stresses the
block-ness over function-ness. By block-ness I mean (ignoring let,
const, and function in Harmony) how code
and {code} are equivalent.
Of course this cuts against the syntax too: block statements are not
first-class callables whose code bodies are evaluated only if invoked,
they are statements evaluated eagerly when reached. This syntax is
arguably too block-like.
A point that I remember having come up in past TC39 meetings: if we ever
want structuring forms (object literals or destructuring patterns) that
use () for grouping property names, this syntax is future hostile.
3. { |params| body }
This is new-to-JS, idiomatic block-like -- but not too
block-statement-like -- syntax for novel body semantics.
The bars will drive some people to distraction. Others will grok, or
already do via Ruby. This is not to favor Ruby, just to build on the
belief that some precedent in language design is better
than none.
We could reject (3) in favor of (2) if we had an overriding
non-aesthetic reason. I don't see one.
Aesthetics vary. The more conventional look of (2) seems like a
usability hazard to me, which trumps aesthetics. Again I'd rather have
something more different-looking to signal the novel application of TCP.
/be
Brendan Eich
January 12, 2012
7:23 PM
Sigh. Never mind, I'm
thinking of statement not _expression_ context -- and you can't start an
_expression_ statement with {. Parade's back on. :-)
/be
Brendan Eich
January 12, 2012
7:21 PM
Sorry, thought about it
more and I'm raining on your (and dherman's) parade :-(.
In an _expression_ but not statement context,
... { (x) e; }
is already a valid JS program if e begins with (, [, +, or - (the last
two intended as unary operators but becoming binary).
Note that | bracketing avoids this problem. In no case can JS of any
extant version have a legal sequence {|.
But because {( is already allowed, what comes after the closing ) can be
the continuation of a parenthesized _expression_.
Even if you don't buy my "better to look different because not function"
argument, this tilts the balance.
/be
Brendan Eich
January 12, 2012
4:53 PM
... continuing
with my sent-too-soon message:
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
You're right, this could be done. Allen's right that aesthetics matter,
and so (aesthetic sensibilities in various people were formed by these)
do older languages. Ruby uses || not (). Smalltalk uses | but
differently, and of course does not use {}.
Apart from aesthetics, I argue that || are better because they are
different from the overloaded () pair, which mean _expression_ grouping in
the nearby context of the body of the block-lambda, e.g. a.add()b;
above. () also are used around formal parameter lists. And of course
they are used for control structure heads, e.g. if (foo).
Rather than overloading () yet again, for a different formal parameter
list context (block-lambda parameter list after {), which is immediately
adjacent to an _expression_-statement contexts (the block-lambda body), I
believe we should use ||.
The Ruby precedent is another reason, and a particular reason to use |
instead of some other candidate. But I'm mainly trying to persuade you
here that () is not the best
Re: Block lambda is cool, its syntax isn't
On Jan 13, 2012, at 6:09 AM, john saylor wrote: hello world! On 01/12/2012 09:09 PM, David Herman wrote: It does help to write a reasonable chunk of code to compare syntaxes for uses of a feature in the wild. Does some enterprising es-discusser wanna take a big JS program with a bunch of little anonymous functions, swap them out with block lambdas, and make two gists with the two different syntaxes? That'd be super helpful. i think this would be very helpful too [although, sadly, since i am overcommitted as it is, it will not be me]. I've updated a version of my ES.next Smalltalk collections implementation experiment to use block lambdas. This version is https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.js The one that you should compare it to is https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.js As you might expect, this new version is even closer in form to the original Smalltalk code. In particularly, I was able to eliminate all the artifacts that needed to be introduced because of function expressions don't have Tennent's Correspondence. In the source, I've tagged the lines where TCP is using /*TCP*/ Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
FWIW, After working through the example gists that I created last night, my
opinion changed about the look of Block Lambda's with pipes. As others on
the list have said previously and is now very clear to me, pipes provide a
very distinct visual cue this is a block lambda, expect X to happen here
where the {(args) expr } gets lost; these visual cues are important when
you're reading and writing real world programs in JavaScript.
Rick
On Fri, Jan 13, 2012 at 1:51 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jan 13, 2012, at 6:09 AM, john saylor wrote:
hello world!
On 01/12/2012 09:09 PM, David Herman wrote:
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch of little anonymous functions, swap them
out with block lambdas, and make two gists with the two different syntaxes?
That'd be super helpful.
i think this would be very helpful too [although, sadly, since i am
overcommitted as it is, it will not be me].
I've updated a version of my ES.next Smalltalk collections implementation
experiment to use block lambdas.
This version is
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.js
The one that you should compare it to is
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.js
As you might expect, this new version is even closer in form to the
original Smalltalk code.
In particularly, I was able to eliminate all the artifacts that needed to
be introduced because of function expressions don't have Tennent's
Correspondence.
In the source, I've tagged the lines where TCP is using /*TCP*/
Allen
___
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: Block lambda is cool, its syntax isn't
On 01/13/2012 03:36 PM, Rick Waldron wrote:
As
others on the list have said previously and is now very clear to me,
pipes provide a very distinct visual cue this is a block lambda, expect
X to happen here where the {(args) expr } gets lost; these visual cues
are important when you're reading and writing real world programs in
JavaScript.
yes, i had the same impression [thx to those who supplied code examples].
one problem i came across in this domain is that a block lambda with no
arguments is visually identical to a boolean or ['||']. context, i
believe, will clarify this; but from a purely visual perspective, two
adjacent pipe characters are almost archetypal for the boolean or
operator [if i can speak about archetypes in computer programming].
--
http://or8.net/~johns yeah yeah yeah -beatles
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
The { and } around the ||
make it pretty clear the || is not a boolean. Also you can put a space
in {| |}. But mainly, as with any alternative bracketing system that
uses an infix operator, we are relying on the leading { to make it clear
that the immediately following delimiter, | in the proposal, cannot
represent its usual infix role (| or ||).
/be
john saylor
January 13, 2012
1:11 PM
yes, i had the same impression [thx to those who supplied code
examples].
one problem i came across in this domain is that a block lambda with
no
arguments is visually identical to a boolean or ['||']. context, i
believe, will clarify this; but from a purely visual perspective, two
adjacent pipe characters are almost archetypal for the boolean or
operator [if i can speak about archetypes in computer programming].
Rick Waldron
January 13, 2012
12:36 PM
FWIW, After working through the
example gists that I created last night, my opinion changed about the
look of Block Lambda's with pipes. As others on the list have said
previously and is now very clear to me, pipes provide a very distinct
visual cue "this is a block lambda, expect X to happen here" where the
{(args) expr } gets lost; these visual cues are important when you're
reading and writing "real world" programs in _javascript_.
Rick
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock
January 13, 2012
10:51 AM
I've updated a
version of my ES.next Smalltalk collections implementation experiment to
use block lambdas.This version ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0-blp.jsThe
one that you should compare it to ishttps://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.jsAs
you might expect, this new version is even closer in form to the
original Smalltalk code.In particularly, I was able to
eliminate all the artifacts that needed to be introduced because of
function expressions don't have Tennent's Correspondence.In
the source, I've tagged the lines where TCP is using /*TCP*/Allen___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
john saylor
January 13, 2012
6:09 AM
hello world!
i think this would be very helpful too [although, sadly, since i am
overcommitted as it is, it will not be me].
David Herman
January 12, 2012
6:09 PM
On Jan 12, 2012, at 2:23 PM, Franois REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as a statement by itself. If it's the case, it should defined as an _expression_ only, where there's no anonymous block to conflict the syntax. That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for uses of a feature "in the wild." Does some enterprising es-discusser wanna take a big JS program with a bunch of little anonymous functions, swap them out with block lambdas, and make two gists with the two different syntaxes? That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous block in some future revision of ES, that very small edge case could vanish at the same time.
I don't understand what you're referring to here -- what do you mean by "unprefixed anonymous block?"
Does it seems possible/acceptable?
Lovely.
Dave
___
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: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 4:26 PM, Thaddee Tyl thaddee@gmail.com wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it can.
And if people choose to use newlines in their code?
{(a, b)
a + b}
... already has a meaning.
-Jon
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it can.
but it is ambiguous with other currently valid statement blocks such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can be
resolved by adding parenthesis, like with the current object notation. And
since I still continue to hope we'll ditch the unprefixed anonymous block in
some future revision of ES, that very small edge case could vanish at the
same time.
Does it seems possible/acceptable?
-Message d'origine-
From: Allen Wirfs-Brock
Sent: Thursday, January 12, 2012 10:38 PM
To: Thaddee Tyl
Cc: es-discuss@mozilla.org
Subject: Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it
can.
but it is ambiguous with other currently valid statement blocks such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
___
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: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 11:23 PM, François REMY
fremycompany_...@yahoo.fr wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can be
resolved by adding parenthesis, like with the current object notation. And
since I still continue to hope we'll ditch the unprefixed anonymous block in
some future revision of ES, that very small edge case could vanish at the
same time.
Does it seems possible/acceptable?
Looks like a great idea to me!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 12, 2012 2:23 PM
Am I wrong if I say there not a bigger issue with block lambda than
with the current object notation on the matter?
Please continue :-).
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
(You need a name for that function if it is a declaration, and from the
context you show, it is.)
Does this perfectly valid JS mean anything useful?
function f() {
(function (a, b) { return a + b; });
}
Nevertheless, it is legal. JS follows C (not Java) in allowing seemingly
useless expression-statements. This can be a source of bugs. It is also
required in some cases, namely when the function expression (in
parentheses) is the completion value of a Program. In such a case that
value could be the wanted result of eval or an eval-like host API.
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as
an Expression only,
Expression is already a kind of statement, via ExpressionStatement.
Furthermore, an ExpressionStatement *already* cannot start with a left
curly brace. Please read the grammar:
12.4 Expression Statement
Syntax
ExpressionStatement :
[lookahead ? {{, function}] Expression ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an
ExpressionStatement cannot start with the function keyword because that
might make it ambiguous with a FunctionDeclaration.
where there's no anonymous block to conflict the syntax.
This is the conflict you're looking for.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
That is already valid ES1-6.
Others have already replied, but the problem with redefining ( after {
without untenable newline sensitivity is it is a backward-incompatible
change.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I think you're correct. An ExpressionStatment can not begin with a {
so,without changing that rule, there should be no potential for ambiguity
between Block and BlockLambda. The only issue is distinguishing ObjectLiteral
and BlockLambda and from that perspective a {( is as good as a {| as neither
is ambiguous with existing ObjectLiteral syntax,
At that point, it becomes a matter of taste. Which of {|x| x.foo()} or {(x)
x.foo()} looks better to you? I find the | | more pleasant and easer for my
eyes to pick out, but I'm undoubtably influenced by many years of reading and
writing Smalltalk code.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 5:52 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I think you're correct. An ExpressionStatment can not begin with a {
so,without changing that rule, there should be no potential for ambiguity
between Block and BlockLambda. The only issue is distinguishing
ObjectLiteral and BlockLambda and from that perspective a {( is as good as
a {| as neither is ambiguous with existing ObjectLiteral syntax,
An additional consideration: for a block lambda's completion value to
be another block lambda, the {( syntax would require parenthesis,
while the {| syntax would not:
let succ =
{(x)
{(s)
{(z)
s(x(s)(z))
}}};
With the grammar François is suggesting, this would be a syntax error
(I think), since the body of a block lambda is a StatementList_opt.
The {| syntax, on the other hand, can accommodate block lambdas as
expression statements, though, given another token of lookahead
(again, I think).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 7:11 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 12, 2012, at 3:41 PM, Jon Zeppieri wrote:
...
With the grammar François is suggesting, this would be a syntax error
(I think), since the body of a block lambda is a StatementList_opt.
The {| syntax, on the other hand, can accommodate block lambdas as
expression statements, though, given another token of lookahead
(again, I think).
With two token look-ahead a | BlockLambda could be allowed at the head of a
statement, but it still would not enable unparenthesized object literals at
the head of a statement. It seems like a cognitive burden to allow one but
not the other. A simple { at the start of an expression statement must be
parenthesized rules seems easiest to learn and remember.
Allen
That's a good point, but I think that unparenthesized block lambdas
might be worth this complication. I hadn't considered object literals,
at all, while writing the previous message, and I don't think that was
simply an oversight. Object literals and blocks have a similar syntax
but dissimilar meaning. Block lambdas, on the other hand, are
semantically kinda-sorta like blocks. You don't need to parenthesize
nested blocks in JS code. (In fact, you can't.) That leads me to
expect unparenthesized block lambdas.
I guess it depends, to some extent, whether you think block lambdas
and object literals have more in common with each other (both being
first-class values) than block lambdas and blocks do (both being lists
of statements).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
... continuing with my sent-too-soon message:
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
You're right, this could be done. Allen's right that aesthetics matter,
and so (aesthetic sensibilities in various people were formed by these)
do older languages. Ruby uses || not (). Smalltalk uses | but
differently, and of course does not use {}.
Apart from aesthetics, I argue that || are better because they are
different from the overloaded () pair, which mean expression grouping in
the nearby context of the body of the block-lambda, e.g. a.add()b;
above. () also are used around formal parameter lists. And of course
they are used for control structure heads, e.g. if (foo).
Rather than overloading () yet again, for a different formal parameter
list context (block-lambda parameter list after {), which is immediately
adjacent to an expression-statement contexts (the block-lambda body), I
believe we should use ||.
The Ruby precedent is another reason, and a particular reason to use |
instead of some other candidate. But I'm mainly trying to persuade you
here that () is not the best choice just because it brackets formal
parameter lists for functions.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course more
consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for uses
of a feature in the wild. Does some enterprising es-discusser wanna take a
big JS program with a bunch of little anonymous functions, swap them out with
block lambdas, and make two gists with the two different syntaxes? That'd be
super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous block
in some future revision of ES, that very small edge case could vanish at the
same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
From the perspective of someone who writes JS every day, the parens look
and feel right.
Dave, you asked for some example code, this is actually from task.js:
https://gist.github.com/e4e0e349f9cf35ad3370
On Thu, Jan 12, 2012 at 9:09 PM, David Herman dher...@mozilla.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as an
Expression only, where there's no anonymous block to conflict the syntax.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course
more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch of little anonymous functions, swap them
out with block lambdas, and make two gists with the two different syntaxes?
That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous
block in some future revision of ES, that very small edge case could vanish
at the same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
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: Block lambda is cool, its syntax isn't
This one is from https://github.com/ecto/duino/blob/master/lib/board.js and
has more real world uses
https://gist.github.com/d2c8fcbab5a3da4c4dae
Rick
On Thu, Jan 12, 2012 at 9:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
From the perspective of someone who writes JS every day, the parens look
and feel right.
Dave, you asked for some example code, this is actually from task.js:
https://gist.github.com/e4e0e349f9cf35ad3370
On Thu, Jan 12, 2012 at 9:09 PM, David Herman dher...@mozilla.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as an
Expression only, where there's no anonymous block to conflict the syntax.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No
semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course
more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch of little anonymous functions, swap them
out with block lambdas, and make two gists with the two different syntaxes?
That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous
block in some future revision of ES, that very small edge case could vanish
at the same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
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: Block lambda is cool, its syntax isn't
b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No
semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can
be
resolved by adding parenthesis, like with the current object notation.
And
since I still continue to hope we'll ditch the unprefixed anonymous
block in
some future revision of ES, that very small edge case could vanish at
the
same time.
Does it seems possible/acceptable?
-Message d'origine-
From: Allen Wirfs-Brock
Sent: Thursday, January 12, 2012 10:38 PM
To: Thaddee Tyl
Cc: es-discuss@mozilla.org
Subject: Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
but it is ambiguous with other currently valid statement blocks
such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
___
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
Allen Wirfs-Brock
January 12, 2012
1:38 PM
but it is
ambiguous with other currently valid statement blocks such as:
{ (a, b) + b}or { (a,b) a+b }Allen___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
