Re: Self-recursion and arrow functions

2013-03-17 Thread Rick Waldron 
On Sun, Mar 17, 2013 at 9:50 PM, Matthew Robb wrote:

> I know I am late to this party and I am not sure how serious it even is
> but can someone help me understand why function expressions require
> anything special to denote the fact that it's a function?
>
> `
> requestAnimationFrame(onFrame(time) { })
>

The parser would need to tokenize the input until it reached the "{" to
determine whether the input was an PrimaryExpression or FunctionExpression.



> `
>
> The following seems a pretty convenient side benefit:
>
 `
> let onFrame(){}
> const onFrame(){}
> var onFrame(){}
>

This has appeared before, thread starts here:
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008218.html



> function onFrame(){}
>

This is a FunctionDeclaration, nothing new here.


Rick
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Rick Waldron 
On Sun, Mar 17, 2013 at 9:54 PM, Jorge Chamorro wrote:

> On 18/03/2013, at 01:49, Rick Waldron wrote:
>
> > snip
> > ...and Brendan's point about backwards compatibility is irrefutable:
> >
> > https://mail.mozilla.org/pipermail/es-discuss/2012-January/019860.html
> > snip
>
> How is
>
> ƒ fib(n) { ... }
>

ƒ is not a reserved word, so the following is valid today:

> var ƒ = 1
> ƒ
1

...Which means any code that exists (maybe there is none, but that's not
really the point) will be broken.


> any more backwards incompatible than
>
> const fib = (n) => { ... };
>

const is a reserved word, so the following is a SyntaxError today, which
means it can be "safely" rolled out without breaking code that already
exists:

> var const = 1;
SyntaxError: Unexpected token const


Although, I think François Remy's argument is the most compelling.

Arrow has had consensus for a long time now and is already in the ES6 spec
draft—it's here to stay.

Rick


> ?
> --
> (Jorge)();
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Jorge Chamorro 
On 18/03/2013, at 01:49, Rick Waldron wrote:

> snip
> ...and Brendan's point about backwards compatibility is irrefutable:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019860.html
> snip

How is

ƒ fib(n) { ... }

any more backwards incompatible than

const fib = (n) => { ... };

?
-- 
(Jorge)();
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Matthew Robb 
I know I am late to this party and I am not sure how serious it even is but
can someone help me understand why function expressions require anything
special to denote the fact that it's a function?

`
requestAnimationFrame(onFrame(time) { })
`

The following seems a pretty convenient side benefit:
`
let onFrame(){}
const onFrame(){}
var onFrame(){}
function onFrame(){}
`

I feel like there must be something obviously impossible about this that I
am not considering.


On Sun, Mar 17, 2013 at 5:49 PM, Rick Waldron wrote:

>
>
>
> On Sun, Mar 17, 2013 at 7:10 PM, Jorge Chamorro 
> wrote:
>
>> On 17/03/2013, at 14:33, Mark S. Miller wrote:
>>
>> > Just in case anyone does not realize that this thread is humorous,
>> >
>> > const factorial = n => n>1 ? n*factorial(n-1) : 1;
>> >
>> > Yes, you can't use this as an expression. So what? After this
>> declaration you can use factorial as an expression.
>>
>> IIRC the possibility of *simply* using 'ƒ' (instead of 'function') for
>> lambdas, which is a syntax that's immediately familiar to any JS developer:
>>
>> [1,2,3,4,5,6].map(ƒ factorial(n) { n>1 ? n*factorial(n-1) : 1 });
>>
>
> This road is a dead end—previously proposed by Axel last year and Brendan
> 3 years ago (I can't spend anymore time going further back to see if it
> appeared prior to that)
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019852.html
>
>  ...which you backed:
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019857.html
>
> ...but François Remy's concerns still stand:
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019864.html
>
> ...and Brendan's point about backwards compatibility is irrefutable:
>
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019860.html
>
>
> As promised, three years ago, Brendan proposes here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2010-April/011010.html
>
> And kills it himself here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2010-April/011034.html
>
>
>
>
> snip
>
>
>> But Brandon Benvie was pointing out at the problem: "Relying on the
>> defined name they're assigned to suffers from the "can be redefined"
>> problem":
>>
>> var factorial= (n)=> n>1 ? n*factorial(n-1) : 1;
>>
>
> use const?
>
>
>
>>
>> The factorial lambda above depends on a free var to function properly
>> which is a hazard.
>>
>> It never ocurred to me that using const instead of var/let as you've done
>> above fixes that, thank you!
>>
>> Still, ƒ named lambdas have the advantage that can be used directly as
>> expressions, without going through any const roundabouts.
>>
>
> But they aren't part of ES6 and Arrow Functions are; if you need a named
> function expression, then use a named function expression, they aren't
> going anywhere.
>
>
> Rick
>
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Matthew Robb
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Rick Waldron 
On Sun, Mar 17, 2013 at 7:10 PM, Jorge Chamorro wrote:

> On 17/03/2013, at 14:33, Mark S. Miller wrote:
>
> > Just in case anyone does not realize that this thread is humorous,
> >
> > const factorial = n => n>1 ? n*factorial(n-1) : 1;
> >
> > Yes, you can't use this as an expression. So what? After this
> declaration you can use factorial as an expression.
>
> IIRC the possibility of *simply* using 'ƒ' (instead of 'function') for
> lambdas, which is a syntax that's immediately familiar to any JS developer:
>
> [1,2,3,4,5,6].map(ƒ factorial(n) { n>1 ? n*factorial(n-1) : 1 });
>

This road is a dead end—previously proposed by Axel last year and Brendan 3
years ago (I can't spend anymore time going further back to see if it
appeared prior to that)

https://mail.mozilla.org/pipermail/es-discuss/2012-January/019852.html

...which you backed:

https://mail.mozilla.org/pipermail/es-discuss/2012-January/019857.html

...but François Remy's concerns still stand:

https://mail.mozilla.org/pipermail/es-discuss/2012-January/019864.html

...and Brendan's point about backwards compatibility is irrefutable:

https://mail.mozilla.org/pipermail/es-discuss/2012-January/019860.html


As promised, three years ago, Brendan proposes here:

https://mail.mozilla.org/pipermail/es-discuss/2010-April/011010.html

And kills it himself here:

https://mail.mozilla.org/pipermail/es-discuss/2010-April/011034.html




snip


> But Brandon Benvie was pointing out at the problem: "Relying on the
> defined name they're assigned to suffers from the "can be redefined"
> problem":
>
> var factorial= (n)=> n>1 ? n*factorial(n-1) : 1;
>

use const?



>
> The factorial lambda above depends on a free var to function properly
> which is a hazard.
>
> It never ocurred to me that using const instead of var/let as you've done
> above fixes that, thank you!
>
> Still, ƒ named lambdas have the advantage that can be used directly as
> expressions, without going through any const roundabouts.
>

But they aren't part of ES6 and Arrow Functions are; if you need a named
function expression, then use a named function expression, they aren't
going anywhere.


Rick
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Jorge Chamorro 
On 17/03/2013, at 14:33, Mark S. Miller wrote:

> Just in case anyone does not realize that this thread is humorous, 
> 
> const factorial = n => n>1 ? n*factorial(n-1) : 1;
> 
> Yes, you can't use this as an expression. So what? After this declaration you 
> can use factorial as an expression.

IIRC the possibility of *simply* using 'ƒ' (instead of 'function') for lambdas, 
which is a syntax that's immediately familiar to any JS developer:

[1,2,3,4,5,6].map(ƒ factorial(n) { n>1 ? n*factorial(n-1) : 1 });

and could also give us anonymous and named lambdas that can be used à la 
'function' function:

A lambda declaration: ƒ factorial(n) { n>1 ? n*factorial(n-1) : 1 }

A named lambda expression: (ƒ factorial(n) n>1 ? n*factorial(n-1) : 1)(5);

Anonymous lambdas:

[1,2,3,4,5,6].map(ƒ(n) n*2);  //ƒ lambdas are even shorter than arrow functions
[1,2,3,4,5,6].map((n)=> n*2);

was being considered in the past, but we ended up with arrows instead. I for 
one liked ƒs much more than arrows because ƒ()... looks like a function much 
more than the grawlixy ()=>...

Now, given that ƒs could be created named or anonymous and used as expressions 
in any case, with ease, just like the regular functions can, perhaps ƒ-lambdas 
may deserve a reconsideration?

> Anonymous lambda expressions are a wonderful things. But in actual 
> development, I have never yet encountered a recursive function I didn't want 
> to name.

But Brandon Benvie was pointing out at the problem: "Relying on the defined 
name they're assigned to suffers from the "can be redefined" problem":

var factorial= (n)=> n>1 ? n*factorial(n-1) : 1;

The factorial lambda above depends on a free var to function properly which is 
a hazard.

It never ocurred to me that using const instead of var/let as you've done above 
fixes that, thank you!

Still, ƒ named lambdas have the advantage that can be used directly as 
expressions, without going through any const roundabouts.

> Ok, and now back to our irregularly scheduled humor...


-- 
(Jorge)();

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Axel Rauschmayer 
Nice (in an IIFE-kind of way). If we had `do` expressions, the following would 
also be possible (producing an expression that could be assigned anywhere and 
to anything):

do {let fact = n=>n>1 ?n*fact(n-1):1}

I’m assuming that the completion value of a let declaration is the rhs of the 
last assignment. Otherwise, `; fact` would have to be appended.

On Mar 17, 2013, at 19:24 , Allen Wirfs-Brock  wrote:

> I don't think anybody has yet exploited the power of parameter default values 
> for defining recursive functions:
> 
>((fact=n=>n>1 ?n*fact(n-1):1)=>(fact))()

-- 
Dr. Axel Rauschmayer
[email protected]

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Allen Wirfs-Brock 
I don't think anybody has yet exploited the power of parameter default values 
for defining recursive functions:

   ((fact=n=>n>1 ?n*fact(n-1):1)=>(fact))()

Allen


On Mar 17, 2013, at 7:39 AM, Axel Rauschmayer wrote:

> ;-)
> 
> How about the following (about which I’m serious)?
> 
> function defineRec(f) {
> return args => f(f, ...args);
> }
> 
> let factorial = defineRec((me, n) => n <= 1 ? 1 :  n * me(me, n-1))
> 
> 
> On Mar 17, 2013, at 14:33 , "Mark S. Miller"  wrote:
> 
>> Just in case anyone does not realize that this thread is humorous, 
>> 
>> const factorial = n => n>1 ? n*factorial(n-1) : 1;
>> 
>> Yes, you can't use this as an expression. So what? After this declaration 
>> you can use factorial as an expression. Anonymous lambda expressions are a 
>> wonderful things. But in actual development, I have never yet encountered a 
>> recursive function I didn't want to name.
>> 
>> Ok, and now back to our irregularly scheduled humor...
>> 
>> 
>> 
>> 
>> On Sun, Mar 17, 2013 at 6:19 AM, Kevin Smith  wrote:
>> 
>> 
>> Sorry arrow functions but this isn't a better JS.
>> 
>> Bah.  Arrow functions are a huge usability win for JS.  Try them- you'll see!
>> 
>> { Kevin } 
>> 
>> 
>> 
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>> Cheers,
>> --MarkM
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> -- 
> Dr. Axel Rauschmayer
> [email protected]
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Brandon Benvie 
This is probably the most humor I've ever seen on esdiscuss.

On Mar 17, 2013, at 6:33 AM, "Mark S. Miller"  wrote:

> Just in case anyone does not realize that this thread is humorous, 
> 
> const factorial = n => n>1 ? n*factorial(n-1) : 1;
> 
> Yes, you can't use this as an expression. So what? After this declaration you 
> can use factorial as an expression. Anonymous lambda expressions are a 
> wonderful things. But in actual development, I have never yet encountered a 
> recursive function I didn't want to name.
> 
> Ok, and now back to our irregularly scheduled humor...
> 
> 
> 
> 
> On Sun, Mar 17, 2013 at 6:19 AM, Kevin Smith  wrote:
>> 
>>> 
>>> Sorry arrow functions but this isn't a better JS.
>> 
>> Bah.  Arrow functions are a huge usability win for JS.  Try them- you'll see!
>> 
>> { Kevin } 
>> 
>> 
>> 
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
> Cheers,
> --MarkM
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Axel Rauschmayer 
;-)

How about the following (about which I’m serious)?

function defineRec(f) {
return args => f(f, ...args);
}

let factorial = defineRec((me, n) => n <= 1 ? 1 :  n * me(me, n-1))


On Mar 17, 2013, at 14:33 , "Mark S. Miller"  wrote:

> Just in case anyone does not realize that this thread is humorous, 
> 
> const factorial = n => n>1 ? n*factorial(n-1) : 1;
> 
> Yes, you can't use this as an expression. So what? After this declaration you 
> can use factorial as an expression. Anonymous lambda expressions are a 
> wonderful things. But in actual development, I have never yet encountered a 
> recursive function I didn't want to name.
> 
> Ok, and now back to our irregularly scheduled humor...
> 
> 
> 
> 
> On Sun, Mar 17, 2013 at 6:19 AM, Kevin Smith  wrote:
> 
> 
> Sorry arrow functions but this isn't a better JS.
> 
> Bah.  Arrow functions are a huge usability win for JS.  Try them- you'll see!
> 
> { Kevin } 
> 
> 
> 
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
[email protected]

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Mark S. Miller 
Just in case anyone does not realize that this thread is humorous,

const factorial = n => n>1 ? n*factorial(n-1) : 1;

Yes, you can't use this as an expression. So what? After this declaration
you can use factorial as an expression. Anonymous lambda expressions are a
wonderful things. But in actual development, I have never yet encountered a
recursive function I didn't want to name.

Ok, and now back to our irregularly scheduled humor...




On Sun, Mar 17, 2013 at 6:19 AM, Kevin Smith  wrote:

>
>
>> Sorry arrow functions but this isn't a better JS.
>>
>
> Bah.  Arrow functions are a huge usability win for JS.  Try them- you'll
> see!
>
> { Kevin }
>
>
>
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Kevin Smith 
>
> Sorry arrow functions but this isn't a better JS.
>

Bah.  Arrow functions are a huge usability win for JS.  Try them- you'll
see!

{ Kevin }
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Jorge Chamorro 
On 17/03/2013, at 12:16, Jason Orendorff wrote:

> On Sun, Mar 17, 2013 at 2:43 AM, Claus Reinke  wrote:
> Neither arguments.callee (not available in strict) nor let (clumsy to
> use in expressions) are needed for self-reference
> 
>var rec = (f) => f((...args)=>rec(f)(...args));
> 
>var f = (self)=>(n)=> n>1 ? n*self(n-1) : n;
> 
>[1,2,3,4,5,6].map((n)=>rec(f)(n));
> 
> ...but then you have a function rec which self-references. Much better to use 
> the Z combinator:
> 
> f => (x => f(v => x(x)(v)))(x => f(v => x(x)(v)))
> 
> which can be conveniently inlined into any expression where it's used:
> 
>   js> [1,2,3,4,5,6].map((n)=>(f => (x => f(v => x(x)(v)))(x => f(v => 
> x(x)(v(self => n => n>1 ? n*self(n-1) : n)(n));
>   [1, 2, 6, 24, 120, 720]
> 
> Obviously this is much better than arguments.callee.

:-)

And I want to tear out my eyes!
-- 
(Jorge)();
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Jason Orendorff 
On Sun, Mar 17, 2013 at 2:43 AM, Claus Reinke wrote:

> Neither arguments.callee (not available in strict) nor let (clumsy to
> use in expressions) are needed for self-reference
>
>var rec = (f) => f((...args)=>rec(f)(...args));
>
>var f = (self)=>(n)=> n>1 ? n*self(n-1) : n;
>
>[1,2,3,4,5,6].map((n)=>rec(f)(**n));
>

...but then you have a function rec which self-references. Much better to
use the Z combinator:

f => (x => f(v => x(x)(v)))(x => f(v => x(x)(v)))

which can be conveniently inlined into any expression where it's used:

  js> [1,2,3,4,5,6].map((n)=>(f => (x => f(v => x(x)(v)))(x => f(v =>
x(x)(v(self => n => n>1 ? n*self(n-1) : n)(n));
  [1, 2, 6, 24, 120, 720]

Obviously this is much better than arguments.callee.

-j
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Jorge Chamorro 
On 17/03/2013, at 10:43, Claus Reinke wrote:

>> I understand, but it's still a limitation of arrow functions that they rely
>> on arguments.callee to self-reference. Relying on the defined name
>> they're assigned to suffers from the "can be redefined" problem. NFE's
>> don't suffer this problem and can completely avoid `arguments` in ES6
>> for all use cases Arrow functions, currently, cannot.
> 
> Neither arguments.callee (not available in strict) nor let (clumsy to
> use in expressions) are needed for self-reference
> 
>   var rec = (f) => f((...args)=>rec(f)(...args));
> 
>   var f = (self)=>(n)=> n>1 ? n*self(n-1) : n;
> 
>   [1,2,3,4,5,6].map((n)=>rec(f)(n));


God, my eyes, they're bleeding!

Sorry arrow functions but this isn't a better JS.
-- 
(Jorge)();
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-17 Thread Claus Reinke 

I understand, but it's still a limitation of arrow functions that they rely
on arguments.callee to self-reference. Relying on the defined name
they're assigned to suffers from the "can be redefined" problem. NFE's
don't suffer this problem and can completely avoid `arguments` in ES6
for all use cases Arrow functions, currently, cannot.


Neither arguments.callee (not available in strict) nor let (clumsy to
use in expressions) are needed for self-reference

   var rec = (f) => f((...args)=>rec(f)(...args));

   var f = (self)=>(n)=> n>1 ? n*self(n-1) : n;

   [1,2,3,4,5,6].map((n)=>rec(f)(n));

You can try it out in traceur (example link at the bottom)

   http://traceur-compiler.googlecode.com/git/demo/repl.html

Claus

http://traceur-compiler.googlecode.com/git/demo/repl.html#var%20rec%20%3D%20(f)%20%3D%3E%20f((...args)%3D%3Erec(f)(...args))%3B%0A%0Avar%20f%20%3D%20(self)%3D%3E(n)%3D%3E%20n%3E1%20%3F%20n*self(n-1)%20%3A%20n%3B%0A%0A%5B1%2C2%2C3%2C4%2C5%2C6%5D.map((n)%3D%3Erec(f)(n))%3B



___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Jason Orendorff 
On Sat, Mar 16, 2013 at 4:53 PM, Brendan Eich  wrote:

> Jason Orendorff wrote:
>
>> Functions with default arguments have the same weird problem. You can
>> still do it in one pass, but you have to track "this
>> parameter-default-value-**expression contains code that would not be
>> allowed if the enclosing function turns out to be strict". You won't know
>> that it's strict until you see the "use strict" directive which is in the
>> function *body*.
>>
>
> Same problem (but semantic check, not syntactic) for duplicate formals
> banned in ES5 strict, right?
>

Ah—yes, that's true.

-j
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Brendan Eich 

Jason Orendorff wrote:
Functions with default arguments have the same weird problem. You can 
still do it in one pass, but you have to track "this 
parameter-default-value-expression contains code that would not be 
allowed if the enclosing function turns out to be strict". You won't 
know that it's strict until you see the "use strict" directive which 
is in the function *body*.


Same problem (but semantic check, not syntactic) for duplicate formals 
banned in ES5 strict, right?


Yes, it's a pain. Pretty sure nothing can be done about it, though.

/be
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Jason Orendorff 
The meeting notes say:

> arrows can't have intrinsic names (contrast with NFEs) so arguments.callee
> may be wanted, so arrows should not be strict-only.
>
>
I'm glad this is going away. I share Alex's skepticism over this particular
motive. But just generally it was going to be a little bizarre and
astonishing for users, the implicit strictness.

Separately, a funny story about that auto-strictness: Since we currently
enforce strictness SyntaxErrors in the initial parse pass, and arguments
can contain default values which are arbitrary JS expressions, I had
implemented arrow functions by rewinding the state of the token stream to
the beginning of the arguments after the => token was reached, and just
re-parsing the whole thing as a function. (I know, I know, I've forefeited
my hacker's license.)

Functions with default arguments have the same weird problem. You can still
do it in one pass, but you have to track "this
parameter-default-value-expression contains code that would not be allowed
if the enclosing function turns out to be strict". You won't know that it's
strict until you see the "use strict" directive which is in the function
*body*.

-j
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Brandon Benvie 
I understand, but it's still a limitation of arrow functions that they rely on 
arguments.callee to self-reference. Relying on the defined name they're 
assigned to suffers from the "can be redefined" problem. NFE's don't suffer 
this problem and can completely avoid `arguments` in ES6 for all use cases 
Arrow functions, currently, cannot.

On Mar 16, 2013, at 3:12 PM, Brendan Eich  wrote:

> I wouldn't overreact. My note was simply that we should not make arrows 
> strict by definition, and TC39 agreed. Among the "folk wisdom" reasons for 
> avoiding strict is to have arguments.callee, but of course NFEs should be 
> preferred in modern engines. But there's no arrow NFE form.
> 
> /be
> 
> Brandon Benvie wrote:
>> I think this is a better argument for introducing a new primitive for 
>> referencing the current function than for resurrecting arguments.
>> 
>> On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer > > wrote:
>> 
>>> Quoting Brendan Eich in [1]:
>>> 
 arrows can't have intrinsic names (contrast with NFEs) so arguments.callee 
 may be wanted, so arrows should not be strict-only.
>>> 
>>> Is this really an option? Sounds messy. Like a carrot to go back to 
>>> non-strict. I’d either allow arguments.callee in both modes. Or introduce a 
>>> new mechanism for a function to refer to itself. I thought that `arguments` 
>>> would disappear from JavaScript code over time so the latter alternative 
>>> seems better.
>>> 
>>> Axel
>>> 
>>> [1] https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
>>> 
>>> -- 
>>> Dr. Axel Rauschmayer
>>> [email protected] 
>>> 
>>> home: rauschma.de 
>>> twitter: twitter.com/rauschma 
>>> blog: 2ality.com 
>>> 
>>> ___
>>> es-discuss mailing list
>>> [email protected] 
>>> https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Brendan Eich 

Allen Wirfs-Brock wrote:
regarding using 'arguments' within arrow functions, I would be 
sympathetic if somebody wanted to argue that arrow functions should 
treat 'arguments' similar to this and super and not local rebind its 
meaning.


However, I would also anticipate some implementor push back on that as 
I suspect that implementations aren't current set up to uplevel access 
'arguments'




No one proposed this and the consensus was implicitly against it in 
wanting strict mode opt-in to compose with arrows as with function 
expressions. Let's not complicate arrows any more than necessary 
(lexical |this|).


/be
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Allen Wirfs-Brock 
If you need to name an arrow function you can use let or const and reference 
the name both within body and use it as an argument expression.

regarding using 'arguments' within arrow functions, I would be sympathetic if 
somebody wanted to argue that arrow functions should treat 'arguments' similar 
to this and super and not local rebind its meaning.

However, I would also anticipate some implementor push back on that as I 
suspect that implementations aren't current set up to uplevel access 'arguments'

Allen





On Mar 16, 2013, at 3:19 PM, Axel Rauschmayer wrote:

> OK. Thankfully, with `super`, an important use case for a function referring 
> to itself goes away (AFAIK, `super` keeps qooxdoo and Ember in non-strict 
> mode, they need arguments.callee).
> 
> On Mar 16, 2013, at 23:12 , Brendan Eich  wrote:
> 
>> I wouldn't overreact. My note was simply that we should not make arrows 
>> strict by definition, and TC39 agreed. Among the "folk wisdom" reasons for 
>> avoiding strict is to have arguments.callee, but of course NFEs should be 
>> preferred in modern engines. But there's no arrow NFE form.
>> 
>> /be
>> 
>> Brandon Benvie wrote:
>>> I think this is a better argument for introducing a new primitive for 
>>> referencing the current function than for resurrecting arguments.
>>> 
>>> On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer >> > wrote:
>>> 
 Quoting Brendan Eich in [1]:
 
> arrows can't have intrinsic names (contrast with NFEs) so 
> arguments.callee may be wanted, so arrows should not be strict-only.
 
 Is this really an option? Sounds messy. Like a carrot to go back to 
 non-strict. I’d either allow arguments.callee in both modes. Or introduce 
 a new mechanism for a function to refer to itself. I thought that 
 `arguments` would disappear from JavaScript code over time so the latter 
 alternative seems better.
 
 Axel
 
 [1] https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
 
 -- 
 Dr. Axel Rauschmayer
 [email protected] 
 
 home: rauschma.de 
 twitter: twitter.com/rauschma 
 blog: 2ality.com 
 
 ___
 es-discuss mailing list
 [email protected] 
 https://mail.mozilla.org/listinfo/es-discuss
>>> ___
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> 
> -- 
> Dr. Axel Rauschmayer
> [email protected]
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Axel Rauschmayer 
OK. Thankfully, with `super`, an important use case for a function referring to 
itself goes away (AFAIK, `super` keeps qooxdoo and Ember in non-strict mode, 
they need arguments.callee).

On Mar 16, 2013, at 23:12 , Brendan Eich  wrote:

> I wouldn't overreact. My note was simply that we should not make arrows 
> strict by definition, and TC39 agreed. Among the "folk wisdom" reasons for 
> avoiding strict is to have arguments.callee, but of course NFEs should be 
> preferred in modern engines. But there's no arrow NFE form.
> 
> /be
> 
> Brandon Benvie wrote:
>> I think this is a better argument for introducing a new primitive for 
>> referencing the current function than for resurrecting arguments.
>> 
>> On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer > > wrote:
>> 
>>> Quoting Brendan Eich in [1]:
>>> 
 arrows can't have intrinsic names (contrast with NFEs) so arguments.callee 
 may be wanted, so arrows should not be strict-only.
>>> 
>>> Is this really an option? Sounds messy. Like a carrot to go back to 
>>> non-strict. I’d either allow arguments.callee in both modes. Or introduce a 
>>> new mechanism for a function to refer to itself. I thought that `arguments` 
>>> would disappear from JavaScript code over time so the latter alternative 
>>> seems better.
>>> 
>>> Axel
>>> 
>>> [1] https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
>>> 
>>> -- 
>>> Dr. Axel Rauschmayer
>>> [email protected] 
>>> 
>>> home: rauschma.de 
>>> twitter: twitter.com/rauschma 
>>> blog: 2ality.com 
>>> 
>>> ___
>>> es-discuss mailing list
>>> [email protected] 
>>> https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
> 

-- 
Dr. Axel Rauschmayer
[email protected]

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Brendan Eich 
I wouldn't overreact. My note was simply that we should not make arrows 
strict by definition, and TC39 agreed. Among the "folk wisdom" reasons 
for avoiding strict is to have arguments.callee, but of course NFEs 
should be preferred in modern engines. But there's no arrow NFE form.


/be

Brandon Benvie wrote:
I think this is a better argument for introducing a new primitive for 
referencing the current function than for resurrecting arguments.


On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer > wrote:



Quoting Brendan Eich in [1]:

arrows can't have intrinsic names (contrast with NFEs) so 
arguments.callee may be wanted, so arrows should not be strict-only.


Is this really an option? Sounds messy. Like a carrot to go back to 
non-strict. I’d either allow arguments.callee in both modes. Or 
introduce a new mechanism for a function to refer to itself. I 
thought that `arguments` would disappear from JavaScript code over 
time so the latter alternative seems better.


Axel

[1] 
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md


--
Dr. Axel Rauschmayer
[email protected] 

home: rauschma.de 
twitter: twitter.com/rauschma 
blog: 2ality.com 

___
es-discuss mailing list
[email protected] 
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Re: Self-recursion and arrow functions

2013-03-16 Thread Brandon Benvie 
I think this is a better argument for introducing a new primitive for 
referencing the current function than for resurrecting arguments.

On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer  wrote:

> Quoting Brendan Eich in [1]:
> 
>> arrows can't have intrinsic names (contrast with NFEs) so arguments.callee 
>> may be wanted, so arrows should not be strict-only.
> 
> Is this really an option? Sounds messy. Like a carrot to go back to 
> non-strict. I’d either allow arguments.callee in both modes. Or introduce a 
> new mechanism for a function to refer to itself. I thought that `arguments` 
> would disappear from JavaScript code over time so the latter alternative 
> seems better.
> 
> Axel
> 
> [1] https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
> 
> -- 
> Dr. Axel Rauschmayer
> [email protected]
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss