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
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
, 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
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
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 @?
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
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
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
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,
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
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
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.
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 ?
-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
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
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
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
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
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
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
; 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
(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 ƒ
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
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
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(){
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,
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( ƒ
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
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
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
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
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
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
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,
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
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
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,
-
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
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
() { ... { ... 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
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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};
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
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
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
... 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 ||
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
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,
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
sion 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
72 matches
Mail list logo
