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
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
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
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
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!
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
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
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
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
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
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
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'
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
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
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
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
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
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
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.
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
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
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
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,
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,
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
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
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
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
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(),
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
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); //
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)
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
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
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
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
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
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
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
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
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
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,
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
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.
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
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
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:
(...)
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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
94 matches
Mail list logo
