Re: arrow syntax unnecessary and the idea that function is too long
Because the LabelledStatement changes in
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
restrict labels to prefix only LabelUsingStatements. I was
addressing the backward incompatibility here: ES1-5 allow
useless labels. You seemed to think that incompatibility was
important enough to require new label syntax, but I argued
that it is (a) not important; (b) caught by early error
during migration.
Ok, so you want to restrict label use. But syntax alone cannot
guarantee that a given label prefix is ever actually used, it can
only rule out alternatives that cannot possibly use the label.
And introducing such syntactic restrictions on label use means
that one can no longer insert labels without thinking about
whether they can be used because inserting unused labels
might require rewriting the code. In any case, the result is
that both parser writers and developers have to think about
the restrictions that make labeled Statements different from
Statements.
I still have a few blind spots where things that I thought
about for this class of language are not actually permitted
by the Javascript grammar, so perhaps LabelUsingStatement
won't introduce enough additional complexity to worry
about. But, generally speaking, I'd prefer to remove
complexity from the grammar, rather than add it.
It isn't that I like labels, but if labels are permitted, I prefer
them not introducing additional complexity that I have to
think about. So my comments were based on not having
the LabelledStatement changes, addressing the ambiguity
in another way.
Without changes, any grammar that has ObjectLiteral and
Block as alternatives is ambiguous:
ObjectLiteral | Block// ambiguous
Assuming we want to resolve ambiguities by preferring
ObjectLiteral, we could write
ObjectLiteral | (Block butnot ObjectLiteral)
where the right branch is the implicit grammar for what you
are aiming to spec explicitly, by removing the ambiguous
cases from Block, specifically from LabelledStatement, to
give us some form of RestrictedBlock that doesn't conflict
with ObjectLiteral. So we can combine both in arrow bodies
ObjectLiteral | RestrictedBlock
(PEG-style grammars could make that even more implicit,
via ordered choice: anything that is a valid ObjectLiteral
can no longer reach the second alternative)
The problem I have with that is that I need to think far
ahead to figure out whether I'm writing an ObjectLiteral
or a RestrictedBlock and that I need to be aware of whether
the Statement I'm writing follows a label or not.
So I'm looking for a way to introduce a committed choice
based on limited lookahead instead. It seems that the
IdentifierName (PropertyName) vs Identifier (label) case
is the one that can lead to long lookaheads, so breaking
that seems a step forward. Hence the new-style labels.
It is not necessary to remove old-style labels right away,
because old code that uses them only uses old language
constructs (which never mix ObjectLiteral and Block). For
code that opts into Harmony, a deprecation warning for
old-style label seems appropriate, but we don't need to
force code rewrites of old code.
For any new language constructs that do mix ObjectLiteral
and Block, such as arrow syntax, we can arrange that
'{ Identifier : .. }' always defaults to ObjectLiteral, no matter
what comes next. In these positions, old-style labels are
useless, but new language constructs are only used in
new code, so we can ask developers to use new label
syntax if they want a Block starting with a label in such
positions.
In grammar terms, the arbitrary lookahead alternative
ObjectLiteral | (Block butnot ObjectLiteral)
turns into something like
ObjectLiteral | (Block butnot ('{' (Identifier|StringLiteral) ':' .*)
If this works out, parsers and programmers can commit
to one of the alternatives after a limited lookahead, no
matter what comes next. Committed choice also means
no backtracking, so '{ empty: ; }' would be an invalid
ObjectLiteral, not a valid Block, if used as an arrow body
(while '{ :empty: ; }' would be an empty block).
So there are pros and cons - the means of disambiguation
are easier to understand, but not as expressive.
Now I don't see any solution in adding new label syntax.
Having to parse the old one leaves us with the ambiguity.
What am I missing?
Old labels in old code don't use new features, like arrow
syntax, so the ambiguity does not surface. Old labels in
new code using arrow syntax will be overlapped by object
property names, so the ambiguity is resolved. New labels
in new code using arrow syntax allow to override the
default ambiguity resolution.
but add labels starting with, say ':' (just to pick a prefix).
We really don't want two label syntaxes, ..
Right. The old syntax could be deprecated (when opting in
for ES/next) - it also doesn't allow label parameters or
label variables.
Do you mean prohibited or deprecated? Usually
Re: arrow syntax unnecessary and the idea that function is too long
On May 22, 2011, at 2:01 AM, Claus Reinke wrote:
Because the LabelledStatement changes in
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
restrict labels to prefix only LabelUsingStatements. I was addressing the
backward incompatibility here: ES1-5 allow useless labels. You seemed to
think that incompatibility was important enough to require new label syntax,
but I argued that it is (a) not important; (b) caught by early error during
migration.
Ok, so you want to restrict label use. But syntax alone cannot
guarantee that a given label prefix is ever actually used, it can
only rule out alternatives that cannot possibly use the label.
The purpose is not to restrict labels to prefix statements that might possibly
refer to them, for that sake. Misplaced labels are harmless.
The purpose is to parse block and object initialiser in the same context,
unambiguously.
Without changes, any grammar that has ObjectLiteral and
Block as alternatives is ambiguous:
ObjectLiteral | Block// ambiguous
Not for a GLR parser with the proposed label restriction.
The problem I have with that is that I need to think far
ahead to figure out whether I'm writing an ObjectLiteral
or a RestrictedBlock and that I need to be aware of whether the Statement I'm
writing follows a label or not.
Not a practical problem. Labels are rare anywhere, even more rare immediately
after a {, and of course useless if labeling an expression-statement.
So I'm looking for a way to introduce a committed choice
based on limited lookahead instead. It seems that the
IdentifierName (PropertyName) vs Identifier (label) case
is the one that can lead to long lookaheads, so breaking
that seems a step forward. Hence the new-style labels.
Please check the rehashing, you said this last time. I understand new style
labels as a disambiguating change, but we would have to prohibit old-style
labels, and that's not wanted if we can simply use GLR or better (you mentioned
PEG).
You seem to acknowledge that a more powerful parser could handle the
disambiguation, so why change the worry to one about I need to think far ahead
[when] writing? That is a shift of argument, and the new argument is not
credible: JS authors do not write labels much, and when they write object
initialisers, *under the proposal* they aren't writing labels inside, no way,
no how.
If we go this route of allowing block or object initialiser, then the right
answer is not to mangle label syntax in Harmony and put some work on JS
programmers migrating code into Harmony.
The right answer is for spec-writers (the few, the brave, blah blah) to step up
with GLR or better. Provided there's a sound top-down algorithm that
implementors can swallow.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
The top-down approach by default is to parse a cover grammar
until an unambiguous decision point is reached, then depending
on the decision, rewrite the AST (e.g., to make a labeled statement
in a block instead of an object initializer).
A somewhat less intrusive way to disambiguate blocks/objects
might be to separate labels from identifiers - keep the old labels
for backward compatibility,
Why do we need the old useless (unusable, literally) labels for
backward compatibility?
Yes, stray labels creep into JS. Typically you find javascript: at
the front of scripts. But finding and fixing these is a one time
migration step caught by an early error.
I don't understand how these comments relate to my suggestion,
so let me try to clarify what I was suggesting, and why:
- the grammars for block and objects share common prefixes,
leading to ambiguities that can be resolved by lookahead
- your proposal suggests parsing a cover grammar until
disambiguation, plus restrictions to LabelledStatement
- both LabelledStatement and PropertyAssignment permit
IdentifierName followed by ':', followed by something,
so disambiguation has to be in the something following
the ':', where overlaps like ExpressionStatement further
extend the ambiguity
My suggestion was simply to remove IdentifierName from
one of the two, by prefixing labels, thereby moving the
disambiguation point forward. By my estimate, that should
reduce the range of lookahead, the size of cover grammars,
and the need for restricted grammars.
I don't know what that has to do with stray labels, and it
is obviously not possible to remove the old label syntax
immediately. But it would be possible to disambiguate
conflicts between property names and block labels in
favour of property names.
but add labels starting with, say ':' (just to pick a prefix).
We really don't want two label syntaxes, ..
Right. The old syntax could be deprecated (when opting in
for ES/next) - it also doesn't allow label parameters or
label variables.
The block vs. object literal disambiguation part of the
proposal is at least as solid as the leading formal
parameter list, which parses as a comma expression
until you get to the arrow. Indeed TC39 may want the
label restriction and block vs. object literal part pulled
out -- we shall see.
I'm not trying to decide whether the proposal's version is
solid, but it is a non-trivial change, and I've seen non-trivial
suggestions shot down because they were thought to be
risky. The more options there are for dealing with the
object literals vs blocks ambiguity, the better the chances
for it actually happening. Also, special-casing labelled
statements increases the complexity of the grammar.
As a third, extreme option, one could disambiguate by
always preferring the object literal interpretation, and
ask programmers to start blocks in otherwise ambiguous
contexts with an empty statement ('{; ..}' cannot be an
object literal). That would require the fewest changes,
and perhaps it is all we need, but I'm not sure how
well it would work in practice, with existing code.
we should focus on the harder nut to crack (the leading
parenthesized parameter list).
Isn't that an example of issues that would not exist if
arrow functions had a prefix marker?
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 7:07 AM, Claus Reinke wrote:
The top-down approach by default is to parse a cover grammar until an
unambiguous decision point is reached, then depending on the decision,
rewrite the AST (e.g., to make a labeled statement in a block instead of
an object initializer).
A somewhat less intrusive way to disambiguate blocks/objects
might be to separate labels from identifiers - keep the old labels
for backward compatibility,
Why do we need the old useless (unusable, literally) labels for backward
compatibility?
Yes, stray labels creep into JS. Typically you find javascript: at the front
of scripts. But finding and fixing these is a one time migration step caught
by an early error.
I don't understand how these comments relate to my suggestion,
Because the LabelledStatement changes in
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax restrict
labels to prefix only LabelUsingStatements. I was addressing the backward
incompatibility here: ES1-5 allow useless labels. You seemed to think that
incompatibility was important enough to require new label syntax, but I argued
that it is (a) not important; (b) caught by early error during migration.
so let me try to clarify what I was suggesting, and why:
- the grammars for block and objects share common prefixes,
leading to ambiguities that can be resolved by lookahead
Only by arbitrarily long lookahead, alas.
- your proposal suggests parsing a cover grammar until
disambiguation, plus restrictions to LabelledStatement
I'm still working on the proposal. Cover grammar doesn't quite do the trick, in
the formalism we want. We don't want always to parse a
MaybeBlockOrObjectLiteral and handle the difference once we see a label on a
label-using-statement, or else a property name labeling an expression, by
semantics in the prose. We need a proper grammar for blocks and object literals.
- both LabelledStatement and PropertyAssignment permit
IdentifierName followed by ':', followed by something,
(LabelledStatement begins with Identifier, not IdentifierName. That only
complicates things a bit more ;-), but seems worth pointing out.)
so disambiguation has to be in the something following
the ':', where overlaps like ExpressionStatement further
extend the ambiguity
No, ExpressionStatement cannot be a LabelUsingStatement.
To be concrete, the problem is {L1:{L2:{L3:{L4:{LN: XYZZY where XYZZY
is neither of the form Identifier : nor {. Ignoring syntax errors, if XYZZY is
a reserved identifier, it must begin a LabelUsingStatement (or syntax error, in
the proposal). Otherwise, it must begin an InitialValue giving LN's property
value.
My suggestion was simply to remove IdentifierName from
one of the two, by prefixing labels, thereby moving the
disambiguation point forward.
I understood your proposal but perhaps I misunderstood that part of the
motivation seemed to be stray-label backward compatibility.
By my estimate, that should
reduce the range of lookahead, the size of cover grammars,
and the need for restricted grammars.
Indeed, just not sure anyone is up for an incompatible new label syntax. It may
be the least evil, though!
Labels are not much used intentionally in JS (for break and continue to label,
which came in only in ES3).
I don't know what that has to do with stray labels, and it
is obviously not possible to remove the old label syntax
immediately.
Now I don't see any solution in adding new label syntax. Having to parse the
old one leaves us with the ambiguity. What am I missing?
But it would be possible to disambiguate
conflicts between property names and block labels in
favour of property names.
Being able to disambiguate != having an unambiguous grammar, unfortunately.
Unless Harmony bans old label syntax, this doesn't help us write a spec-grammar.
but add labels starting with, say ':' (just to pick a prefix).
We really don't want two label syntaxes, ..
Right. The old syntax could be deprecated (when opting in
for ES/next) - it also doesn't allow label parameters or
label variables.
Do you mean prohibited or deprecated? Usually deprecation means a warning,
obsolescence or prohibition means removal.
The block vs. object literal disambiguation part of the proposal is at least
as solid as the leading formal parameter list, which parses as a comma
expression until you get to the arrow. Indeed TC39 may want the label
restriction and block vs. object literal part pulled out -- we shall see.
I'm not trying to decide whether the proposal's version is solid, but it is a
non-trivial change, and I've seen non-trivial
suggestions shot down because they were thought to be risky. The more options
there are for dealing with the object literals vs blocks ambiguity, the
better the chances for it actually happening. Also, special-casing labelled
statements increases the complexity of the grammar.
Truly, I'm
Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 7:43 AM, Brendan Eich wrote:
That is simpler, but I believe I have seen code like this:
L: { S1; S2; S3; } where S2 is a label-using statement, specifically a
break from the outer block, a sugared downward goto that skips S3.
Probably only in tests for labels!
Yes, the strawman proposes to break such code.
Oops, I'm wrong (pre-caffeine here, sorry!) -- the strawman has NonEmptyBlock
as a LabelUsingStatement, so does not break this at all.
So requiring {; or similar would be a simpler change and non-breaking in the
sense that one can rescue such code so it works in Harmony as it used to, by
adding one character. Good idea!
Your idea still may help make a single spec-grammar that does not require some
arbitrary-lookahead decision procedure on the side.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 7:07 AM, Claus Reinke wrote:
we should focus on the harder nut to crack (the leading parenthesized
parameter list).
Isn't that an example of issues that would not exist if
arrow functions had a prefix marker?
It is a deeper issue. ECMA-262 currently covers left-hand side of assignment
with LeftHandSideExpression, but that produces 42, not a valid LHS. Semantic
checks and mandatory errors in spec prose make up for the lack of a precise
grammar.
ES5, Clause 16, has
Attempts to call PutValue on any value for which an early determination can be
made that the value is not a Reference (for example, executing the assignment
statement 3=4).
Destructuring assignment -- not the binding forms, e.g. let {x, y} = obj; but
just assignment expressions, {x, y} = obj -- takes advantage of this cover
grammar approach, but it will require semantic checks. And as Waldemar points
out, this constrains RHS structuring via object and array initialisers to
have the same syntax (unless we add more semantic post-grammar restrictions
there too!) as the LHS destructuring patterns.
This may be a bad constraint. Type guards don't seem like they'll be only LHS
or RHS, indeed the :: choice for guard prefix was based on easy composing of
guards after property names in object initialisers. But some future extension
might want LHS and RHS to diverge.
Arrow functions really do want a different ArrorFormalParameters sub-grammar
from ( Expression ) where Expression is of course a comma-expression.
So I'm investigating GLR parsing. It can handle all of these cases without
ambiguity. It does not require implementatoins to have forking parsers, but it
is an attractive spec tool. More on this in a bit.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 11:06 AM, Brendan Eich wrote:
Destructuring assignment -- not the binding forms, e.g. let {x, y} = obj; but
just assignment expressions, {x, y} = obj -- takes advantage of this cover
grammar approach,
The example {x, y} assumes
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_shorthand
makes it to Harmony.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Some references to parsers that do not share ambiguity problems due to limited
lookahead such as GLR and PEG parsers.
http://www.cs.nyu.edu/rgrimm/papers/pldi06.pdf
http://www.cs.rit.edu/~ats/projects/jsm/paper.xml
http://www.cs.ucla.edu/~awarth/papers/dls07.pdf
From: Brendan Eich bren...@mozilla.com
To: Claus Reinke claus.rei...@talk21.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Friday, May 20, 2011 11:06 AM
Subject: Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 7:07 AM, Claus Reinke wrote:
we should focus on the harder nut to crack (the leading parenthesized parameter
list).
Isn't that an example of issues that would not exist if
arrow functions had a prefix marker?
It is a deeper issue. ECMA-262 currently covers left-hand side of assignment
with LeftHandSideExpression, but that produces 42, not a valid LHS. Semantic
checks and mandatory errors in spec prose make up for the lack of a precise
grammar.
ES5, Clause 16, has
Attempts to call PutValue on any value for which an early determination can be
made that the value is not a Reference (for example, executing the assignment
statement 3=4).
Destructuring assignment -- not the binding forms, e.g. let {x, y} = obj; but
just assignment expressions, {x, y} = obj -- takes advantage of this cover
grammar approach, but it will require semantic checks. And as Waldemar points
out, this constrains RHS structuring via object and array initialisers to
have the same syntax (unless we add more semantic post-grammar restrictions
there too!) as the LHS destructuring patterns.
This may be a bad constraint. Type guards don't seem like they'll be only LHS
or RHS, indeed the :: choice for guard prefix was based on easy composing of
guards after property names in object initialisers. But some future extension
might want LHS and RHS to diverge.
Arrow functions really do want a different ArrorFormalParameters sub-grammar
from ( Expression ) where Expression is of course a comma-expression.
So I'm investigating GLR parsing. It can handle all of these cases without
ambiguity. It does not require implementatoins to have forking parsers, but it
is an attractive spec tool. More on this in a bit.
/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: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 11:26 AM, Kam Kasravi wrote: Some references to parsers that do not share ambiguity problems due to limited lookahead such as GLR and PEG parsers. http://www.cs.nyu.edu/rgrimm/papers/pldi06.pdf http://www.cs.rit.edu/~ats/projects/jsm/paper.xml http://www.cs.ucla.edu/~awarth/papers/dls07.pdf The trick is not so much to use an expensive memoizing parser, or even a forking one that could be much more efficient, but to figure out how real JS parsers, which are all top down in the big VMs, should implement. Working on that... /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
For a presumed-done area, there has been a lot of activity in parser research recently, partially fueled by IDEs and DSLs (model-driven development with good generated tool support). For grammar spec purposes, it might be interesting to look at self-applications of these techniques (IDEs for parser development, with support for grammar analysis and debugging). I keep meaning to look at ANTLRWorks: The ANTLR GUI Development Environment http://www.antlr.org/works/index.html Anyway, the titles for two of those three urls, for those who don't have time to look right now: http://www.cs.nyu.edu/rgrimm/papers/pldi06.pdf Better Extensibility through Modular Syntax Robert Grimm http://www.cs.rit.edu/~ats/projects/jsm/paper.xml Monadic Parsing using JavaScript Axel T. Schreiner Independent of parsing, I recommend that readers of this thread scroll down to the interpreter (search for 'eval'). It gives an example of how an essential programming pattern (monads) is technically supported in Javascript, but mostly useless due to syntactic overhead: instead of bringing out the essential aspects, they get burried in syntax (and if one tries to shunt the 'return's out of the way, ASI says hello). Javascript coders, when faced with this issue, tend to split into two groups: one that abandons the variable binding functionality of monads and makes due with libraries, and one that writes preprocessors (the author here, also streamline.js and Jscex as just two recent examples from the nodejs list). Just as a further example for those still unconvinced by the case for better function syntax: it isn't sufficient, but it is necessary!-) http://www.cs.ucla.edu/~awarth/papers/dls07.pdf 404 for me? Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Thanks Claus for the synopsis and pointing out the 404. ometa is the last paper: http://www.tinlizzie.org/~awarth/papers/dls07.pdf, which is a javascript packrat parser. Tom and Mark are very familiar with this work I believe. There are some great examples of javascript monads or monad-like frameworks - for example jquery ... It's unfortunate the harmony grammar cannot take advantage of these more recent advances in parsing, however I understand Brendan's point about accommodating the major implementors. Any transpiler could certainly go this route. From: Claus Reinke claus.rei...@talk21.com To: Kam Kasravi kamkasr...@yahoo.com; Brendan Eich bren...@mozilla.com Cc: es-discuss es-discuss@mozilla.org Sent: Friday, May 20, 2011 2:11 PM Subject: Re: arrow syntax unnecessary and the idea that function is too long For a presumed-done area, there has been a lot of activity in parser research recently, partially fueled by IDEs and DSLs (model-driven development with good generated tool support). For grammar spec purposes, it might be interesting to look at self-applications of these techniques (IDEs for parser development, with support for grammar analysis and debugging). I keep meaning to look at ANTLRWorks: The ANTLR GUI Development Environment http://www.antlr.org/works/index.html Anyway, the titles for two of those three urls, for those who don't have time to look right now: http://www.cs.nyu.edu/rgrimm/papers/pldi06.pdf Better Extensibility through Modular Syntax Robert Grimm http://www.cs.rit.edu/~ats/projects/jsm/paper.xml Monadic Parsing using JavaScript Axel T. Schreiner Independent of parsing, I recommend that readers of this thread scroll down to the interpreter (search for 'eval'). It gives an example of how an essential programming pattern (monads) is technically supported in Javascript, but mostly useless due to syntactic overhead: instead of bringing out the essential aspects, they get burried in syntax (and if one tries to shunt the 'return's out of the way, ASI says hello). Javascript coders, when faced with this issue, tend to split into two groups: one that abandons the variable binding functionality of monads and makes due with libraries, and one that writes preprocessors (the author here, also streamline.js and Jscex as just two recent examples from the nodejs list). Just as a further example for those still unconvinced by the case for better function syntax: it isn't sufficient, but it is necessary!-) http://www.cs.ucla.edu/~awarth/papers/dls07.pdf 404 for me? Claus___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 20, 2011, at 2:11 PM, Claus Reinke wrote: Just as a further example for those still unconvinced by the case for better function syntax: it isn't sufficient, but it is necessary!-) Good example. Shows how shorter syntax to avoid the 8-letter 'function' is not enough, 'return' elimination via expression-language completion value or something like it is needed too. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Ok, final and most delicate part of the mission here:
allow (v) - {k: v} and even - {} to return objects,
not make useless block statements.
..
Thanks to Doug for pushing on this idea. I believe that it is
sound (still to be formalized and tested mechanically) in a
bottom-up parser.
The top-down approach by default is to parse a cover grammar
until an unambiguous decision point is reached, then depending
on the decision, rewrite the AST (e.g., to make a labeled statement
in a block instead of an object initializer).
A somewhat less intrusive way to disambiguate blocks/objects
might be to separate labels from identifiers - keep the old labels
for backward compatibility, but add labels starting with, say ':'
(just to pick a prefix).
Then, new syntax, such as arrow functions, could default to
assuming objects when they see '{ identifier: .. }', while
programmers could write '{ :identifier: .. }' if they want a block
starting with a label instead. Disambiguation would not have
to look far ahead and there would be less grammar duplication,
which might translate into reduced potential for things going
wrong. Empty block values are far from useless, but should be
possible as '-{;}' or '-{:empty:;}'.
I would still prefer combining the infix arrow with a prefix marker,
to avoid ambiguities (for human readers and non-human parsers),
some of which might only arise in combinations with future features.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Wed, 11 May 2011 02:44:30 +0200, Brendan Eich bren...@mozilla.com
wrote:
I've mooted \ along with ƒ, etc. for a while. \ is bad for readability
because it's visually light, but worse, if we want named function
expression shorthand, then \u10A0(){} is a valid
Unicode-identifier-char-named function expression.
Is there a plan to make arrow notation allow named function expressions?
/L
--
Lasse Reichstein - reichsteinatw...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 19, 2011, at 2:42 AM, Lasse Reichstein wrote:
Hi Lasse.
On Wed, 11 May 2011 02:44:30 +0200, Brendan Eich bren...@mozilla.com wrote:
I've mooted \ along with ƒ, etc. for a while. \ is bad for readability
because it's visually light, but worse, if we want named function expression
shorthand, then \u10A0(){} is a valid Unicode-identifier-char-named function
expression.
Is there a plan to make arrow notation allow named function expressions?
Not in the strawman. Without a leading special character, that's a bridge too
far.
Even now the ambiguity with comma expression requires a cover-grammar parsing
hack, which is used for destructuring assignment and even (going back to ES1)
left-hand side of assignment. This hack is done for assignments, doable for
destructuring (SpiderMonkey and Rhino do it), and controversial for arrow
function formal parameter vs. comma expression parsing.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 19, 2011, at 1:46 AM, Claus Reinke wrote:
Ok, final and most delicate part of the mission here: allow (v) - {k: v}
and even - {} to return objects, not make useless block statements.
..
Thanks to Doug for pushing on this idea. I believe that it is sound (still
to be formalized and tested mechanically) in a bottom-up parser.
The top-down approach by default is to parse a cover grammar until an
unambiguous decision point is reached, then depending on the decision,
rewrite the AST (e.g., to make a labeled statement in a block instead of an
object initializer).
A somewhat less intrusive way to disambiguate blocks/objects
might be to separate labels from identifiers - keep the old labels
for backward compatibility,
Why do we need the old useless (unusable, literally) labels for backward
compatibility?
Yes, stray labels creep into JS. Typically you find javascript: at the front of
scripts. But finding and fixing these is a one time migration step caught by an
early error.
but add labels starting with, say ':'
(just to pick a prefix).
We really don't want two label syntaxes, especially if there is no strong
compatibility argument for stray labels, and they can be detected as early
errors in Harmony.
The block vs. object literal disambiguation part of the proposal is at least as
solid as the leading formal parameter list, which parses as a comma expression
until you get to the arrow. Indeed TC39 may want the label restriction and
block vs. object literal part pulled out -- we shall see.
So I say: stray label compatibility is a non-issue and we should focus on the
harder nut to crack (the leading parenthesized parameter list).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 16, 2011, at 7:55 PM, Peter Michaux wrote: On Mon, May 9, 2011 at 6:02 PM, Brendan Eich bren...@mozilla.com wrote: Yes, and we could add call/cc to make (some) compiler writers even happier. But users would shoot off all their toes with this footgun, and some implementors would be hard-pressed to support it. The point is *not * to do any one change that maximizes benefits to some parties while harming others. By the nature of their task and its complexity, compiler writers targeting JavaScript need JavaScript to have features that make it possible to generate efficient compiled code. Without the big features like call/cc there are many things that just cannot be compiled well enough...which ultimately means all the languages that compile to JavaScript are just thin sugar layers that really aren't even worth the bother. Those languages, like Coffeescript, are obscure and known by only a few people. Rails 3.1 is obscure and known by only a few people? Seriously, check your attitude. There are many languages in the world. Asserting that Python implemented via Skulpt is not worth the bother is insulting to people working on that project and using it. If you don't think it's worth the bother, feel free not to bother. Your opinion does not become an imperative to add arbitrary compiler-target wishlist items. Here's a list of languages that compile to JS: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS I'm sure it's not complete. The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. This is not a straight-up discussion. You ignore safety, never mind usability. Compiler writers want unsafe interfaces to machine-level abstractions. Should we expose them? Certainly not, even though not exposing them hurts efforts to compile (not transpile, as you note) other languages to JS. Too bad -- the first order of business is JS as a source language. Being a better target for compilers is secondary. It is among the goals, but not super-ordinate. http://wiki.ecmascript.org/doku.php?id=harmony:harmony Compiler-writers don't seem to be having such a bad time of it, and we can proceed on a more concrete requirements proposal basis than taking absolute-sounding philosophical stances. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 17, 2011, at 4:57, Peter Michaux petermich...@gmail.com wrote: The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. You sound like you really hate JavaScript and can’t imagine working with it unless some other language is compiled to it. I’ve programmed quite a bit of Perl, Python, and Scheme and found that once you get to know the proverbial “good parts” of JavaScript, it can be quite elegant. That is, I don’t miss either of these three languages, except maybe for Python’s runtime library (and Java’s tools, but that’s a different topic). With the increasing momentum behind JavaScript, IMHO the primary goal should be to improve the language for people who actually want to program in it. This is difficult enough, given all the parties that have to be pleased. Listening to feedback from compiler writers should be a secondary goal. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Tue, May 17, 2011 at 10:50 AM, Axel Rauschmayer a...@rauschma.de wrote: On May 17, 2011, at 4:57, Peter Michaux petermich...@gmail.com wrote: The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. You sound like you really hate JavaScript and can’t imagine working with it unless some other language is compiled to it. Actually the opposite is true. I write in JavaScript all day and like it a lot. I wouldn't want to compile to JavaScript with today's possibility. What I was trying to express is that I believe dream of people who want to compile to JavaScript is to write in their server-side language of choice (e.g. Perl, Python, Ruby, Scheme, Java, etc) and compile that to JavaScript. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 17, 2011, at 5:04 PM, Kyle Simpson wrote:
Regarding the - and = syntax, I just want to throw out one other concern
that I hope is taken into account, not only now, but for the future: I really
hope that we don't get to the point where we start adding functionality to
that style of function that is not available to explicit functions (we're
almost, but not, there with having = do the magical `this` binding).
You have to distinguish syntax from semantics.
There's nothing proposed for arrow functions that is more than shorter syntax
-- including |this| binding.
I know Brendan and others have declared it's shorthand only, but it can be
a slippery slope, and to rely on the if you don't like - don't use it
argument, we have to make sure that it really stays only a shorthand and
nothing more, otherwise it's tail-wagging-the-dog.
Agreed, which is why I'm still going to write up a fairy radical Ruby-block
proposal that competes in this sense: it too gives better function syntax,
plus semantics not available to arrow functions as constrained to be just
syntax.
I hope we'll be able to decide between these two approaches quickly, since I do
not want to do both. That is, either arrow functions win and shorter syntax
is enough; or we have blocks for control abstraction (which means other syntax
changes, details soon) and no arrow functions.
In other words, I hope that those who favor - aren't also hoping that
eventually - replaces `function` entirely. As stated many times thus far in
this thread, there are still those of us who favor (and maybe always will)
the explicitness of `function(){}` or `#(){}`.
There's no way to remove 'function' long syntax from JS. Just no way.
Your point about just syntax is well-taken, since translation tools will be
important in aiding Harmony migration -- not just for targeting downrev
browsers but for added static checking -- and these should be as simple (local
rewriting, e.g. transpilers not compilers) as possible.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Mon, May 9, 2011 at 6:02 PM, Brendan Eich bren...@mozilla.com wrote: Yes, and we could add call/cc to make (some) compiler writers even happier. But users would shoot off all their toes with this footgun, and some implementors would be hard-pressed to support it. The point is *not * to do any one change that maximizes benefits to some parties while harming others. By the nature of their task and its complexity, compiler writers targeting JavaScript need JavaScript to have features that make it possible to generate efficient compiled code. Without the big features like call/cc there are many things that just cannot be compiled well enough...which ultimately means all the languages that compile to JavaScript are just thin sugar layers that really aren't even worth the bother. Those languages, like Coffeescript, are obscure and known by only a few people. The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 13, 2011, at 11:25 PM, Brendan Eich wrote:
I'll update
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax to
include an ES5 grammar patch.
Done: http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax,
specifically
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
This requires splitting the sub-grammar starting at Expression (comma
expression), at AssignmentExpression (which occurs in all comma-separated list
non-comma-expression contexts, namely argument lists and initialisers),
creating a parallel production chain from Statement through AssignmentStatement.
Many languages restrict assignment to statement form. We don't need to do that
and shouldn't break extant code that nests assignment expressions, but
separating assignment statements (comma-separated lists of assignments) enables
better right-hand side syntax for arrow function expressions -- namely, they
don't have to be parenthesized.
Thus you can write
array.map((elem) - elem * elem)
let identity = (x) - x;
thrice = (x) - 3 * x;
without gratuitous parenthesization. Calling an arrow function expression
requires parentheses on the outside, of course:
alert((- paren me)());
Comments welcome, I haven't had time to formalize and test this but it looks
like it will work.
/be
Grammar Changes
Change all uses of AssignmentExpression outside of the Expression sub-grammar
to InitialExpression:
ElementList :// See 11.1.4
Elisionopt InitialExpression
ElementList , Elisionopt InitialExpression
...
PropertyAssignment : // See 11.1.5
PropertyName : InitialExpression
...
ArgumentList : // See 11.2
InitialExpression
ArgumentList , InitialExpression
...
Initialiser :// See 12.2
= InitialExpression
InitialiserNoIn :// See 12.2
= InitialExpressionNoIn
Define InitialExpression and ArrowFunctionExpression:
InitialExpression :
AssignmentExpression
ArrowFunctionExpression
ArrowFunctionExpression :
FormalParametersOpt Arrow [lookahead ∉ {{}] InitialExpression
FormalParametersOpt Arrow Block
FormalParameters :
( FormalParameterListOpt )
Arrow : one of - or =
Split assignment out of ExpressionStatement into AssignmentStatement:
Statement :
Block
VariableStatement
EmptyStatement
AssignmentStatement
ExpressionStatement
...
AssignmentStatement :
[lookahead ∉ {{, function}] AssignmentList ;
AssignmentList :
Assignment
AssignmentList , Assignment
Assignment :
LeftHandSideExpression = InitialExpression
LeftHandSideExpression AssignmentOperator InitialExpression
ExpressionStatement :
[lookahead ∉ {{, function}] ConditionalExpression ;
Finally, PrimaryExpression produces a parenthesized ArrowFunctionExpression:
PrimaryExpression :
...
( ArrowFunctionExpression )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 15.05.2011 10:33, Brendan Eich wrote:
On May 13, 2011, at 11:25 PM, Brendan Eich wrote:
I'll update
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
to include an ES5 grammar patch.
Done:
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax,
specifically
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
This requires splitting the sub-grammar starting at Expression (comma
expression), at AssignmentExpression (which occurs in all
comma-separated list non-comma-expression contexts, namely argument
lists and initialisers), creating a parallel production chain from
Statement through AssignmentStatement.
Many languages restrict assignment to statement form. We don't need to
do that and shouldn't break extant code that nests assignment
expressions, but separating assignment statements (comma-separated
lists of assignments) enables better right-hand side syntax for arrow
function expressions -- namely, they don't have to be parenthesized.
Thus you can write
array.map((elem) - elem * elem)
let identity = (x) - x;
thrice = (x) - 3 * x;
without gratuitous parenthesization. Calling an arrow function
expression requires parentheses on the outside, of course:
alert((- paren me)());
Comments welcome, I haven't had time to formalize and test this but it
looks like it will work.
Cool!
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) - a * a;
}
let p = return_pure(),
q = return_pure();
assert(p === q);
So, ES3 joined-objects are back. Though, the question is in their
[[Scope]] difference (i.e. can be they joined in the following case):
let foo = (args...) - {
return #(a) - args.map(a);
};
foo(1, 2, 3)((x) - x * x); // [1, 4, 9]
foo(5, 10)((x) - x * x); // [25, 10]
Do both have the same (reflected) [[Scope]] to be joined? At first
glance with named args, e.g. foo(a, b, c) yes, but what's with rest args?
Other things seems fine.
Dmitry.
/be
Grammar Changes
Change all uses of /AssignmentExpression/ outside of the /Expression/
sub-grammar to /InitialExpression/:
ElementList :// See 11.1.4
Elisionopt InitialExpression
ElementList , Elisionopt InitialExpression
...
PropertyAssignment : // See 11.1.5
PropertyName : InitialExpression
...
ArgumentList : // See 11.2
InitialExpression
ArgumentList , InitialExpression
...
Initialiser :// See 12.2
= InitialExpression
InitialiserNoIn :// See 12.2
= InitialExpressionNoIn
Define /InitialExpression/ and /ArrowFunctionExpression/:
InitialExpression :
AssignmentExpression
ArrowFunctionExpression
ArrowFunctionExpression :
FormalParametersOpt Arrow [lookahead ∉ {{}] InitialExpression
FormalParametersOpt Arrow Block
FormalParameters :
( FormalParameterListOpt )
Arrow : one of - or =
Split assignment out of /ExpressionStatement/ into /AssignmentStatement/:
Statement :
Block
VariableStatement
EmptyStatement
AssignmentStatement
ExpressionStatement
...
AssignmentStatement :
[lookahead ∉ {{, function}] AssignmentList ;
AssignmentList :
Assignment
AssignmentList , Assignment
Assignment :
LeftHandSideExpression = InitialExpression
LeftHandSideExpression AssignmentOperator InitialExpression
ExpressionStatement :
[lookahead ∉ {{, function}] ConditionalExpression ;
Finally, /PrimaryExpression/ produces a parenthesized
/ArrowFunctionExpression/:
PrimaryExpression :
...
( ArrowFunctionExpression )
___
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: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 8:14 AM, Dmitry A. Soshnikov wrote:
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a)
- a * a;
}
let p = return_pure
()
,
q = return_pure
()
;
assert
(p === q);
So, ES3 joined-objects are back. Though, the question is in their [[Scope]]
difference (i.e. can be they joined in the following case):
The join to nearest relevant closure words were meant to address this. Let's
see (I made a few typo and syntax fixes):
let foo = (...args) - {
return #(a) - args.map(a);
};
foo(1, 2, 3)((x) - x * x); // [1, 4, 9]
foo(5, 10)((x) - x * x); // [25, 100]
Do both have the same (reflected) [[Scope]] to be joined?
The two foo calls have different unjoinable scope chains enclosing variables
captured by the returned #(a) - args.map(a) function, specifically args. So
that hash-frozen arrow-function cannot be joined into one identity.
At first glance with named args, e.g. foo(a, b, c) yes, but what's with rest
args?
Named vs. rest doesn't matter, the question is lexical capture. The name |args|
is from the outer
(...args) - { return #(a) - args.map(a); }
function. It is used in the inner arrow function.
The location of this |args| parameter is what is actually captured in general.
This is optimizable to copying the value at that location in many cases,
including this one, but that doesn't change the fact that the location varies
with each call to foo.
So args' abstract location differs, and therefore its value may differ, each
time the inner arrow-function is evaluated. So the # freezes it but it will not
be joined with other evaluations of the same source form.
However you implement closures, something has to vary each time the inner arrow
is evaluated, to capture the correct args, [1, 2, 3] or [5, 10].
/be
Other things seems fine.
Dmitry.
/be
Grammar Changes
Change all uses of AssignmentExpression outside of the Expression
sub-grammar to InitialExpression:
ElementList :// See 11.1.4
Elisionopt InitialExpression
ElementList , Elisionopt InitialExpression
...
PropertyAssignment : // See 11.1.5
PropertyName : InitialExpression
...
ArgumentList : // See 11.2
InitialExpression
ArgumentList , InitialExpression
...
Initialiser :// See 12.2
= InitialExpression
InitialiserNoIn :// See 12.2
= InitialExpressionNoIn
Define InitialExpression and ArrowFunctionExpression:
InitialExpression :
AssignmentExpression
ArrowFunctionExpression
ArrowFunctionExpression :
FormalParametersOpt Arrow [lookahead ∉ {{}] InitialExpression
FormalParametersOpt Arrow Block
FormalParameters :
( FormalParameterListOpt )
Arrow : one of - or =
Split assignment out of ExpressionStatement into AssignmentStatement:
Statement :
Block
VariableStatement
EmptyStatement
AssignmentStatement
ExpressionStatement
...
AssignmentStatement :
[lookahead ∉ {{, function}] AssignmentList ;
AssignmentList :
Assignment
AssignmentList , Assignment
Assignment :
LeftHandSideExpression = InitialExpression
LeftHandSideExpression AssignmentOperator InitialExpression
ExpressionStatement :
[lookahead ∉ {{, function}] ConditionalExpression ;
Finally, PrimaryExpression produces a parenthesized ArrowFunctionExpression:
PrimaryExpression :
...
( ArrowFunctionExpression )
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 14, 2011, at 11:33 PM, Brendan Eich wrote:
Grammar Changes
Change all uses of AssignmentExpression outside of the Expression sub-grammar
to InitialExpression:
...
ArrowFunctionExpression :
FormalParametersOpt Arrow [lookahead ∉ {{}] InitialExpression
FormalParametersOpt Arrow Block
FormalParameters :
( FormalParameterListOpt )
Forgot to include the optional leading |this| parameter, so the above two
production-sets should be:
ArrowFunctionExpression :
ArrowFormalParametersOpt Arrow [lookahead ∉ {{}] InitialExpression
ArrowFormalParametersOpt Arrow Block
ArrowFormalParameters :
( FormalParameterListOpt )
( this InitialiserOpt )
( this InitialiserOpt , FormalParameterList )
(Opt at the end is because I can't get dokuwiki to do a subscripted opt as
ES1-5's grammars do for optional right-hand side terms -- at least not without
a dokuwiki plugin.)
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Ok, final and most delicate part of the mission here: allow (v) - {k: v} and
even - {} to return objects, not make useless block statements.
// Expression bodies needs no parentheses or braces
let identity = (x) - x;
// Fix: object initialiser need not be parenthesized, see Grammar Changes
let key_maker = (val) - {key: val};
Thanks to Doug for pushing on this idea. I believe that it is sound (still to
be formalized and tested mechanically) in a bottom-up parser.
The top-down approach by default is to parse a cover grammar until an
unambiguous decision point is reached, then depending on the decision, rewrite
the AST (e.g., to make a labeled statement in a block instead of an object
initializer).
/be
On May 15, 2011, at 10:26 AM, Brendan Eich wrote:
On May 14, 2011, at 11:33 PM, Brendan Eich wrote:
Grammar Changes
To enable unparenthesized ObjectLiteral expressions as bodies of arrow
functions, without ambiguity with Block bodies, restrict LabelledStatement as
follows:
LabelledStatement :
Identifier : LabelledStatement
Identifier : LabelUsingStatement
LabelUsingStatement :
NonEmptyBlock
IfStatement
IterationStatement
BreakStatement
SwitchStatement
TryStatement
NonEmptyBlock : // See 12.1
{ StatementList }
The resulting grammar should be unambiguously LR(1) (ignoring ASI), because {
L: expr...} can parse only as an ObjectLiteral, and { L: { if (cond)... } } or
similar LabelUsingStatement variations can parse only as a LabelledStatement.
TODO: evaluate top-down parsing difficulty___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 15.05.2011 21:09, Brendan Eich wrote:
On May 15, 2011, at 8:14 AM, Dmitry A. Soshnikov wrote:
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a)
- a * a;
}
let p = return_pure
()
,
q = return_pure
()
;
assert
(p === q);
So, ES3 joined-objects are back. Though, the question is in their [[Scope]]
difference (i.e. can be they joined in the following case):
The join to nearest relevant closure words were meant to address this. Let's
see (I made a few typo and syntax fixes):
let foo = (...args) - {
return #(a) - args.map(a);
};
foo(1, 2, 3)((x) - x * x); // [1, 4, 9]
foo(5, 10)((x) - x * x); // [25, 100]
Do both have the same (reflected) [[Scope]] to be joined?
The two foo calls have different unjoinable scope chains enclosing variables
captured by the returned #(a) - args.map(a) function, specifically args. So
that hash-frozen arrow-function cannot be joined into one identity.
At first glance with named args, e.g. foo(a, b, c) yes, but what's with rest
args?
Named vs. rest doesn't matter, the question is lexical capture. The name |args|
is from the outer
(...args) - { return #(a) - args.map(a); }
function. It is used in the inner arrow function.
The location of this |args| parameter is what is actually captured in general.
Oh, my misunderstanding then. Then I just incorrectly treated yours
assert(p === q);
I though here you try to show that the engine will handle the case with
optimization and reuse (i.e. to join) the function object. However, it
still not possible because of different scope chain, that exactly why I
was asking.
So you mean just lexical addressing of free variable? I.e. without
dynamic scope chain lookup (that what Dave Herman confused recently with
dynamic scope concept IIRC). However it's interesting -- if ES6 will
have lexical addressing anyway (that is there will be no dynamic
bindings -- no `eval`, no `with`, etc, -- just compile-time bindings),
this means that this optimization will be done in any way, -- without
needing of this #function in this case. Or am I mistaken again?
Thanks for explanations btw.
Dmitry.
This is optimizable to copying the value at that location in many cases,
including this one, but that doesn't change the fact that the location varies
with each call to foo.
So args' abstract location differs, and therefore its value may differ, each
time the inner arrow-function is evaluated. So the # freezes it but it will not
be joined with other evaluations of the same source form.
However you implement closures, something has to vary each time the inner arrow
is evaluated, to capture the correct args, [1, 2, 3] or [5, 10].
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Oh, and just a small note -- perhaps there's a sense to put a comment
near each line to what result the expression evaluates in your examples,
e.g.
asset(p === q); // true (or false?)
etc.
Dmitry.
On 15.05.2011 22:55, Dmitry A. Soshnikov wrote:
On 15.05.2011 21:09, Brendan Eich wrote:
On May 15, 2011, at 8:14 AM, Dmitry A. Soshnikov wrote:
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a)
- a * a;
}
let p = return_pure
()
,
q = return_pure
()
;
assert
(p === q);
So, ES3 joined-objects are back. Though, the question is in their
[[Scope]] difference (i.e. can be they joined in the following case):
The join to nearest relevant closure words were meant to address
this. Let's see (I made a few typo and syntax fixes):
let foo = (...args) - {
return #(a) - args.map(a);
};
foo(1, 2, 3)((x) - x * x); // [1, 4, 9]
foo(5, 10)((x) - x * x); // [25, 100]
Do both have the same (reflected) [[Scope]] to be joined?
The two foo calls have different unjoinable scope chains enclosing
variables captured by the returned #(a) - args.map(a) function,
specifically args. So that hash-frozen arrow-function cannot be
joined into one identity.
At first glance with named args, e.g. foo(a, b, c) yes, but what's
with rest args?
Named vs. rest doesn't matter, the question is lexical capture. The
name |args| is from the outer
(...args) - { return #(a) - args.map(a); }
function. It is used in the inner arrow function.
The location of this |args| parameter is what is actually captured in
general.
Oh, my misunderstanding then. Then I just incorrectly treated yours
assert(p === q);
I though here you try to show that the engine will handle the case
with optimization and reuse (i.e. to join) the function object.
However, it still not possible because of different scope chain, that
exactly why I was asking.
So you mean just lexical addressing of free variable? I.e. without
dynamic scope chain lookup (that what Dave Herman confused recently
with dynamic scope concept IIRC). However it's interesting -- if ES6
will have lexical addressing anyway (that is there will be no dynamic
bindings -- no `eval`, no `with`, etc, -- just compile-time bindings),
this means that this optimization will be done in any way, -- without
needing of this #function in this case. Or am I mistaken again?
Thanks for explanations btw.
Dmitry.
This is optimizable to copying the value at that location in many
cases, including this one, but that doesn't change the fact that the
location varies with each call to foo.
So args' abstract location differs, and therefore its value may
differ, each time the inner arrow-function is evaluated. So the #
freezes it but it will not be joined with other evaluations of the
same source form.
However you implement closures, something has to vary each time the
inner arrow is evaluated, to capture the correct args, [1, 2, 3] or
[5, 10].
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 11:55 AM, Dmitry A. Soshnikov wrote:
Oh, my misunderstanding then. Then I just incorrectly treated yours
assert(p === q);
This was from
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) - a * a;
}
let p = return_pure(),
q = return_pure();
assert(p === q);
and the assertion means what it seems: p is identical to q.
I though here you try to show that the engine will handle the case with
optimization and reuse (i.e. to join) the function object.
I'm not talking about optimization -- this is a case where joining works, since
the function is pure. It closes over no outer variables' locations.
However, it still not possible because of different scope chain, that exactly
why I was asking.
No, that's not what the strawman says, and not what I said last time. The issue
is not different scope chains, it is whether there are captured closure
variables whose abstract locations are not invariant with respect to the source
function expression in question.
Each evaluation of a given function expression gives a fresh object in JS
today. WIth joining as Mark proposed at
http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining
and with opt-in syntax (the # prefix) as I'm proposing, this fresh function
object for each evaluation of a function expression rule would no lot apply.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 11:56 AM, Dmitry A. Soshnikov wrote: Oh, and just a small note -- perhaps there's a sense to put a comment near each line to what result the expression evaluates in your examples, e.g. asset(p === q); // true (or false?) That is confusing and pointless. I meant what I wrote. The assertions are intended to claim that their argument conditions are truthy. See last reply for more on joining. It occurs to me you thought scope chain varying in the context of a pure hash-rocket such as #-42 means that function cannot be joined, but since it is pure, it need not entrain its scope chain as an internal [[Scope]] property. More, since # freezes, there's no need for it to be duplicated, since there is no mutation side channel. So http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax proposes freezing and joining, only if the user specifies via the # prefix. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Could I trouble you to confirm or clarify the semantics of the
following constructs*:
let f = - - 3; // well-formed?
let x = f()(); // x is equal to 3 right?
let global = this;
let o = {};
o.fat = = this;
o.thin = - this;
assert( o.fat() === global); // true?
assert( o.thin() === o); // true?
o.thin_then_fat = - = this;
o.fat_then_thin = = - this;
assert(o.thin_then_fat()() === o); // true?
assert(o.fat_then_thin()() === global); // true?
Thanks!
*(based on the arrow syntax proposal
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 16.05.2011 0:37, Brendan Eich wrote:
On May 15, 2011, at 11:55 AM, Dmitry A. Soshnikov wrote:
Oh, my misunderstanding then. Then I just incorrectly treated yours
assert(p === q);
This was from
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) - a * a;
}
let p = return_pure(),
q = return_pure();
assert(p === q);
and the assertion means what it seems: p is identical to q.
I though here you try to show that the engine will handle the case with
optimization and reuse (i.e. to join) the function object.
I'm not talking about optimization -- this is a case where joining works, since
the function is pure. It closes over no outer variables' locations.
However, it still not possible because of different scope chain, that exactly
why I was asking.
No, that's not what the strawman says, and not what I said last time. The issue
is not different scope chains, it is whether there are captured closure
variables whose abstract locations are not invariant with respect to the source
function expression in question.
Each evaluation of a given function expression gives a fresh object in JS
today. WIth joining as Mark proposed at
http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining
Got it. Though it still seems to me as just an implementation
optimization without need to specify explicitly that a function is
closed (without free variables) and thus can be optimized, i.e. created
once and stored as some internal property.
Dmitry.
and with opt-in syntax (the # prefix) as I'm proposing, this fresh function object
for each evaluation of a function expression rule would no lot apply.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 16.05.2011 0:40, Brendan Eich wrote: On May 15, 2011, at 11:56 AM, Dmitry A. Soshnikov wrote: Oh, and just a small note -- perhaps there's a sense to put a comment near each line to what result the expression evaluates in your examples, e.g. asset(p === q); // true (or false?) That is confusing and pointless. I meant what I wrote. The assertions are intended to claim that their argument conditions are truthy. Yeah, OTOH, yes. See last reply for more on joining. It occurs to me you thought scope chain varying in the context of a pure hash-rocket such as #-42 means that function cannot be joined, but since it is pure, it need not entrain its scope chain as an internal [[Scope]] property. More, since # freezes, there's no need for it to be duplicated, since there is no mutation side channel. So http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax proposes freezing and joining, only if the user specifies via the # prefix. Yep, I got it, thanks, though, as mentioned seems it can be managed then at engine level without explicit specifying by the user, no? Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 1:49 PM, Faisal Vali wrote:
Could I trouble you to confirm or clarify the semantics of the
following constructs*:
let f = - - 3; // well-formed?
let x = f()(); // x is equal to 3 right?
Sure, unambiguous. Same as in CoffeeScript:
coffee f = - - 3;
[Function]
coffee f()()
3
let global = this;
let o = {};
o.fat = = this;
o.thin = - this;
assert( o.fat() === global); // true?
Sure, or (no need for global) assert(o.fat() === this).
assert( o.thin() === o); // true?
Yes.
o.thin_then_fat = - = this;
This example is given in
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax -- look
for method:.
o.fat_then_thin = = - this;
assert(o.thin_then_fat()() === o); // true?
Right, as in the strawman.
assert(o.fat_then_thin()() === global); // true?
No. Since the proposed syntax is just syntax, you can expand it and evaluate:
o.fat_then_thin = (function () { return function () { return this; };
}).bind(this);
So the first call,
o.fat_then_thin() indeed returns function () { return this; } from a function
in which |this| was bound to the outermost |this|, aliased via |global|.
But that (function () { return this; }) result is then immediately invoked and
the |this| it receives, per ES5 strict and Harmony, is undefined.
That's why I focused on the thin-then-fat example in the strawman. To show
fat-then-thin with |this| dynamically bound on the second call (to the inner
thin arrow function), you might need to store the return value of the first
(outer, o.fat_then_thin()) call as a property value, and call it that way. Or
via .call/.apply. Or as you did here, but it is less clear to have an undefined
|this| pop out at the end.
Again, http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax is
just syntax. Therefore since - does not bind |this|, that parameter is bound
dynamically depending on the callee sub-expression of the call expression. Same
as for long function syntax with ES5 strict semantics.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 1:52 PM, Dmitry A. Soshnikov wrote: Each evaluation of a given function expression gives a fresh object in JS today. WIth joining as Mark proposed at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining Got it. Though it still seems to me as just an implementation optimization without need to specify explicitly that a function is closed (without free variables) and thus can be optimized, i.e. created once and stored as some internal property. We would want to specify the optimization in order to make === and egal constant time (i.e., based on pointer not value comparison). This matters for WeakMaps keyed by joined functions. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 15, 2011, at 1:54 PM, Dmitry A. Soshnikov wrote: See last reply for more on joining. It occurs to me you thought scope chain varying in the context of a pure hash-rocket such as #-42 means that function cannot be joined, but since it is pure, it need not entrain its scope chain as an internal [[Scope]] property. More, since # freezes, there's no need for it to be duplicated, since there is no mutation side channel. So http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax proposes freezing and joining, only if the user specifies via the # prefix. Yep, I got it, thanks, though, as mentioned seems it can be managed then at engine level without explicit specifying by the user, no? Do you mean that users shouldn't have to write # prefixes to get joining? That is hard. SpiderMonkey implements joining for lambdas that do not close over outer lexical variables provided those lambdas are used as the initializer of a property in an object literal, or as the full RHS of assignment to a property of an Object instance. This optimization wins but it requires read and write barriers (which we already have for getters and setters in general). It's complex. The # prefix means freeze too, and that is required for joining. ES3 left it to implementations to join but that was a mistake that (if implementations had done so; none did after early SpiderMonkey bugs were fixed) creates a mutation side channel. See also the ES3 global regexp singleton per lexical regular expression bug. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 13, 2011, at 2:52 PM, Brendan Eich wrote: One might be tempted to make an unparenthesized (on the outside) function expression with an unparenthesized expression body be a low-precedence expression (say, AssignmentExpression), but then it can't be used as the callee part of a CallExpression without being parenthesized. Such a low-precedence function expression would have to be parenthesized with every operator save comma. CoffeeScript does something like this. It separates Invocation from Operation (both are Expressions, and an Operation combines Expressions using operators, sometimes with a narrower non-terminal than Expression on the left of a dyadic operator). Invocations can be chained but the basis case is a Value as callee nonterminal, and a Value must be parenthesized if it contains Code. The Code nonterminal produces a CoffeeScript function expression, with optional parenthesized parameter list, arrow (- or =), and a block body. The ECMA-262 grammar could be extended like this. It would mean - and = as proposed in http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax would not be sugar for existing function expression (with .bind or some tamper-proof internal equivalent in the case of =). But that seems better than requiring parentheses. This grammar interlude reminds me of the grammar dependency graphs at http://blog.nicksieger.com/articles/2006/10/27/visualization-of-rubys-grammar -- the Java and JavaScript grammars show the C-family expression sub-grammar-dependency tower (duplicated in JS's case due to the NoIn productions), with all those precedence levels we know and love. Ruby has a flatter graph with a popular primary non-terminal in the middle. http://www.flickr.com/photos/nicksieger/280661836/sizes/o/in/photostream/ (warning: BIG) I'll update http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax to include an ES5 grammar patch. The Ruby-ish block (Allen's lambda syntax proposal) approach has to be considered, still, since it has braces around the outside and avoids all this grammar hacking. The downside is an empty block has to be distinguished from an empty object initialiser (from an empty block statement :-P). That may not be a big downside as Allen noted, although I don't think undefined or null can stand in for empty block. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 7, 2011, at 2:39 PM, Claus Reinke wrote:
Consider this: w = (x)-y || z
That code is not obvious at all. Which of these would it be?
1: w = function (x) { return y } || z
2: w = function (x) { return y || z }
It seems to me that there must be some sort of delineation around the
function start and end.
Either that, or around the function body (expression or statement).
But such delineation does not have to lead to required syntax
in the function construct. Such required delineations were not
part of lambda-calculus originally **, they arose out of implementation
limitations that can be overcome.
We're talking JS syntax here, not anything like the original Lambda calculus or
s-expressions.
I know that takes some getting used to (been there myself*), but there is an
established standard, both in publications on
programming language theory, and in some real languages:
function bodies extend as far as possible **
So your examples would be
1: w = (function (x) return y) || z
2: w = (function (x) return y || z)
This does not work, because the ECMA-262 grammar simplifies to something like
this toy bison grammar:
%token FUNCTION
%token NUMBER
%%
Expr: Expr '+' Term
| Term
;
Term: Term '*' Fact
| Fact '(' ')'
| Fact
;
Fact: FUNCTION '(' ')' '{' Expr '}'
| '(' Expr ')'
| NUMBER
;
Notice this grammar parses function expressions with empty parameter lists, and
function calls with empty argument lists. No statements, only expressions, and
only numbers with addition and multiplication (and numbers are syntactically
callable, as in JS), but the essential grammatical structure remains.
Now let's try to extend it to allow an unbraced body for the analogue of ES5's
PrimaryExpression, here called Fact:
%token FUNCTION
%token NUMBER
%%
Expr: Expr '+' Term
| Term
;
Term: Term '*' Fact
| Fact '(' ')'
| Fact
;
Fact: FUNCTION '(' ')' Fact
| '(' FUNCTION '(' ')' Expr ')'
| '(' Expr ')'
| NUMBER
;
That is, we allow an unparenthesized high-precedence expression (a Fact) as the
body of a function expression, or else require parentheses around an entire
function expression whose body is an unparenthesized low-precedence expression
(an Expr).
The results in reduce/reduce conflicts:
state 23
4 Term: Fact . '(' ')'
5 | Fact .
6 Fact: FUNCTION '(' ')' Fact .
'(' shift, and go to state 13
'+' reduce using rule 5 (Term)
'+' [reduce using rule 6 (Fact)]
'*' reduce using rule 5 (Term)
'*' [reduce using rule 6 (Fact)]
'(' [reduce using rule 6 (Fact)]
')' reduce using rule 5 (Term)
')' [reduce using rule 6 (Fact)]
$default reduce using rule 5 (Term)
In other words, we've created a hopeless ambiguity between an unparenthesized
function expression with a high-precedence body expression and a
parenthesized-on-the-outside function expression with a low-precedence body.
There's a shift/reduce conflict too, but that is not the concern here. The
problem is that no amount of lookahead can decide by which production to
reduce. We must give up one of the two function expression forms.
One might be tempted to make an unparenthesized (on the outside) function
expression with an unparenthesized expression body be a low-precedence
expression (say, AssignmentExpression), but then it can't be used as the callee
part of a CallExpression without being parenthesized. Such a low-precedence
function expression would have to be parenthesized with every operator save
comma.
In practice, function expressions aren't operated on except by being on the
right-hand side of assignment, by calling them to make a CallExpression, and by
concatenating their string conversions, but requiring parens for all
sub-expression uses of function expressions is a big break from ECMA-262's
grammar since ES3, which introduced function expressions as PrimaryExpressions
(highest precedence).
Here is a more complete toy ES sub-grammar, still not too big:
%token FUNCTION
%token IDENT
%token NUMBER
%token PLUSPLUS
%%
Expr: Expr '+' Term
| Term
;
Term: Term '*' Fact
| Fact
;
Fact: PLUSPLUS Fact
| Post
;
Post: Call PLUSPLUS
| Call
;
Call: Call '(' ')'
| Prim
;
Prim: FUNCTION '(' ')' '{' Expr '}'
| '(' Expr ')'
| IDENT
| NUMBER
;
If we make the mistake ES4 made (implemented in SpiderMonkey still) of adding a
Prim(aryExpression) right-hand side:
Prim: FUNCTION '(' ')' Expr
to allow unbraced expression bodies for function expressions, the
low-precedence Expr at the end of high-precedence Prim makes a nasty loop in
the grammar. Waldemar pointed this out a while ago
(http://www.mail-archive.com/es-discuss@mozilla.org/msg01008.html). His
counter-example used a let expression, but there's a function expression
equivalent:
function () a ? f : x++();
Per the full ES grammar, and
Re: arrow syntax unnecessary and the idea that function is too long
On May 11, 2011, at 12:55 AM, Erik Corry wrote:
2011/5/10 Oliver Hunt oli...@apple.com:
As much as I'm opposed to the idea of keyword shortening for the sake of
keyword shortening, the more i think about it, the less i like the arrow
syntax.
I think I'd simply prefer a prefix character to the infix arrow operator,
mostly from a readability stand point but i have a few other issues i'll go
into later. When I read the examples in the wiki I simply find it
unpleasant and difficult, I can't put my finger on the specific reason
either alas :(
I think I'd prefer the #{ expr } or #(args...){ expr } syntaxes simply to
ease linear reading of code. That said they seem to introduce ambiguity
with the Records strawman, but on the other hand i'm not too fond of records
or even really the tuple strawmen so maybe this isn't necessarily problem.
That said this is kind of bikeshed-y (as B said in twitter)
Honestly these are the big issues I see in JS.current that I'd like to see
fixed in JS.next:
* Array functions (and by proxy list comprehensions) all return Arrays. I
think fixing this is necessary, esp. in the context of iterators existing.
* for in enumeration with iterators is an icky problem that needs to be
resolved.
* Generalised object subtyping
* Probably Mark's simple map and set APIs -- these can be implemented in
JS, but I suspect much more efficiently by the host vm. I thought about
just doing hashCode() (or whatever) but i'm not sure how v8 would do the
hashcodes without obviously increasing memory use. I presume it's a solved
problem (as Java and .NET etc can do it) but a quick Bing (i shall make this
a verb!!) for details didn't seem to show much useful info.
We already have getters and setters in the API for an identity hash
code. It adds an invisible property to the object (not value). This
can cause the object to expand and change 'hidden class' in much the
same way as would happen if someone just did o.__hashCode__ =
Math.random(). If the hash code is not visible to the JS code then
maps could be done in other ways than with a hash code, eg. rehashing
when objects move.
I was actually thinking of object pointers from the PoV of guaranteeing
uniqueness of hashcode, which of course isn't actually a requirement (facepalm)
I can see you are thinking of using the address of the object as a
hash code. This can work, and early Java VMs did it, but there is a
nasty gotcha: You can't leak this hash code to JS code in any way,
because then you just defeated ASLR and leaked very valuable
information to any attacker hoping to use buffer overflows to
overwrite adjacent objects. You could xor all hash codes with a
nonce, but it wouldn't be hard for the attacker to find the low bits
of that nonce. I'm not sure whether you could recover the high bits
somehow.
I was aware of those issues, essential plan had been one-way unique hash from
address which as above is not necessary as you just need to have a fixed
hashcode for the object :)
Also you put an extra barrier in the way of a moving GC if you do it that way.
I know, which is why i was wondering how V8 did it, given that it obviously
required the object pointer (see above re: facepalm)
--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
See also
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes and especially
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes#a_note_regarding_security
which date from ES4, and
http://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes
which needs updating.
/be
On May 11, 2011, at 1:06 AM, Oliver Hunt wrote:
On May 11, 2011, at 12:55 AM, Erik Corry wrote:
2011/5/10 Oliver Hunt oli...@apple.com:
As much as I'm opposed to the idea of keyword shortening for the sake of
keyword shortening, the more i think about it, the less i like the arrow
syntax.
I think I'd simply prefer a prefix character to the infix arrow operator,
mostly from a readability stand point but i have a few other issues i'll go
into later. When I read the examples in the wiki I simply find it
unpleasant and difficult, I can't put my finger on the specific reason
either alas :(
I think I'd prefer the #{ expr } or #(args...){ expr } syntaxes simply to
ease linear reading of code. That said they seem to introduce ambiguity
with the Records strawman, but on the other hand i'm not too fond of
records or even really the tuple strawmen so maybe this isn't necessarily
problem.
That said this is kind of bikeshed-y (as B said in twitter)
Honestly these are the big issues I see in JS.current that I'd like to see
fixed in JS.next:
* Array functions (and by proxy list comprehensions) all return Arrays. I
think fixing this is necessary, esp. in the context of iterators existing.
* for in enumeration with iterators is an icky problem that needs to be
resolved.
* Generalised object subtyping
* Probably Mark's simple map and set APIs -- these can be implemented in
JS, but I suspect much more efficiently by the host vm. I thought about
just doing hashCode() (or whatever) but i'm not sure how v8 would do the
hashcodes without obviously increasing memory use. I presume it's a solved
problem (as Java and .NET etc can do it) but a quick Bing (i shall make
this a verb!!) for details didn't seem to show much useful info.
We already have getters and setters in the API for an identity hash
code. It adds an invisible property to the object (not value). This
can cause the object to expand and change 'hidden class' in much the
same way as would happen if someone just did o.__hashCode__ =
Math.random(). If the hash code is not visible to the JS code then
maps could be done in other ways than with a hash code, eg. rehashing
when objects move.
I was actually thinking of object pointers from the PoV of guaranteeing
uniqueness of hashcode, which of course isn't actually a requirement
(facepalm)
I can see you are thinking of using the address of the object as a
hash code. This can work, and early Java VMs did it, but there is a
nasty gotcha: You can't leak this hash code to JS code in any way,
because then you just defeated ASLR and leaked very valuable
information to any attacker hoping to use buffer overflows to
overwrite adjacent objects. You could xor all hash codes with a
nonce, but it wouldn't be hard for the attacker to find the low bits
of that nonce. I'm not sure whether you could recover the high bits
somehow.
I was aware of those issues, essential plan had been one-way unique hash from
address which as above is not necessary as you just need to have a fixed
hashcode for the object :)
Also you put an extra barrier in the way of a moving GC if you do it that
way.
I know, which is why i was wondering how V8 did it, given that it obviously
required the object pointer (see above re: facepalm)
--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
As much as I'm opposed to the idea of keyword shortening for the sake of
keyword shortening, the more i think about it, the less i like the arrow syntax.
I think I'd simply prefer a prefix character to the infix arrow operator,
mostly from a readability stand point but i have a few other issues i'll go
into later. When I read the examples in the wiki I simply find it unpleasant
and difficult, I can't put my finger on the specific reason either alas :(
I think I'd prefer the #{ expr } or #(args...){ expr } syntaxes simply to ease
linear reading of code. That said they seem to introduce ambiguity with the
Records strawman, but on the other hand i'm not too fond of records or even
really the tuple strawmen so maybe this isn't necessarily problem.
That said this is kind of bikeshed-y (as B said in twitter)
Honestly these are the big issues I see in JS.current that I'd like to see
fixed in JS.next:
* Array functions (and by proxy list comprehensions) all return Arrays. I
think fixing this is necessary, esp. in the context of iterators existing.
* for in enumeration with iterators is an icky problem that needs to be
resolved.
* Generalised object subtyping
* Probably Mark's simple map and set APIs -- these can be implemented in JS,
but I suspect much more efficiently by the host vm. I thought about just doing
hashCode() (or whatever) but i'm not sure how v8 would do the hashcodes without
obviously increasing memory use. I presume it's a solved problem (as Java and
.NET etc can do it) but a quick Bing (i shall make this a verb!!) for details
didn't seem to show much useful info.
--Oliver
On May 9, 2011, at 6:04 PM, Brendan Eich wrote:
On May 7, 2011, at 1:37 AM, Jorge wrote:
But if I wanted a shorter syntax, I would no doubt choose ruby blocks'
syntax, it's even shorter yet and it's familiar already to millions of
programmers.
Ruby and Smalltalk before it had blocks for most of their usable lives. JS
does not. Having break, continue, return, this, arguments, and perhaps other
features of JS change meaning in a block to refer to aspects of the outer
function's activation (if still active) is a big change. It adds new runtime
error cases. It's certainly not simpler than shorter function syntax.
Not all JS hackers are Rubyists.
/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: arrow syntax unnecessary and the idea that function is too long
On 5/10/11, Oliver Hunt oli...@apple.com wrote:
[...]
I think I'd prefer the #{ expr } or #(args...){ expr } syntaxes simply to\
What good is Arguments?
[...]
* Generalised object subtyping
* Probably Mark's simple map and set APIs -- these can be implemented in\
If it's wish list time, then I'll say triple quotes:
div.innerHTML =
span id=foo class='bar'#str/span
;
(if not, then I apologize fro being off topic).
--
Garrett
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
To Oliver's point: I think this would qualify as bikeshedding if this didn't
really matter. It is a tiny detail, but an important one, so it makes sense
that we've spent so long discussing it.
I acknowledge the arrow notation's advantages over #:
(a) we've got precious few ASCII characters left and the octothorp has been
claimed by several strawmen;
(b) the proposed octothorp syntax doesn't solve the -/= thing (having a
concise syntax for binding functions to current scope);
(c) prior art of CoffeeScript.
I'm not completely sold on it, though, for a couple of reasons:
(a) the cost of typing an arrow on a western keyboard is much higher than the
cost of an octothorp;
(b) the -/= distinction is, I think, too subtle. Rebinding dramatically
changes the meaning of the function, so I'd prefer if the notation guaranteed
that a user couldn't gloss over that by mistaking - for = or vice/versa.
To rephrase that second point: I think it's a good idea to have a shorthand
syntax for `.bind(this)`, but it has to make itself more obvious than the arrow
notation proposes. And there's nothing precluding a similar syntax for the
octothorp (e.g., `#(x){ this.foo }` vs. `##(x){ this.foo }` — retaining
Brendan's point that the rebinding syntax should be fatter).
(Also, for the purposes of this argument, I'm fine with using another of our
free ASCII characters in place of the octothorp.)
Cheers,
Andrew
On May 10, 2011, at 5:42 PM, Breton Slivka wrote:
I have to say that I was a bit indifferent about the different
syntaxes on offer until I had a good look at the strawman, and found
that there were differences between - = and #(x)-(x*x); with
regards to |this| binding. I have to admit that at the moment, exactly
what those subtleties are, is a little over my head at the moment.
But given I have to explain |this| again
http://stackoverflow.com/questions/1085674/where-is-my-this-using-objects-method-as-a-callback-function/1085715#1085715
and again
http://stackoverflow.com/questions/5639451/why-this-is-not-this/5692094#5692094
and again...
I appreciate efforts to address the |this| problem. I think though,
that in terms of familiarity, bind already effectively solves that
specific issue. The # operator seems too much like ambient magic to
me.
Broadly, I like how the arrow syntax resembles mathematical notation
for functional dependency, much like the original function syntax
resembles mathematical notation for function. Given some time, I
don't think it would be hard to get used to. But it might scare some
programmers easily spooked by weird syntax. We're the experts, the
language designers (you), and the advanced users (me and others), who
are drawn to and appreciate javascript due to its resemblance to
scheme and haskell etc. etc. so the arrow syntax appeals to us on that
level. But one of the strengths of Javascript has been as a
syntactical trojan horse- Getting these nice qualities under the noses
of people who would otherwise find that stuff unpalatable. For this
reason, as much as I like arrow syntax, and attempts to address |this|
scoping, I have to lean towards #(x){x*x}, and us syntactical snobs
can still have coffeescript.
I still wish there was a way to make |this| less confusing though. I'm
sure you do too.
-Breton
___
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: arrow syntax unnecessary and the idea that function is too long
On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:
On Tue, May 10, 2011 at 16:22, Oliver Hunt oli...@apple.com wrote:
\ is a much more common lambda symbol in many languages, and i'm not sure
what the ambiguity would be in \{...} or \(...){...}.
\(a,b,c) { a + b * c }
That's cute.
Oliver still has a crush on Haskell.
I've mooted \ along with ƒ, etc. for a while. \ is bad for readability because
it's visually light, but worse, if we want named function expression shorthand,
then \u10A0(){} is a valid Unicode-identifier-char-named function expression.
Last time we talked about \ in TC39 for shorter function syntax it died hard,
IIRC.
I'm also really not happy with the concept of minor variances in syntax
having such dramatic impact the language semantics. All the fiddling with
|this| dramatically increases the complexity of the language, it doesn't
simplify it.
I completely agree. It think any short-form function syntax should
have the exact same semantics as the existing long-form. We've got
.bind(obj). That's enough.
No, there are more efficient ways to implement something with dedicated syntax,
such as CoffeeScript's =, and it comes up enough that '.bind(this)', ignoring
optimization difficulty, is too much.
The long-standing way to code lexical this is 'var self = this; ... function
(...) {... self ... }'. That won't go away, but it is also crying for a
shorthand.
What makes 'var self = this;' particularly bad is when the inner function is
named, and all its calls are via that unqualified name.
In such a scenario, ES5 strict's rule of binding |this| to undefined just
wastes the |this| parameter, and requires 'var self = this' or '.bind(this)' as
heavyweight workarounds.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Do I understand you that the idea here is 'function' without the
'function' keyword? I think this has a pretty bad
backwards-incompatibility with ASI:
x = (x)
{ return x }
Which way should this parse?
My reading of Rick's gist was:
(x = (x)
{return x})
The outer ( ) removes the ASI ambiguity. FWIW, I'm not terribly excited by
this syntax, but I like it better than -.
One thing that troubles me about the goal/movement to have a shorter
function syntax... It seems like all the examples we exchange for it are,
on principle, single-line functions. From a readability standpoint, I think
it's a little deceptive to judge a syntax like that, without considering how
it will look for a longer, non-trivial function. How easy will it be to scan
for a function's start/end if the biggest visual signal for a function start
(aka, function) is gone and is replaced by that rather non-descript -
which, as was said earlier in a thread, looks a lot like existing operators.
Since in the real world, functions are usually a lot more than a single
return statement or a single assignment, I think we should at least keep in
mind the readability (or lack thereof) of how these proposals look when
there's 10, 20, 100 lines in a function... By the same token, how easy is
the readability when there's 2-4 levels of nested functions (the module
pattern, etc)?
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sunday, 2011-05-08 at 20:48 , Peter Michaux wrote:
On Sun, May 8, 2011 at 11:34 AM, Irakli Gozalishvili rfo...@gmail.com wrote:
I'd like to point out that coffeescript has a huge success and in the end
it's just syntax sugared js.
Can someone give evidence that Coffeescript is actually a success? Has
anyone crawled the web to determine the rate of Coffeescript adoption?
(Assuming there is some way to identify Coffeescript's compiled code.)
Will adoption plateau at a small percentage of total browser scripts?
Coffeescript is one of the most watched projects on github. Which I'd say is
pretty big for such a young project.
https://github.com/popular/watched
People cannot just reiterate this idea that Coffeescript is popular
and use that as support for arrows without evidence that Coffeescript
is actually popular.
Let's ignore popularity level for the moment, no other proposal has analog of
`=` which is a solution for a real problem:
var self = this;
function callback() {
self
}
Peter
___
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: arrow syntax unnecessary and the idea that function is too long
Let's ignore popularity level for the moment, no other proposal has analog
of `=` which is a solution for a real problem:
var self = this;
function callback() {
self
}
Maybe I missed something, but didn't Brendan's #-function proposal specify
lexical `this` binding, so that:
function foo() {
this.bar = baz;
return #(x){ this.bar = x; };
}
Isn't that the spirit of what = would give us?
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
(...)
Let's ignore popularity level for the moment, no other proposal has analog of
`=` which is a solution for a real problem:
var self = this;
function callback() {
self
}
Sorry, alternatives were evocated. If you had read my last mail (I know it was
a pretty long one so I don’t blame you), you could have noticed that I proposed
to use the @-syntax to perform just that. The idea would be that all lambdas
would have a “bound” this (which would be the biggest distinctive between them
and functions).
The syntax would be the following :
“@” + ( “(“ + argument-list + “)” )? + ( expression | block )
And it would allow to solve the “this” problem easily :
element.onclick = @this.removeFromParent();
setTimeout((@alert(this)), 10);
alongside with the other common lambda usage :
firstChilds = elements.map(@a.firstChild);
array.reduce(@(a,b) { return (a-b)*(a+b); });
In case you need to pass a function that has not a bound this, you should
continue to use the “function” keyword as usual :
var anObjectHasOwnValueOf = Function.prototype.bind.call(function() {
return this.hasOwnProperty(“valueOf”);
}, anObject);___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Monday, 2011-05-09 at 11:02 , Kyle Simpson wrote:
Let's ignore popularity level for the moment, no other proposal has analog
of `=` which is a solution for a real problem:
var self = this;
function callback() {
self
}
Maybe I missed something, but didn't Brendan's #-function proposal specify
lexical `this` binding, so that:
function foo() {
this.bar = baz;
return #(x){ this.bar = x; };
}
Isn't that the spirit of what = would give us?
Yes and this case makes following example extremely confusing:
MyObject.prototype.bar = #(x) { this.bar = x }
Is this instance of MyObject ? So we need to use `#` in some places, but in
other cases we need to stick to long form `function`. I think `-` and `=` is
way more intuitive and simple.
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Mon, May 9, 2011 at 10:40, Kyle Simpson get...@gmail.com wrote:
[snip]
One thing that troubles me about the goal/movement to have a shorter
function syntax... It seems like all the examples we exchange for it are,
on principle, single-line functions. From a readability standpoint, I think
it's a little deceptive to judge a syntax like that, without considering how
it will look for a longer, non-trivial function. How easy will it be to scan
for a function's start/end if the biggest visual signal for a function start
(aka, function) is gone and is replaced by that rather non-descript -
which, as was said earlier in a thread, looks a lot like existing operators.
Since in the real world, functions are usually a lot more than a single
return statement or a single assignment, I think we should at least keep in
mind the readability (or lack thereof) of how these proposals look when
there's 10, 20, 100 lines in a function... By the same token, how easy is
the readability when there's 2-4 levels of nested functions (the module
pattern, etc)?
Since several people have asked about and for feedback from the
greater developer community and since I don't think there's a way to
resolve these questions quantitatively, here's my two cents:
The main problem I'm having with declaring lambdas inline is the sheer
verbosity of it. That is, I don't care about _writing_ the code so
much as _reading_ it and stumbling upon it each and every time. You
(Kyle) say that you fear for your code's readability when a shorter
syntax is used for very long functions. I have exactly the opposite
problem: Because of the verbosity required to express even the
(otherwise) most concise statements, I declare my lambdas and then use
their name to increase readability most of the time. While I agree
that there are lots of cases where it's desirable to immediately see
the function start, there's also lots of cases where I'd want the
function itself to be nearly invisible so as to be able to focus on
the contained functionality as much as possible.
Thus, I'd much rather read
var onlyOdds = myArray.map(#(item) {item % 2});
or
var onlyOdds = myArray.map((item) - (item % 2));
than
var onlyOdds = myArray.map(function(item) {return item % 2});
(I'd love
var onlyOdds = myArray.map(item % 0);
but since that's not going to work, I'm willing to settle for the
next-best thing)
To be honest, I don't really care about which exact syntax gets
chosen. I guess if I could freely choose, I'd go for #, but I
understand the desire to save that symbol for other usages. Also, -
communicates intent very nicely in many cases, I think.
--Kyle
cheers,
till
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Dave, Kyle, Andrew et al
Thanks for your feedback, very much appreciated. To clarify, my gist was in
no way meant to be an official proposal of any sort, mostly for my own
personal, academic benefit :)
In that spirit, I've updated the gist based on the comments and I've set a
goal to implement (or at least attempt to implement) my idea using Narcissus
- again, purely for my own benefit, however I will certainly share my
findings for those that might be interested.
Again, thanks for the constructive feedback!
Rick
On Mon, May 9, 2011 at 9:51 AM, Dave Herman dher...@mozilla.com wrote:
Andrew Dupont mozi...@andrewdupont.net wrote:
Presumably it could be defined in the grammar so as to prohibit a
newline in that very place, much like how the return statement is
defined.
Yeah, but that's one of the sharper corners of JS as is-- I think it would
be pretty subtle and error prone. And some people might want to align their
braces.
Alternatively: someone in this thread asked whether there was any
purpose to blocks in ES when they aren't used for try/catch/finally or
other such purposes. In other words, is there any reason not to
restrict them to those use cases and thus remove this ambiguity?
This would be a serious backwards-incompatibility, and with block scoping
they will become very important. My crystal ball envisions a web full of
if (true) {
...
}
;-)
Dave
Cheers,
Andrew
On May 8, 2011, at 11:20 PM, Dave Herman wrote:
Do I understand you that the idea here is 'function' without the
'function' keyword? I think this has a pretty bad
backwards-incompatibility with ASI:
x = (x)
{ return x }
Which way should this parse?
Dave
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Rick Waldron waldron.r...@gmail.com wrote:
Just read
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html
and I'm buzzing with the idea of Lisp style functions as inspiration
for a short hand. While I realize the idea is likely absurd, but I'm
thinking in terms of concepts that _all_ JavaScript devs know and
understand.
This is a super simple, first-pass, rough-draft, not-too-serious,
request-for-comments...
https://gist.github.com/961495
Rick
On Sun, May 8, 2011 at 1:51 PM, Faisal Vali fais...@gmail.com
wrote:
On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com
wrote:
On 08/05/2011, at 05:52, Faisal Vali wrote:
(...) I find the
aesthetics of the arrow-syntax far more consistent with
javascript's
C-based-syntactic roots than the preprocessor-tainted '#' (...)
Consistent ?
- in C has a *totally* different meaning !
Yes, but that is why I alluded to a syntactic commonality and not a
semantic one.
But, I can see how the disparity in semantics might bother some
programmers.
___
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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
function bodies extend as far as possible **
I see. So, a function body would be just like an if-block or loop
body. One full statement, or a block. There is precedent for that in
the rest of the language. So, then, this case:
x = function () y; z
would be:
x = function () { return y }; z
Is that a trick question?-) Your interpretation is one plausible
extrapolation of this maximal munch rule to cover javascript's
function body blocks but it might not be the only one.
In particular, you have chosen to combine maximal munch for
expressions with minimal munch for statement lists, while one
might want to apply maximal munch to both expressions and
statement lists (if the braces around function bodies were to
be made optional). One would need to look at the design options
in detail before making a decision.
Javascript's handling of the statement/expression divide could
do with some work, e.g., we want to be able to use functions to
build control abstractions; but javascript has chosen to make
assignments into expressions, and expressions into statements;
javascript statements/blocks are currently not expressions, and
if we tried to correct that, we'd run into the question of what to
do with assignments (pass them around or execute them).
In the meantime, the only way to abstract over blocks is to
wrap them in functions, so if we wanted to emulate conditional
statements with conditional expressions (or other use cases
where we want to work with blocks as values), we'd write
something like this:
(condition ? function() { ..blockA.. } : function() { ..blockB.. })();
The use of function wrappers to delay execution is yet another
motivation for concise (but readable and unambiguous) function
syntax.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 6, 2011, at 11:22 PM, Peter Michaux wrote: On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont mozi...@andrewdupont.net wrote: I don't want to get too deep into matters of taste, but I do think the current syntax is annoyingly verbose for passing lambdas as arguments in other functions. The fact that it's so verbose ends up hurting readability when the function itself is short. I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. You're free to keep writing eight characters all over the place :-|. If you don't like reading a shorter function syntax (# has been proposed as well as -, and I've combined the two to make #'s meaning compositional with respect to object initialisers for records and array initialisers for tuples), then shun the offending code by not reading it. I think improving JavaScript as a compilation target is a good goal. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, That's what I'm proposing, ignoring control effects. By real 'lambda' you must also mean new control effects, with novel runtime exceptions, e.g., for return in a lambda attempting to return out of an inactive outer function. We've already decided several times (on this list, even) not to do that kind of lambda. IIRC Maciej's post dealt the death blow: http://www.mail-archive.com/es-discuss@mozilla.org/msg01533.html But why in the world are you favoring new and definitely more confusing runtime semantics along with lambda syntax, while objecting to shorter function syntax that avoids ten or 12 of 14 letters? etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. Yes, and we could add call/cc to make (some) compiler writers even happier. But users would shoot off all their toes with this footgun, and some implementors would be hard-pressed to support it. The point is *not * to do any one change that maximizes benefits to some parties while harming others. Again, I claim you are not harmed by shorthands. Read them or reject them, don't use them. JS has many ways to say things, it is already multi-paradigm in shallow and deep ways. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 7, 2011, at 1:37 AM, Jorge wrote: But if I wanted a shorter syntax, I would no doubt choose ruby blocks' syntax, it's even shorter yet and it's familiar already to millions of programmers. Ruby and Smalltalk before it had blocks for most of their usable lives. JS does not. Having break, continue, return, this, arguments, and perhaps other features of JS change meaning in a block to refer to aspects of the outer function's activation (if still active) is a big change. It adds new runtime error cases. It's certainly not simpler than shorter function syntax. Not all JS hackers are Rubyists. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 9, 2011, at 2:21 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-09 at 11:02 , Kyle Simpson wrote:
Isn't that the spirit of what = would give us?
Yes and this case makes following example extremely confusing:
MyObject.prototype.bar = #(x) { this.bar = x }
Is this instance of MyObject ? So we need to use `#` in some places, but in
other cases we need to stick to long form `function`. I think `-` and `=`
is way more intuitive and simple.
Exactly. Beyond the CoffeeScript precedent (pave the cowpaths) there is the
EIBTI Python dictum. We should not add a shorthand for function that materially
differs in semantics. Alex Russell argued this point with respect to # freezing
and joining (that is, uniting object identity up to the nearest relevant
closure). It applies to |this|-binding too.
It is hard to beed = for lexically bound |this| function vs. - for
dynamically bound |this| function. I've tried. Any form that defaults to
lexical-|this| and looks like a function from (...){...} on is going to mislead
programmers, exaclty as you show above.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
You are ignoring =. Please do read the strawman, such as it is. Edits coming soon to clarify. /be On May 7, 2011, at 11:48 PM, Garrett Smith wrote: On 5/7/11, Faisal Vali fais...@gmail.com wrote: Kyle Simpson get...@gmail.com Date: Sat, 7 May 2011 21:58:32 -0500 Subject: Re: arrow syntax unnecessary and the idea that function is too long snip With all due respect, Brendan's personal tastes on what kind of code he likes to write is not enough. It has to be something that is likely to find wide spread support among the JavaScript masses. Since the arrow syntax assailants have been quite vocal on this list, Yeah, not much vocal whatevers, right? I haven't seen much into the benefit of -. I haven't given it a whole lot of thought and don't find it all that thrilling, really. Unusually underopinionated for me, I know. Though If I was forced to pick between - and #, I'd pick #. -- Garrett ___ 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: arrow syntax unnecessary and the idea that function is too long
Read the whole thread. As I noted earlier today, Maciej pointed out the
infelicity of a new control effect system (return, break and continue in lambda
affecting the outer function, and throwing if the outer function has returned
already). Waldemar observed that it is hard to beat function, except for the
syntactic burden. You end up introducing something too like function to be
worth it, or too strange and confusingly different in JS's
statements-for-control-effects non-functionally-pure world.
/be
On May 8, 2011, at 2:39 AM, Jorge wrote:
On 08/05/2011, at 04:58, Kyle Simpson wrote:
(...) So I felt like it was important to voice early that not everyone
feels universally so lovey-dovey over that syntax. (..)
What happened to Allen's lambda syntax proposal ?
When, why was it ditched in favor of - ?
Brendan, you liked it. What has happened ?
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008216.html
--
Jorge.
Begin forwarded message:
From: Brendan Eich bren...@mozilla.com
Date: 30 de noviembre de 2008 07:30:14 GMT+01:00
To: es-discuss@mozilla.org
Subject: Allen's lambda syntax proposal
At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding
discussion about lambda syntax and why it matters. Observation: blocks in
Smalltalk being lightweight means users don't mind writing them for control
abstractions, compared to JS functions in ES3. In Smalltalk, ignoring JS,
it's hard to beat [ and ] as overhead, although one must count the message
selector and its punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I then started to write an example of return to label, and in need of a
nested lambda, got stuck for a split second trying to write
function^H^H^H^H^H^H^H^lambda. After thinking 0.3 more seconds I then said
I will use Allen's proposed syntax. Pure win, readers and the writer (me)
agreed.
I think someone proposed pretty much the same syntax here on es*-discuss
within the last two years, but I can't find that message at the moment.
Bikeshed color is secondary to semantics, but lambda conciseness does
matter. I think Allen's homage to Smalltalk in JS wins. Every time I reach
for more verbose syntax my hand steers back to those || delimiters.
Am I an old Smalltalk fan? Sure, I have Byte magazine with the balloons on
the cover still (in a box somewhere; mildewed, sadly). I'm the C hacker who
took the make it look like Java orders and made it look like C with some
awk, Self, Scheme, and even HyperCard (HyperTalk, actually) influences.
Eclecticism is not an end, but it could be a means to a better end than a
cramped non-eclectic grammar, if the deeper reasons for concise lambda
syntax are sound and valid. Syntax is for users, it must be usably sweet.
It's not all about theoretical completeness and minimality.
Anyway, we need a fun weekend thread, and everyone loves syntax. Comments?
Huzzahs? The latter go to Allen. Go nuts.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 9, 2011, at 2:21 AM, Irakli Gozalishvili wrote:
On Monday, 2011-05-09 at 11:02 , Kyle Simpson wrote:
Isn't that the spirit of what = would give us?
Yes and this case makes following example extremely confusing:
MyObject.prototype.bar = #(x) { this.bar = x }
Is this instance of MyObject ? So we need to use `#` in some places, but in
other cases we need to stick to long form `function`. I think `-` and `=`
is way more intuitive and simple.
Exactly. Beyond the CoffeeScript precedent (pave the cowpaths) there is the
EIBTI Python dictum. We should not add a shorthand for function that materially
differs in semantics. Alex Russell argued this point with respect to # freezing
and joining (that is, uniting object identity up to the nearest relevant
closure). It applies to |this|-binding too.
It is hard to beed = for lexically bound |this| function vs. - for
dynamically bound |this| function. I've tried. Any form that defaults to
lexical-|this| and looks like a function from (...){...} on is going to mislead
programmers, exaclty as you show above.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
I wrote PHP full time for years. - can get pretty aggravating. # is 50% shorter, and doesn't use the same fingers that type the (). ()- is a lot of right-hand-dancing. That being said, it does look pretty nice, and we're all just going to set our editors to do that for us anyhow, right? On Sat, May 7, 2011 at 20:52, Faisal Vali fais...@gmail.com wrote: Kyle Simpson get...@gmail.com Date: Sat, 7 May 2011 21:58:32 -0500 Subject: Re: arrow syntax unnecessary and the idea that function is too long snip With all due respect, Brendan's personal tastes on what kind of code he likes to write is not enough. It has to be something that is likely to find wide spread support among the JavaScript masses. Since the arrow syntax assailants have been quite vocal on this list, lest they be construed as representative of the javascript masses, I would like to voice a strong endorsement for pursuing and exploring the arrow syntax further - and I do this as a simple javascript hobbyist who uses javascript (and JQuery, for lack of the perfect library) extensively to automate tasks on windows (via htas) and to write RIAs. With all due respect to Mr. Simpson's personal tastes, I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' - but I also recognize that my personal aesthetic tastes are just that. Anyway, I hope that enough general users share my aesthetic and usability preference (short syntax for functionally well behaved and intuitive lambdas with closure capability) that the arrow syntax is given some serious thought and not dismissed because of this thread. Thanks! Faisal Vali ___ 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: arrow syntax unnecessary and the idea that function is too long
On 5/7/11, Faisal Vali fais...@gmail.com wrote: Kyle Simpson get...@gmail.com Date: Sat, 7 May 2011 21:58:32 -0500 Subject: Re: arrow syntax unnecessary and the idea that function is too long snip With all due respect, Brendan's personal tastes on what kind of code he likes to write is not enough. It has to be something that is likely to find wide spread support among the JavaScript masses. Since the arrow syntax assailants have been quite vocal on this list, Yeah, not much vocal whatevers, right? I haven't seen much into the benefit of -. I haven't given it a whole lot of thought and don't find it all that thrilling, really. Unusually underopinionated for me, I know. Though If I was forced to pick between - and #, I'd pick #. -- Garrett ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 08/05/2011, at 05:52, Faisal Vali wrote: (...) I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' (...) Consistent ? - in C has a *totally* different meaning ! -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 08/05/2011, at 04:58, Kyle Simpson wrote:
(...) So I felt like it was important to voice early that not everyone
feels universally so lovey-dovey over that syntax. (..)
What happened to Allen's lambda syntax proposal ?
When, why was it ditched in favor of - ?
Brendan, you liked it. What has happened ?
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008216.html
--
Jorge.
Begin forwarded message:
From: Brendan Eich bren...@mozilla.com
Date: 30 de noviembre de 2008 07:30:14 GMT+01:00
To: es-discuss@mozilla.org
Subject: Allen's lambda syntax proposal
At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding
discussion about lambda syntax and why it matters. Observation: blocks in
Smalltalk being lightweight means users don't mind writing them for control
abstractions, compared to JS functions in ES3. In Smalltalk, ignoring JS,
it's hard to beat [ and ] as overhead, although one must count the message
selector and its punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I then started to write an example of return to label, and in need of a
nested lambda, got stuck for a split second trying to write
function^H^H^H^H^H^H^H^lambda. After thinking 0.3 more seconds I then said I
will use Allen's proposed syntax. Pure win, readers and the writer (me)
agreed.
I think someone proposed pretty much the same syntax here on es*-discuss
within the last two years, but I can't find that message at the moment.
Bikeshed color is secondary to semantics, but lambda conciseness does matter.
I think Allen's homage to Smalltalk in JS wins. Every time I reach for more
verbose syntax my hand steers back to those || delimiters.
Am I an old Smalltalk fan? Sure, I have Byte magazine with the balloons on
the cover still (in a box somewhere; mildewed, sadly). I'm the C hacker who
took the make it look like Java orders and made it look like C with some
awk, Self, Scheme, and even HyperCard (HyperTalk, actually) influences.
Eclecticism is not an end, but it could be a means to a better end than a
cramped non-eclectic grammar, if the deeper reasons for concise lambda syntax
are sound and valid. Syntax is for users, it must be usably sweet. It's not
all about theoretical completeness and minimality.
Anyway, we need a fun weekend thread, and everyone loves syntax. Comments?
Huzzahs? The latter go to Allen. Go nuts.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com wrote: On 08/05/2011, at 05:52, Faisal Vali wrote: (...) I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' (...) Consistent ? - in C has a *totally* different meaning ! Yes, but that is why I alluded to a syntactic commonality and not a semantic one. But, I can see how the disparity in semantics might bother some programmers. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Just read https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html and I'm buzzing with the idea of Lisp style functions as inspiration for a short hand. While I realize the idea is likely absurd, but I'm thinking in terms of concepts that _all_ JavaScript devs know and understand. This is a super simple, first-pass, rough-draft, not-too-serious, request-for-comments... https://gist.github.com/961495 Rick On Sun, May 8, 2011 at 1:51 PM, Faisal Vali fais...@gmail.com wrote: On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com wrote: On 08/05/2011, at 05:52, Faisal Vali wrote: (...) I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' (...) Consistent ? - in C has a *totally* different meaning ! Yes, but that is why I alluded to a syntactic commonality and not a semantic one. But, I can see how the disparity in semantics might bother some programmers. ___ 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: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 4:17 PM, David Herman dher...@mozilla.com wrote:
But we are going to have to make a decision, and it simply won't
be perfect. We're going to listen to everyone, consider the
technical issues, and at the end of the day, make the best
decision we can with imperfect information.
I hope the committee keeps in mind that it can choose not to include
any short function syntax. I know the committee knows that but I hope
it is near the top of the list as one of the options.
On Sat, May 7, 2011 at 4:40 PM, Kyle Simpson get...@gmail.com wrote:
But, JSConf has just 150-200 JavaScript developers in attendance. While they
are certainly some of the most passionate (and intelligent) developers of
the community, no doubt, they are definitely not a representative sampling
of the overall community. Making language decisions based on the vocal
support of JSConf alone is not sufficient.
Agreed. I think the personality type of hundreds of developers that
attend conferences is quite different than the tens of thousands of
developers that don't attend.
I think I could easily come up with a dozen examples of patterns in
JavaScript coding which are shorter, but which most of the community would
say is *not* more readable. So I take issue with the assertion that
shorter==better unequivocally.
Agreed. There shouldn't be the feeling that shorter function syntax is
desperately needed and that it has to go into the next ES even if it
is not perfect.
On Sat, May 7, 2011 at 5:18 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Brendan once said JS is a curly-brace language and it always will be. I
think the - looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep #(x) { x * x }.
I also think familiarity should be considered and that #(x) { x * x } would
be more familiar to the casual JS programmer.
I agree with this type of thinking about keeping syntax similar with
arguments in parens and the body in braces more than introducing
something so foreign to JavaScript like the arrow syntax.
On Sat, May 7, 2011 at 7:33 PM, Isaac Schlueter i...@izs.me wrote:
It has been my experience that professional JavaScripters will cheer
*any* idea that shortens the spelling of function and return :)
There are professional JavaScript programmers in *this* thread that
aren't cheering. That is why this thread started.
On Sat, May 7, 2011 at 7:58 PM, Kyle Simpson get...@gmail.com wrote:
So I felt like it was important to voice early that not everyone feels
universally so lovey-dovey over that syntax. In fact, a recent tweet I read
sums up my feelings: If I wanted to be using Coffeescript, I'd be using
Coffeescript. I prefer JavaScript.
Exactly! There are syntactic features that some developers want that
are so far from JavaScript that they shouldn't or can't be
incorporated into the language. This is why compilers exist and I hope
that the to-JavaScript compiler community grows if people want to do
that sort of thing.
I've talked with some JavaScript developers and asked them What do
you think of Coffeescript? without biasing my question. I've had a
100% negative response. They aren't interested in using Coffeescript
_at_all_. So just because Coffeescript has some vocal fans, it has not
caught on like wildfire. In the big scheme of things it has virtually
not caught on at all. It is a very fringe group that is experimenting.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
I'm really happy that arrow syntax proposal was made and thanks a lot Brendan!! I'd like to point out that coffeescript has a huge success and in the end it's just syntax sugared js. I think this is quite good proof that syntax change like this is more then welcome. Another thing I'd like to point out that arrow function is not just saving keystrokes of typing `function` and `return`, but also gives even bigger win IMO via `=` when binding of `this` pseudo variable is desired. This case BTW was not addressed by `#`. Even though `-` is one more char in comparison to `#`, `=` is much less then `.bind(this)`, in addition having both - and = feels just natural! Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France On Sunday, 2011-05-08 at 19:09 , Rick Waldron wrote: Just read https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html and I'm buzzing with the idea of Lisp style functions as inspiration for a short hand. While I realize the idea is likely absurd, but I'm thinking in terms of concepts that _all_ JavaScript devs know and understand. This is a super simple, first-pass, rough-draft, not-too-serious, request-for-comments... https://gist.github.com/961495 Rick On Sun, May 8, 2011 at 1:51 PM, Faisal Vali fais...@gmail.com wrote: On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com wrote: On 08/05/2011, at 05:52, Faisal Vali wrote: (...) I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' (...) Consistent ? - in C has a *totally* different meaning ! Yes, but that is why I alluded to a syntactic commonality and not a semantic one. But, I can see how the disparity in semantics might bother some programmers. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sun, May 8, 2011 at 11:34 AM, Irakli Gozalishvili rfo...@gmail.com wrote: I'd like to point out that coffeescript has a huge success and in the end it's just syntax sugared js. Can someone give evidence that Coffeescript is actually a success? Has anyone crawled the web to determine the rate of Coffeescript adoption? (Assuming there is some way to identify Coffeescript's compiled code.) Will adoption plateau at a small percentage of total browser scripts? People cannot just reiterate this idea that Coffeescript is popular and use that as support for arrows without evidence that Coffeescript is actually popular. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Do I understand you that the idea here is 'function' without the 'function'
keyword? I think this has a pretty bad backwards-incompatibility with ASI:
x = (x)
{ return x }
Which way should this parse?
Dave
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Rick Waldron waldron.r...@gmail.com wrote:
Just read
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html and I'm
buzzing with the idea of Lisp style functions as
inspiration for a short hand. While I realize the idea is likely absurd, but
I'm thinking in terms of concepts that _all_ JavaScript devs know and
understand.
This is a super simple, first-pass, rough-draft, not-too-serious,
request-for-comments...
https://gist.github.com/961495
Rick
On Sun, May 8, 2011 at 1:51 PM, Faisal Vali fais...@gmail.com wrote:
On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com wrote:
On 08/05/2011, at 05:52, Faisal Vali wrote:
(...) I find the
aesthetics of the arrow-syntax far more consistent with javascript's
C-based-syntactic roots than the preprocessor-tainted '#' (...)
Consistent ?
- in C has a *totally* different meaning !
Yes, but that is why I alluded to a syntactic commonality and not a
semantic one.
But, I can see how the disparity in semantics might bother some programmers.
___
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: arrow syntax unnecessary and the idea that function is too long
Presumably it could be defined in the grammar so as to prohibit a newline in
that very place, much like how the return statement is defined.
Alternatively: someone in this thread asked whether there was any purpose to
blocks in ES when they aren't used for try/catch/finally or other such
purposes. In other words, is there any reason not to restrict them to those use
cases and thus remove this ambiguity?
Cheers,
Andrew
On May 8, 2011, at 11:20 PM, Dave Herman wrote:
Do I understand you that the idea here is 'function' without the 'function'
keyword? I think this has a pretty bad backwards-incompatibility with ASI:
x = (x)
{ return x }
Which way should this parse?
Dave
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Rick Waldron waldron.r...@gmail.com wrote:
Just read
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html and
I'm buzzing with the idea of Lisp style functions as inspiration for a
short hand. While I realize the idea is likely absurd, but I'm thinking in
terms of concepts that _all_ JavaScript devs know and understand.
This is a super simple, first-pass, rough-draft, not-too-serious,
request-for-comments...
https://gist.github.com/961495
Rick
On Sun, May 8, 2011 at 1:51 PM, Faisal Vali fais...@gmail.com wrote:
On Sun, May 8, 2011 at 4:04 AM, Jorge jo...@jorgechamorro.com wrote:
On 08/05/2011, at 05:52, Faisal Vali wrote:
(...) I find the
aesthetics of the arrow-syntax far more consistent with javascript's
C-based-syntactic roots than the preprocessor-tainted '#' (...)
Consistent ?
- in C has a *totally* different meaning !
Yes, but that is why I alluded to a syntactic commonality and not a
semantic one.
But, I can see how the disparity in semantics might bother some programmers.
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 10:49 PM, Andrew Dupont mozi...@andrewdupont.net wrote: On May 7, 2011, at 12:42 AM, Peter Michaux wrote: Yes and readability counts. JavaScript's function syntax is already *highly* usable and readable. Many people, including me, would disagree. Do you really struggle using or reading the current function syntax? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Many people, including me, would disagree. On matters of taste, I'd want the committee to listen to all interested parties and try to pick the solution that pleases the most people. That appears to be what's happening here. Based on what evidence are we concluding that the majority of the javascript developers want - syntax for functions? The fact that coffeescript is the hot buzzword? Was there some developer-community wide voting or poll that I missed? Or is it that a few vocal people on these lists like it, and that's being substituted as what the majority is in favor of? I'm not just being snarky, I'm genuinely curious, on this and a variety of other matters related to what's being added to ES-next/harmony... It's clear Brendan (and other language cohorts) likes these new syntax sugars, but where is the evidence that suggests that all this new syntax sugar is the exact sugar that javascript developers want? Is it just enough that everyone at JSConf likes it, and thus that means that the whole community is assumed to be on board? There's LOTS of examples where writing less JavaScript is more awesomer, but there's also plenty of examples of where writing less is much more uglier. I am troubled by the implication that just because we've found a shorter syntax sugar for functions, this unequivocally means it's better. - syntax being shorter is a clear and objective question. No doubt it's shorter. But is is prettier or more readable? According to who's opinion do we conclude that, because that seems pretty subjective. --Kyle ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont mozi...@andrewdupont.net wrote: I don't want to get too deep into matters of taste, but I do think the current syntax is annoyingly verbose for passing lambdas as arguments in other functions. The fact that it's so verbose ends up hurting readability when the function itself is short. I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. I think improving JavaScript as a compilation target is a good goal. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On 07/05/2011, at 02:04, Peter Michaux wrote:
(...)
If the arrow syntax is only syntactic sugar for the existing function
forms then I don't see how it achieves any of the goals he outlined.
The only possible category is be a better language but the arrow
syntax won't make JavaScript a better language for complex
applications or libraries in comparison to any other kind of
JavaScript code. I would argue that the arrow syntax will make
JavaScript a worse language anyway as there are already perfectly good
forms using the function keyword now. We don't need new syntax and
we don't need multiple ways to do the same thing just for the sake 6
characters. Please keep JavaScript simple.
(...)
This above is ~ how I feel about it too.
But if I wanted a shorter syntax, I would no doubt choose ruby blocks' syntax,
it's even shorter yet and it's familiar already to millions of programmers.
On 07/05/2011, at 03:22, David Bruant wrote:
I'm attracted to the idea of a shorter function syntax not only because
it reduces the number of characters of the function keyword, but also
because it gets rid of the return keyword (and corresponding semicolon).
(return does not need the semicolon ;-)
The particular case where I would enjoy shorter syntax is when using
inlined functions in array extras.
// assuming a is an array
a.filter( (e)-(typeof e === number e3) )
.map( (e)-(e*e) )
.reduce( (prev, curr)-(prev+curr), 0);
Using ruby blocks' syntax (+6 versus +4 chars):
a.filter( {|e| typeof e === number e3})
.map({|e| e*e } )
.reduce( {|prev, curr| prev+curr}, 0);
Is {| as a token likely to be found in any .js source file in the world, as
of today ?
- Not in any object literal
- Not likely to be found at the beginning of a block.
- Inside a string it would not matter.
--
Jorge.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Just to add my two cents, I would like to let you remember that the arrow
syntax should not be viewn as the only way to avoid the 'return' statement
and the brackets. function(x) x*x; does the trick too, whithout
introducing any new keyword. To those that think that the arrow syntax is
easier to type because there's less characters to type, it may be
disappointing to notice it's not the case : (x) - x*x; is only 5
characters shorter than the other form but :
- You don't beneficiate from autocompletion anymore (in most IDE, typing
'fun+TAB' brings up 'function' arlready)
- The '-' and the '' characters are more complex to type (on my
keyboard, both then - and the char requires me to move my hand away from
its standards position, and the time it takes to type ' - ' equals or is
more important than the time I need to type 'function' in *full* word, which
I usually don't need to).
- The syntax is less clear. CSharp originally introduced something like
that in the past, and I never liked the syntax. (It's to notice that the
VB.NET language later implemented the lambda feature using the Function(X)
X*X syntax). Okay, if I could really choose, I would prefer the @(x) x*x;
syntax, which is already implemented as-is in other scripting languages
such as MatLAB (but I already hear the concerns about other possible usages
of the @ sign).
- It introduces ambiguities in the code (Sample: var z = (x) - x || y)
Regards,
François
-Message d'origine-
From: Brendan Eich
Sent: Saturday, May 07, 2011 3:39 AM
To: Peter Michaux
Cc: es-discuss@mozilla.org
Subject: Re: arrow syntax unnecessary and the idea that function is too
long
On May 6, 2011, at 5:04 PM, Peter Michaux wrote:
The only possible category is be a better language but the arrow
syntax won't make JavaScript a better language for complex
applications or libraries in comparison to any other kind of
JavaScript code.
Usability is always on the top three lists of programming language success
factors. 'function' and 'return' are too long.
I would argue that the arrow syntax will make
JavaScript a worse language anyway as there are already perfectly good
forms using the function keyword now.
Eight characters is at least six too many.
We don't need new syntax and
we don't need multiple ways to do the same thing just for the sake 6
Wrong, 14. You are not counting 'return'.
characters. Please keep JavaScript simple.
Sorry, this is a bogus argument. Simple does not mean fewest productions
in all possible grammars or fewest ways of saying any given sentence.
That is simpler by some measures, more complex by others. In particular,
writing and (lesser but still material) reading 'function' over and over is
not a win.
Consider the destructuring object shorthand: let {x, y} = pt; instead of let
{x:x, y:y} = pt;
Look at all the complex/subtle edge cases mentioned in the wiki page
about arrow function syntax. Do we really want to have that much
trickiness added to the language?
The wiki page is a work in progress. I have updates coming, which should
address the parenthesization burden. But again, you can use 14 characters if
you want. This is shorthand, and only shorthand. And usability counts, so
shorthands are in Harmony (e.g., destructuring)
Gzip is not the issue (although stats I've seen from Steve Souders show too
may scripts not being compressed at the Transfer-encoding layer). Human
usability is.
/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: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 2:22 AM, Peter Michaux petermich...@gmail.com wrote: I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. I think improving JavaScript as a compilation target is a good goal. This argument comes up time and again: We don't need to make JavaScript a good programming language, just a good compilation target. I think it's really wrong-headed. First, JavaScript is a language used by millions of people as a programming language, and we should give them a great language to program in. Second, JavaScript as source rather than target has been a huge enabler of the Web as an open platform, which I certainly don't want to move away from. So, even though we've worked hard in the module system to better support compilation to JavaScript, I think the our fundamental goal should be to make JavaScript a great language to write all kinds of programs in. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. And hey, it turns out we've done this too -- at least with the - syntax. :) -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 6:04 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, May 7, 2011 at 2:22 AM, Peter Michaux petermich...@gmail.com wrote: I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. I think improving JavaScript as a compilation target is a good goal. This argument comes up time and again: We don't need to make JavaScript a good programming language, JavaScript is already a good programming language. It can use improvements but it has good covered. just a good compilation target. I did not write that it needs to be just a good compilation target. I don't use a compiler to enable me to write source in another language and then serve JavaScript to the browser. I write in JavaScript. So I do want JavaScript to remain a good language. That said, improving JavaScript as a compilation target does expose areas where the language could use features it does not have at all (in any syntax.) Adding those features makes JavaScript objectively a more capable language. I think it's really wrong-headed. Me too. First, JavaScript is a language used by millions of people as a programming language, and we should give them a great language to program in. JavaScript already has great covered too. :-) I'd be willing to go for even better but the arrow syntax isn't even a significant contribution to this cause. Real features would be. A weak map, for example, is a great idea because we just cannot do anything like that now without implementing our own garbage collection. Second, JavaScript as source rather than target has been a huge enabler of the Web as an open platform, which I certainly don't want to move away from. So, even though we've worked hard in the module system to better support compilation to JavaScript, I think the our fundamental goal should be to make JavaScript a great language to write all kinds of programs in. That wasn't one of Brendan's stated goals; however, it is a good goal. I think the arrow syntax is not helpful in this goal. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. And hey, it turns out we've done this too -- at least with the - syntax. :) It has been confirmed that the arrow syntax is *only* syntactic sugar for existing function syntax. That means introducing the arrow syntax does *not* improve the compilation Scheme to JavaScript *at all*. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 6:31 PM, Peter Michaux petermich...@gmail.com wrote: On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl thaddee@gmail.com wrote: I believe that David Bruant has a good point. We *need* a shorter syntax because we advocate the use of map/reduce, etc., which require simple anonymous functions. No. We don't need syntactic sugar. The current function syntax is working and we are talking a few characters difference, not hundreds. Map/reduce don't require syntactic sugar. It is not a requirement, indeed. I feel like it is a need, however. JavaScript is still seen as a badly object-oriented programming language by those who still think it is java with a weird syntax. I do hope it grows to be known as an outstanding functional programming language. Thanks to ES5's strict mode, it now gets freed from the this issue, for those that use it. Huffmanization requires that we reduce the size of what we want to use often. If we want to use more functions, then it isn't just eleven less characters once in a while, it becomes a bigger deal! There are so many more important issues to address. If you feel like addressing more important issues, I warmly beg you to do so! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 9:56 AM, Thaddee Tyl thaddee@gmail.com wrote: JavaScript is still seen as a badly object-oriented programming language by those who still think it is java with a weird syntax. I think that concpetion has declined a lot as rich clients have forced people to become better acquainted with JavaScript and a lot more has been written on the language. I do hope it grows to be known as an outstanding functional programming language. JavaScript won't ever be known as a outstanding functional programming language until it has proper tail calls. This would give the language new capabilities it doesn't have now. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
For what it's worth, I'm a *huge* fan of Ruby's {|-style blocks.
Also, it's worth noting that do...done seems to be a bit more
popular in Ruby programs that I've seen.
I'm not a fan of the fact that these blocks have different behavior
than regular functions and methods, but that's a qualm for a
different mailing list, and I'm not a rubyist anyhow :)
Consider this: w = (x)-y || z
That code is not obvious at all. Which of these would it be?
1: w = function (x) { return y } || z
2: w = function (x) { return y || z }
It seems to me that there must be some sort of delineation around the
function start and end. I agree that function ... return is way too
many characters to write and read for such a fundamental bit of
syntax.
This style is quite clear and readable:
w = {|x| y || z}
w = {|x| y} || z
However, that's pretty awful to type. Perhaps even worse than -.
Maybe {(x) y || z} might be better? Of course, that would break
blocks that start with parenthesized sequence blocks, but is that
really a concern? Blocks in JS are useless, can't we just do away
with them?
On Sat, May 7, 2011 at 10:04, Peter Michaux petermich...@gmail.com wrote:
On Sat, May 7, 2011 at 9:56 AM, Thaddee Tyl thaddee@gmail.com wrote:
JavaScript is still seen as a badly object-oriented programming
language by those who still think it is java with a weird syntax.
I think that concpetion has declined a lot as rich clients have forced
people to become better acquainted with JavaScript and a lot more has
been written on the language.
I do
hope it grows to be known as an outstanding functional programming
language.
JavaScript won't ever be known as a outstanding functional programming
language until it has proper tail calls. This would give the language
new capabilities it doesn't have now.
Peter
___
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: arrow syntax unnecessary and the idea that function is too long
On 5/7/11, Isaac Schlueter i...@izs.me wrote: [...] Blocks in JS are useless, can't we just do away with them? Blocks are required for many productions such as try/catch/finally. Almost all existing code uses blocks to group statements together. Blocks can't be removed. -- Garrett ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 1:04 PM, Peter Michaux petermich...@gmail.com wrote: JavaScript won't ever be known as a outstanding functional programming language until it has proper tail calls. This would give the language new capabilities it doesn't have now. http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls (note that it's in the Harmony namespace, meaning that it's been approved as a proposal). -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Consider this: w = (x)-y || z
That code is not obvious at all. Which of these would it be?
1: w = function (x) { return y } || z
2: w = function (x) { return y || z }
It seems to me that there must be some sort of delineation
around the function start and end.
But such delineation does not have to lead to required syntax
in the function construct. Such required delineations were not
part of lambda-calculus originally **, they arose out of
implementation limitations that can be overcome.
I know that takes some getting used to (been there myself*),
but there is an established standard, both in publications on
programming language theory, and in some real languages:
function bodies extend as far as possible **
So your examples would be
1: w = (function (x) return y) || z
2: w = (function (x) return y || z)
If the right-hand side itself is delimited, 2 could also be written
2': w = function (x) return y || z
The idea is that we can always shorten an unbounded function
by enclosing it with existing grouping constructs, but we cannot
lengthen a pre-delineated function in any way, nor can we get
rid of the delineating parens and braces if they are required in
the grammar. Combining non-delineated functions with grouping
constructs gives us a modular and unambiguous solution.
Another issue is that of blocks in function bodies. It would be
nice if blocks were values - then procedures would just be
block-returning functions, and all functions would just return
values, separating the function construct from the details of
block execution. Not sure whether such niceties would work
in javascript, though:-)
Claus
* I used to write my lambda-calculus terms fully parenthesized,
because the functional languages I knew (before Haskell)
required that style. Many programming language theory
folks found that style difficult to read, because they had
grown up with the extends-as-far-as-possible convention.
** Church, Barendregt, .., they all define lambda-terms as
term := x | (\x term) | (term term)
with additional conventions to drop parentheses where
possible, such as
(A B C D) instead of (((A B) C) D)
(\x y z.M) instead of (\x (\y (\z M)))
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Based on what evidence are we concluding that the majority of the javascript developers want - syntax for functions? The fact that coffeescript is the hot buzzword? Was there some developer-community wide voting or poll that I missed? Or is it that a few vocal people on these lists like it, and that's being substituted as what the majority is in favor of? IIRC there were cheers at JSConf this week. But you're looking for something that doesn't exist: a way to make scientifically sound decisions about language design. There is *no* way to resolve syntax questions perfectly. We welcome community input, all community input. But we are going to have to make a decision, and it simply won't be perfect. We're going to listen to everyone, consider the technical issues, and at the end of the day, make the best decision we can with imperfect information. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Based on what evidence are we concluding that the majority of the javascript developers want - syntax for functions? The fact that coffeescript is the hot buzzword? Was there some developer-community wide voting or poll that I missed? Or is it that a few vocal people on these lists like it, and that's being substituted as what the majority is in favor of? IIRC there were cheers at JSConf this week. Yeah, I unfortunately wasn't able to attend. I was quite sad about missing JSConf for the first time. But, JSConf has just 150-200 JavaScript developers in attendance. While they are certainly some of the most passionate (and intelligent) developers of the community, no doubt, they are definitely not a representative sampling of the overall community. Making language decisions based on the vocal support of JSConf alone is not sufficient. I was certain there had to be more behind the claim than just that. So that's what I was asking for. But you're looking for something that doesn't exist: a way to make scientifically sound decisions about language design. I am not looking for any such thing. I was looking for more detail behind Brendan's (and Andrew's) assertions that - is definitively better because it's shorter (and for no other stated reason). There is *no* way to resolve syntax questions perfectly. We welcome community input, all community input. I don't claim that any such perfect system could be devised. I was merely responding to Andrew's insinuation that the majority of the community (including him) had already voiced support for -. If someone makes an implication, I think it's fair game on here to ask for the supporting reasoning. I think I could easily come up with a dozen examples of patterns in JavaScript coding which are shorter, but which most of the community would say is *not* more readable. So I take issue with the assertion that shorter==better unequivocally. But we are going to have to make a decision, and it simply won't be perfect. We're going to listen to everyone, consider the technical issues, and at the end of the day, make the best decision we can with imperfect information. From the tone of this thread, and from many other recent postings regarding reactions from JSConf this week, it sounded like all of a sudden we'd gone from yeah coffeescript has some interesting short-hand syntax to the community has spoken, and coffeescript will be adopted into ES.Harmony/Next as-is. I was, and am now, still wondering how we so quickly made the leap from Brendan's harmony of my dreams a couple of months ago, where the idea of # sounded good, and plausible for inclusion, all the way to Brendan declaring that it's basically a done deal that we'll be including a variety of function and other shorthands from coffeescript post haste? --Kyle ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
But, JSConf has just 150-200 JavaScript developers in attendance. Right. The JS community has no borders, no government, no constitution, no membership cards, no census... We welcome everyone. So we have no way of instituting democratic institutions. they are definitely not a representative sampling of the overall community. Making language decisions based on the vocal support of JSConf alone is not sufficient. I can only repeat what I said before. There's no magic way to figure out accurately what most people want. The best we can do is publicize, solicit feedback, discuss, and make a decision. As we have always done. I was merely responding to Andrew's insinuation that the majority of the community (including him) had already voiced support for -. You have no way of knowing Andrew was insinuating that. I saw only the eminently reasonable point that we will never be able to please everyone, and will have to *try* to please as many people as possible. I take issue with the assertion that shorter==better unequivocally. I don't know whether anyone actually made that assertion. But in the case of function literals, there is a *ton* of precedent for languages with very concise syntax, and lots of experience to show that the conciseness is a win here. From the tone of this thread, and from many other recent postings regarding reactions from JSConf this week, it sounded like all of a sudden we'd gone from yeah coffeescript has some interesting short-hand syntax to the community has spoken, and coffeescript will be adopted into ES.Harmony/Next as-is. Hey, take a deep breath. 1) If you read the draft strawman, you'll see it's not exactly the same as the CoffeeScript syntax. 2) Brendan has been describing a strawman he is proposing at the next face-to-face meeting. 3) The strawman has not yet been promoted to Harmony status. 4) We *always* go to great pains to make it clear that nothing is final until the standard has been approved, which is slated for 2013. So even if it were at Harmony status, it wouldn't be final. You're reading into perceived tone and insinuation (your words) things that are directly contradicted by verifiable facts. Syntax discussions are difficult and controversial. If you want to contribute productively, please assume good faith on the part of your interlocutors. I think you'll find the assumption holds up. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Since there's a call for developer feedback, I'll give mine.
Brendan once said JS is a curly-brace language and it always will be. I
think the - looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep #(x) { x * x }.
I also think familiarity should be considered and that #(x) { x * x } would
be more familiar to the casual JS programmer.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
David,
Thanks for those clarifying points, much appreciated.
From an academic perspective, I'm also curious about the change from # to -gt;
To be honest, # always seemed weird to me, but I welcome a shortened syntax
regardless
Rick
-- Sent from my Palm Pre
On May 7, 2011 8:18 PM, Juan Ignacio Dopazo lt;dopazo.j...@gmail.comgt;
wrote:
Since there's a call for developer feedback, I'll give mine.
Brendan once said JS is a curly-brace language and it always will be. I think
the -gt; looks works very nice with a pythonic-like forced indentation like
Coffeescript has. However, I believe # looks better with curly braces, so I'd
keep #(x) { x * x }.
I also think familiarity should be considered and that #(x) { x * x } would be
more familiar to the casual JS programmer.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
It has been my experience that professional JavaScripters will cheer
*any* idea that shortens the spelling of function and return :)
Brendan has said that 8 characters for function is at least 6 too
many. I think it's probably at least 7 too many. But it'd be a shame
to remove the character-count-tax only to introduce a
twisting-wrist-tax. I'd prefer something closer to the middle of
(most) keyboards than - or {|. #() is pretty nice, actually.
When I suggested doing away with blocks, I of course was not
referring to structures where the block is relevant, such a function
bodies, if/else, try/catch/finally, or loops. I was talking about
having a bare unadorned block in JavaScript. These are relevant in C,
where you have block-scope, but in JavaScript have only made it
trickier to know whether something is supposed to be an Object-literal
or a block with labelled lines. For example:
return {
foo: bar
}
// vs
return
{
foo: bar
}
On Sat, May 7, 2011 at 14:39, Claus Reinke claus.rei...@talk21.com wrote:
function bodies extend as far as possible **
I see. So, a function body would be just like an if-block or loop
body. One full statement, or a block. There is precedent for that in
the rest of the language. So, then, this case:
x = function () y; z
would be:
x = function () { return y }; z
am I understanding that correctly?
--i
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
they are definitely not a representative sampling of the overall
community. Making language decisions based on the vocal support of JSConf
alone is not sufficient.
I can only repeat what I said before. There's no magic way to figure out
accurately what most people want. The best we can do is publicize, solicit
feedback, discuss, and make a decision. As we have always done.
OK, it's fair to point out that an attempt is being made. I'm asking though
for the resulting evidence from that attempt. As far as I can tell (and
please correct me if I'm wrong), there's been a few discussions on some
rather-esoteric lists/threads, like es-discuss, a few strawmans, and some ad
hoc presentations as JSConf. If there's a signficant medium of exchange of
opinions and ideas about topics that I'm NOT listing there, please do tell
me. I like to think I keep on the pulse of the JS community (generally
speaking), and so I'm anxious to hear if and how I'm missing out.
If OTOH those few mediums do constitute the breadth of community opinion
solicitation thus far regarding specifically the matters of these
coffeescript shorthands, as I was previously inclined to believe, then my
original assertion stands, that this doesn't constitute, in my opinion,
enough of the broader perspectives on what is and is not useful and readable
JavaScript. With all due respect, Brendan's personal tastes on what kind of
code he likes to write is not enough. It has to be something that is likely
to find wide spread support among the JavaScript masses.
And if we're looking for any kind of guide as to what they might like
(because we cannot scientifically poll all of them, obviously), then might I
suggest that the community that's grown up around jQuery (and its associated
projects, plugin ecosystem, etc) is a place to start. I am not in any way
suggesting jQuery is the only style of code out there, by any means. But it
clearly represents a wide swath of how JavaScript developers are currently
using the language. And jQuery is unique enough in its syntactic
eccentricities (its chaining, etc) that it may offer some insights.
To the extent that jQuery syntax encourages people to take shortcuts, it
could be seen as support for shorter syntax. And to the extent that jQuery
uses lots of anonymous functions, it could be seen as an opportunity to
shorten all that function soup.
But, by the same token, jQuery preserves verbosity in some places for
readability sake. For instance, event names are known by their full
canonical names, rather than by some shorthand (similarly with attribute and
property names). I can say as many times as I write `click(...)` or
`bind(click...)`, I could see where `c` or `clk` might be nice to have, to
save on all that typing. But, it would probably be for a loss of readability
and semantics of the code.
So there has to be a careful balance struck between shortness and
readability. I think at least a few of us are saying that we're skeptical
that - is sufficiently readable and semantic, compared to function(){} or
#(){}. The same goes for the loss of `return`... Having `return` in there is
a good thing, I think, because it makes it clear what's being returned. I
often write complex functions with internal branching logic, where there's
more than one `return` statement, and so it scares me to think how I could
inspect and understand such code as readily/easily if the `return` was
implicit, for instance, only the last evaluated expression, etc.
I was merely responding to Andrew's insinuation that the majority of the
community (including him) had already voiced support for -.
You have no way of knowing Andrew was insinuating that. I saw only the
eminently reasonable point that we will never be able to please everyone,
and will have to *try* to please as many people as possible.
Andrew's original message (in part):
I'd want the committee to listen to all interested parties and try to pick
the solution that pleases the most people. That appears to be what's
happening here.
The phrase That appears to be what's happening here, following after the
committee...listen...pick sentence before, led me to believe that Andrew
was indicating that the movement to adopt Coffeescript-like shorthand was a
result of the committee *having already listened* and *having already
picked* a solution that most people agreed with. It was the implication of
this has already been happening I reacted to. If I misread it, I
apologize. But my interpretation was fueled strongly by half a dozen blog
posts and dozens of tweets from JSConf and post-JSConf which seemed to
suggest that this stuff was already basically a done-deal.
I take
Re: arrow syntax unnecessary and the idea that function is too long
Kyle Simpson get...@gmail.com Date: Sat, 7 May 2011 21:58:32 -0500 Subject: Re: arrow syntax unnecessary and the idea that function is too long snip With all due respect, Brendan's personal tastes on what kind of code he likes to write is not enough. It has to be something that is likely to find wide spread support among the JavaScript masses. Since the arrow syntax assailants have been quite vocal on this list, lest they be construed as representative of the javascript masses, I would like to voice a strong endorsement for pursuing and exploring the arrow syntax further - and I do this as a simple javascript hobbyist who uses javascript (and JQuery, for lack of the perfect library) extensively to automate tasks on windows (via htas) and to write RIAs. With all due respect to Mr. Simpson's personal tastes, I find the aesthetics of the arrow-syntax far more consistent with javascript's C-based-syntactic roots than the preprocessor-tainted '#' - but I also recognize that my personal aesthetic tastes are just that. Anyway, I hope that enough general users share my aesthetic and usability preference (short syntax for functionally well behaved and intuitive lambdas with closure capability) that the arrow syntax is given some serious thought and not dismissed because of this thread. Thanks! Faisal Vali ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
Le 07/05/2011 02:04, Peter Michaux a écrit :
I'd like to ask when is function too long? I never type it thanks to
my text editor's features so I know it is not too long for developers
with a good editor.
What editor are you using? I have always been disappointed in my
experience with IDEs and JavaScript integration and would be glad to
know what people use for JavaScript (I'm actually asking the question to
everyone).
I'm attracted to the idea of a shorter function syntax not only because
it reduces the number of characters of the function keyword, but also
because it gets rid of the return keyword (and corresponding semicolon).
The particular case where I would enjoy shorter syntax is when using
inlined functions in array extras.
// assuming a is an array
a.filter( (e)-(typeof e === number e3) )
.map( (e)-(e*e) )
.reduce( (prev, curr)-(prev+curr), 0);
This is obviously extremely subjective, I admit. And there is no right
or wrong answer/opinion, it's really a matter of taste.
I actually prefer the idea of the # notation, because it looks more
like a function with its brackets ({ and }) while in my example,
without any help of syntax highlighting, the reader can easily get lost
in nested parenthesis. Same example with #:
// assuming a is an array
a.filter( #(e){typeof e === number e3} )
.map( #(e){e*e} )
.reduce( #(prev, curr){prev+curr}, 0);
This looks more clear to me. But once again, this is very subjective.
Your message seems to assume that the choice of providing a shorter
syntax is to help JS code writer. I have the opposite opinion: a shorter
syntax should be introduced to help code readers.
In most cases I have seen for array extras functions, the function has
only one return statement. While reading the code, having the function
inlined avoids to look for the function in some other place in the code
and getting rid of a dozen character makes the line shorter without
introducing ambiguity.
My two cents,
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 6, 2011, at 5:04 PM, Peter Michaux wrote:
The only possible category is be a better language but the arrow
syntax won't make JavaScript a better language for complex
applications or libraries in comparison to any other kind of
JavaScript code.
Usability is always on the top three lists of programming language success
factors. 'function' and 'return' are too long.
I would argue that the arrow syntax will make
JavaScript a worse language anyway as there are already perfectly good
forms using the function keyword now.
Eight characters is at least six too many.
We don't need new syntax and
we don't need multiple ways to do the same thing just for the sake 6
Wrong, 14. You are not counting 'return'.
characters. Please keep JavaScript simple.
Sorry, this is a bogus argument. Simple does not mean fewest productions in
all possible grammars or fewest ways of saying any given sentence. That is
simpler by some measures, more complex by others. In particular, writing and
(lesser but still material) reading 'function' over and over is not a win.
Consider the destructuring object shorthand: let {x, y} = pt; instead of let
{x:x, y:y} = pt;
Look at all the complex/subtle edge cases mentioned in the wiki page
about arrow function syntax. Do we really want to have that much
trickiness added to the language?
The wiki page is a work in progress. I have updates coming, which should
address the parenthesization burden. But again, you can use 14 characters if
you want. This is shorthand, and only shorthand. And usability counts, so
shorthands are in Harmony (e.g., destructuring)
Gzip is not the issue (although stats I've seen from Steve Souders show too may
scripts not being compressed at the Transfer-encoding layer). Human usability
is.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 6:39 PM, Brendan Eich bren...@mozilla.com wrote: But again, you can use 14 characters if you want. The problem is that the author of the code that I'm reading may have used the arrow syntax and then I'm stuck reading it. This is shorthand, and only shorthand. And usability counts, so shorthands are in Harmony (e.g., destructuring) Yes and readability counts. JavaScript's function syntax is already *highly* usable and readable. Having many ways to write the same thing is a burden to readers of code because they have to know a larger set of forms and all of the gotchas that come along with them. A lot of languages have a lot of cool syntax and then the communities come up with best practices that prohibit the use of them anyway often for reasons only discovered after their introduction. My hunch is that arrow syntax will be one of these cases. JavaScript can use attention in many of areas. Devoting time to adding sugary function syntax seems like a misappropriation of resources. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On May 7, 2011, at 12:42 AM, Peter Michaux wrote: Yes and readability counts. JavaScript's function syntax is already *highly* usable and readable. Many people, including me, would disagree. On matters of taste, I'd want the committee to listen to all interested parties and try to pick the solution that pleases the most people. That appears to be what's happening here. Cheers, Andrew ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
