Re: optional "function" keyword

So, assuming that these two are valid function expressions that mean roughly the same thing: a: (x) { return "x" } b: function (x) "x" and then you might conclude that this is as well: c: (x) "x" So far, so good, I think. What about these? d: (x) (y) e: (x) (y) { return

Re: optional "function" keyword

I think we can use a modification of the Dart technique to parse "=>" functions: On encountering "(" in a context where an expression is acceptable, you can try to parse it as ( Expression ) or as ( FormalParameterList ). Attempt to parse it as a formal parameter list, enqueuing each token encoun

Re: is is odd and so is this isOdd

http://www.youtube.com/watch?v=Xm_7FLKRS4Y Dave On Mar 8, 2012, at 2:23 PM, Andreas Rossberg wrote: > Today, I came up with this odd way to implement an isOdd predicate in > tentative ES6, and thought I share it: > > function isOdd(n) { > let is = n isnt n; > return eval(Array(2 * n).join("is

Re: is is odd and so is this isOdd

On Thu, Mar 8, 2012 at 5:23 PM, Andreas Rossberg wrote: > Today, I came up with this odd way to implement an isOdd predicate in > tentative ES6, and thought I share it: > > function isOdd(n) { > let is = n isnt n; > return eval(Array(2 * n).join("is ") + "is") > } > That looks fun - I like seei

Re: Mutable array methods

On Thu, Mar 8, 2012 at 12:19 PM, David Bruant wrote: > Le 08/03/2012 18:02, Maël Nison a écrit : > > Shouldn't native versions be more efficients ? >> > I heard V8 is on the path of self-hosting (writing standard functions in > JavaScript itself) as much as it can (can anyone confirm?). > Confi

is is odd and so is this isOdd

Today, I came up with this odd way to implement an isOdd predicate in tentative ES6, and thought I share it: function isOdd(n) { let is = n isnt n; return eval(Array(2 * n).join("is ") + "is") } :) /Andreas ___ es-discuss mailing list es-discuss@mo

Re: system module loader

2012/3/8 David Herman : > On Mar 8, 2012, at 9:27 AM, Mike Samuel wrote: >> Has the behavior of the system module loader been speced at all? > > Not really. The plan is to leave it mostly unspecified; it's sort of the > "Pineal gland" of ES6 [1], so most of the questions of how it interacts with

Re: optional "function" keyword

Thanks for the clear explanation, Brendan - I think I understand the concerns now. And if not, I don't mind looking foolish : ) I just looked at the code for the Dart parser and it basically queues tokens until it finds the matching right paren (recursively counting nested parens). It peeks at w

Re: optional "function" keyword

I forgot to mention that the call to () do {...} should work as written in 11.1.7 in block_lambda_revival (if not my second example does not work), so the behavior is supposed to be the same (if [[FormalParameters]] is empty), I was more focused on the "this" stuff (do examples 1 and 3 look use

Re: optional "function" keyword

On Thu, Mar 8, 2012 at 1:08 PM, Brendan Eich wrote: > Another which I cited just a few messages back: parsing ( params ) as ( > expr ), as any top down parser must until it gets to an arrow or other > distinguishing token ({ on same line as ), e.g.), can be considered > future-hostile. params sho

Re: Native JSON loading

Le 08/03/2012 18:42, Wes Garland a écrit : > > What about native JSON loading? > > How would this be different from XHR + JSON.parse() sugar? I think it wouldn't. Loading rules applied for module loading would be applied to JSON loading. > Are you proposing loading the JSON from the server as thou

Re: system module loader

On Mar 8, 2012, at 9:27 AM, Mike Samuel wrote: > http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions > a system module loader. > > Has the behavior of the system module loader been speced at all? Not really. The plan is to leave it mostly unspecified; it's sort of the "Pineal

Re: optional "function" keyword

Aymeric Vitte wrote: Indeed it looks more intuitive than block lambdas (IMHO). Intuitions vary, but why does function huh(a, b) { let toss = () do{return a*b}; downward(toss); return 42; } where downward, if it calls its argument, forces a return of a*b from huh, and control never reac

Re: optional "function" keyword

Then you really have three somewhat modest proposals: 1. optional "function". 2. braceless functions that auto-return the completion value of the expression and exhibit TCP freakdeekness. 3. do-expressions blocks that evaluate to their completion value. These three seem to combine to let you do

Re: optional "function" keyword

Kevin Smith wrote: If I understand correctly, it's still an open question whether parsing () => {} is feasible or not using a recursive top-down parser. Is that right? No. Top down parsers can be hacked to do a great many things. What we seek is a grammar that can be parsed by a well-establi

Re: optional "function" keyword

IIRC, "fn" for functions (as a breaking change) was in the running, at some point. Is it still? On Mar 8, 2012, at 18:59 , Brendan Eich wrote: > Russell Leggett wrote: >> >>Bound this would be nice, since it is a new form that can't break >>existing code. >> >> >> Yes - I think this c

Re: optional "function" keyword

Russell Leggett wrote: Bound this would be nice, since it is a new form that can't break existing code. Yes - I think this could be pretty excellent - no pun intended. I think think it would be a great compromise between current functions and full TCP. Again, it's a bad idea to mix

Re: Mutable array methods

Maël Nison wrote: Shouldn't native versions be more efficients ? No, as David wrote. Also, it doesn't matter until it matters. There has been little (none to my knowledge until your post) evolutionary pressure or demand for mutating extras. Let's see a popular library or three first, then pa

Re: Native JSON loading (was: system module loader)

> What about native JSON loading? How would this be different from XHR + JSON.parse() sugar? Are you proposing loading the JSON from the server as though it were a module? FWIW, most of my JSON-loading use cases are post-page-load, they are of the "fetch some data from the server based on user

Native JSON loading (was: system module loader)

Le 08/03/2012 18:27, Mike Samuel a écrit : http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions a system module loader. Has the behavior of the system module loader been speced at all? If not, would it be worthwhile specifying that when it loads an http or https URL, it does s

system module loader

http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions a system module loader. Has the behavior of the system module loader been speced at all? If not, would it be worthwhile specifying that when it loads an http or https URL, it does so with a fairly minimal Accept header that ex

Re: Mutable array methods

Le 08/03/2012 18:02, Maël Nison a écrit : Shouldn't native versions be more efficients ? I heard V8 is on the path of self-hosting (writing standard functions in JavaScript itself) as much as it can (can anyone confirm?). It seems that in some cases, there is actually no benefit in writing in

Re: Mutable array methods

Shouldn't native versions be more efficients ? On 8 March 2012 17:45, David Bruant wrote: > Le 08/03/2012 13:02, Maël Nison a écrit : > >> Hi, >> >> I'm just wondering why there is no mutable function with Javascript >> arrays. >> >> For exemple, if I want to remove every entry matching 42 from

Re: optional "function" keyword

If I understand correctly, it's still an open question whether parsing () => {} is feasible or not using a recursive top-down parser. Is that right? kevin On Thu, Mar 8, 2012 at 10:46 AM, Russell Leggett wrote: > Bound this would be nice, since it is a new form that can't break existing >> code

Re: Mutable array methods

Le 08/03/2012 13:02, Maël Nison a écrit : Hi, I'm just wondering why there is no mutable function with Javascript arrays. For exemple, if I want to remove every entry matching 42 from an array, I will have to write something like : > var array = [ 0, 1, 42, 3, 4, 5, 42, 42, 42 ]; > array =

Re: optional "function" keyword

> > Bound this would be nice, since it is a new form that can't break existing > code. > Yes - I think this could be pretty excellent - no pun intended. I think think it would be a great compromise between current functions and full TCP. - Russ > > -- > John A. Tamplin > Software Engineer (GWT)

Re: optional "function" keyword

On Wed, Mar 7, 2012 at 8:31 PM, Kevin Smith wrote: > // Or > () => expr > You don't need TCP here, since there is no return. Bound this would be nice, since it is a new form that can't break existing code. -- John A. Tamplin Software Engineer (GWT), Google

Re: optional "function" keyword

I don't see ambiguity on (){} but as I have said it was only a test. I'd like to know what kind of code could brake it thought :-) On Thu, Mar 8, 2012 at 3:41 PM, Russell Leggett wrote: > On Thu, Mar 8, 2012 at 9:35 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> I was thinkin

Re: optional "function" keyword

On Thu, Mar 8, 2012 at 9:35 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > I was thinking and playing with something similar ... here an example: > http://www.3site.eu/functionize/ > > Looks like the "function" keyword could actually be dropped easily without > compromising the synt

Re: optional "function" keyword

I was thinking and playing with something similar ... here an example: http://www.3site.eu/functionize/ Looks like the "function" keyword could actually be dropped easily without compromising the syntax too much. That is just a test, but it looks OKish to me br __

Re: The result of (0).toExponential(1)

I don't think so. ES5 specified the algorithm of toExponential. “The number is the same” is not the only requirement. See the algorithm below: ( please pay attention to 8.a ) 1. Let *x* be this Number value . 2. Let *f* be ToInteger

Re: optional "function" keyword

Thank you for the explanations. Block lambda syntax with pipes makes more sense to me now. Given that most of the stuff I do is asynchronous though, I personally would prioritize the semantics this way: 1. Short function syntax with lexical this. 4. Block lambdas with TCP return. Thanks again

Re: optional "function" keyword

On Thu, Mar 8, 2012 at 8:43 AM, Herby Vojčík wrote: > > > Russell Leggett wrote: > >> Its mostly about being able to make control abstractions - being able to >> make your own loops, conditionals, DSLs - and while you can get close >> with anonymous functions, you'll never get there, because some

Re: optional "function" keyword

Russell Leggett wrote: Its mostly about being able to make control abstractions - being able to make your own loops, conditionals, DSLs - and while you can get close with anonymous functions, you'll never get there, because someone will want to use 'return' or 'break' or 'throw' and the behavio

Re: optional "function" keyword

Its mostly about being able to make control abstractions - being able to make your own loops, conditionals, DSLs - and while you can get close with anonymous functions, you'll never get there, because someone will want to use 'return' or 'break' or 'throw' and the behavior is all screwed up (as we

Re: optional "function" keyword

(Slightly off topic...) In Yehuda Katz's examples (one of which I quoted) he's doing synchronous file stuff. Which we don't really do in javascript. Since so much of the code we write is asynchronous it seems like TCP return semantics are not really applicable. Or are they? Thanks, kevin On W

Mutable array methods

Hi, I'm just wondering why there is no mutable function with Javascript arrays. For exemple, if I want to remove every entry matching 42 from an array, I will have to write something like : > var array = [ 0, 1, 42, 3, 4, 5, 42, 42, 42 ]; > array = array.filter( function ( x ) { return x === 42;

Re: The result of (0).toExponential(1)

On H.24/03/08, at 12:39, DX Jin wrote: > (0).toExponential(1) should, according to the algorithm in 15.7.4.6, return > "0e+0". > > But all browser implementations return "0.0e+0" instead. > > Which is wrong? The specification or the implementations? Neither, the result is correct. The number

The result of (0).toExponential(1)

(0).toExponential(1) should, according to the algorithm in 15.7.4.6, return "0e+0". But all browser implementations return "0.0e+0" instead. Which is wrong? The specification or the implementations? ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: optional "function" keyword

Claus Reinke wrote: *If* it is possible to make 'function'-free functions work, then how about dropping the implicit bindings for 'arguments' and 'this' for the short form? Then the 'function' keyword would be a modifier on the short form, to re-introduce these implicit bindings. That would suppo

Re: optional "function" keyword

Another lingering objection to arrows is this-binding (=> vs. ->). *If* it is possible to make 'function'-free functions work, then how about dropping the implicit bindings for 'arguments' and 'this' for the short form? Then the 'function' keyword would be a modifier on the short form, to re-int