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 useles
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
impor
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' elimin
this route.
From: Claus Reinke
To: Kam Kasravi ; Brendan Eich
Cc: es-discuss
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, partiall
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 par
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.e
From: Brendan Eich
To: Claus Reinke
Cc: es-discuss
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 par
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=s
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-h
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:
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 in
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/obj
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 forma
On May 19, 2011, at 2:42 AM, Lasse Reichstein wrote:
Hi Lasse.
> On Wed, 11 May 2011 02:44:30 +0200, Brendan Eich 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, th
On Wed, 11 May 2011 02:44:30 +0200, Brendan Eich
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 express
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 to
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
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
On Tue, May 17, 2011 at 10:50 AM, Axel Rauschmayer wrote:
> On May 17, 2011, at 4:57, Peter Michaux 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
On May 17, 2011, at 4:57, Peter Michaux 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 compiler
On May 16, 2011, at 7:55 PM, Peter Michaux wrote:
> On Mon, May 9, 2011 at 6:02 PM, Brendan Eich 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
On Mon, May 9, 2011 at 6:02 PM, Brendan Eich 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 chang
On 16.05.2011 1:47, Brendan Eich wrote:
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
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 ch
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 a
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]
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 con
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)
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 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
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(),
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 M
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-ob
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
l
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
> FormalParamete
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
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,
specifi
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.
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 Cal
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
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
On May 11, 2011, at 12:55 AM, Erik Corry wrote:
> 2011/5/10 Oliver Hunt :
>> 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
2011/5/10 Oliver Hunt :
> 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
if (a)->x is going to be a function that doesn't capture 'this', I'd
prefer (a)+>x for capturing 'this'. they're visually distinct,
somewhat mnemonic, about equally easy/hard to type.
On Tue, May 10, 2011 at 17:44, Brendan Eich wrote:
> On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:
>
>> On
On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:
> On Tue, May 10, 2011 at 16:22, Oliver Hunt 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 stil
On Tue, May 10, 2011 at 16:22, Oliver Hunt 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.
> I'm also really not happy with the concept of minor variances in syntax
On May 10, 2011, at 4:06 PM, Andrew Dupont wrote:
> 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 advant
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
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
On 5/10/11, Oliver Hunt 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
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 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 i
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, exce
bject: Re: arrow syntax unnecessary and the idea that "function" is too
>>> long
>>
>>
>>
>>> With all due respect, Brendan's personal tastes on what kind of code he
>>> likes to write is not enough.
>>> It has to be somethin
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 i
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 6, 2011, at 11:22 PM, Peter Michaux wrote:
> On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont
> 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
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 };
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
Andrew Dupont 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 m
On Mon, May 9, 2011 at 10:40, Kyle Simpson 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 lit
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
(...)
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 prett
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:
functi
On Sunday, 2011-05-08 at 20:48 , Peter Michaux wrote:
On Sun, May 8, 2011 at 11:34 AM, Irakli Gozalishvili 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
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 ambig
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
purp
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 wr
On May 8, 2011 8:34 PM, "Irakli Gozalishvili" wrote:
>
> 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 li
On Sun, May 8, 2011 at 11:34 AM, Irakli Gozalishvili 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 Coffeescri
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 p
On Sat, May 7, 2011 at 4:17 PM, David Herman 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 t
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 Sun, May 8, 2011 at 4:04 AM, Jorge 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* d
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
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 5/7/11, Faisal Vali wrote:
>> "Kyle Simpson"
>> Date: Sat, 7 May 2011 21:58:32 -0500
>> Subject: Re: arrow syntax unnecessary and the idea that "function" is too
>> long
>
>
>
>> With all due respect, Brendan's personal taste
yhow, right?
On Sat, May 7, 2011 at 20:52, Faisal Vali wrote:
>> "Kyle Simpson"
>> Date: Sat, 7 May 2011 21:58:32 -0500
>> Subject: Re: arrow syntax unnecessary and the idea that "function" is too
>> long
>
>
>
>> With all due respect,
> "Kyle Simpson"
> Date: Sat, 7 May 2011 21:58:32 -0500
> Subject: Re: arrow syntax unnecessary and the idea that "function" is too long
> With all due respect, Brendan's personal tastes on what kind of code he likes
> to write is not enough.
> 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
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 characte
David,
Thanks for those clarifying points, much appreciated.
>From an academic perspective, I'm also curious about the change from # to ->
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 Ignac
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
> 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
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,
> 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
>
> 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.
Proper tail calls are *already* in Harmony and totally orthogonal to the
question of new function syntax.
Dave
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 n
On Sat, May 7, 2011 at 1:04 PM, Peter Michaux 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
On 5/7/11, Isaac Schlueter 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
___
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
On Sat, May 7, 2011 at 9:56 AM, Thaddee Tyl 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
On Sat, May 7, 2011 at 6:31 PM, Peter Michaux wrote:
> On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl 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 "
On Sat, May 7, 2011 at 6:04 AM, Sam Tobin-Hochstadt wrote:
> On Sat, May 7, 2011 at 2:22 AM, Peter Michaux 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
On Sat, May 7, 2011 at 2:22 AM, Peter Michaux 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 tim
ear 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
Sub
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
On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont 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 func
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
j
On Fri, May 6, 2011 at 10:49 PM, Andrew Dupont 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 read
1 - 100 of 105 matches
Mail list logo
