Discuss
  • Even simpler lambdas

Even simpler lambdas

# Peter van der Zee (13 years ago)

Why can't lambda's be a simple case of a lexically scoped return keyword with any arguments implicitly defined and accessible through a predefined identifier/keyword (much like arguments works now)?

arr.map(return '<'+arguments[0]+' class="'+this.getClassName(arguments[1])+'"/>');

arr.map(return '<'+$0+' class="'+this.getClassName($1)+'"/>');

arr.map(return '<'+$[0]+' class="'+this.getClassName($[1])+'"/>');

Or maybe the hash sign...

arr.map(return '<'+#0+' class="'+this.getClassName(#1)+'"/>');

It's going to be hard to come up with a solid grammar for allowing statements this way though (return {foo:bar} would be an objlit, not a block with label). Is that why it's not being considered?

You could work around that by restricting grammar for return and {. So return{ would always start a block. I'm aware that this is also currently valid syntax for returning an object literal, but I think objections over introducing more restricted grammar rules trumps that anyways... :)

Anyways, I like it because it's short, consise, and it feels very intuitive to me. We'd basically overload the return keyword much like the function keyword is right now. As a statement it'd remain the same. As an expression it becomes shorthand notation for a function.

# Tab Atkins Jr. (13 years ago)

On Tue, Apr 17, 2012 at 2:33 AM, Peter van der Zee <ecma at qfox.nl> wrote:

Why can't lambda's be a simple case of a lexically scoped return keyword with any arguments implicitly defined and accessible through a predefined identifier/keyword (much like arguments works now)?

arr.map(return '<'+arguments[0]+' class="'+this.getClassName(arguments[1])+'"/>');

This doesn't seem simpler than:

arr.map((x,y)=> '<' + x + 'class="' + this.getClassName(y) + '"/>');

Your other variants that shorten the 'arguments' name are better, but don't appear to offer much of a win. They also prevent you from using the argument list to good effect, such as by giving them descriptive names or using destructuring and rest args.

I'm not generally a fan of overloading keywords with multiple distinct meanings. It makes the language harder to read.

# François REMY (13 years ago)

I kinda like it. My preferred being:

arr.map(return '<'+$0+' class="'+this.getClassName($1)+'"/>')

BTW, to respond to @TabAtkins, I know by experience that a very large amount of lambdas have 'a', 'b', 'c', 'x', 'y' and 'z' as argument names, because lambdas are short and have an obvious use. In fact, many times, typing the argument names is a pain. When you really need arguments name, it's generally because the code is more complex, or longer. In those particular cases, you can still do that:

arr.map(return do {
    let currentElement = $0;
    let currentIndex = $1;
    ...
});

even if in such cases, I would strongly advocate the use of a true function (question of taste).

-----Message d'origine---

# Brendan Eich (13 years ago)

François REMY wrote:

I kinda like it.

I don't, but what's more, Tab's point has come up already in TC39 in similar settings. I doubt this will fly. It's hard to see 'return' in an expression as different from 'return' at statement level. That's a readability problem that I suspect would sink this if it were to get to TC39.

# Peter van der Zee (13 years ago)

On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich <brendan at mozilla.org> wrote:

François REMY wrote:

I kinda like it.

I don't, but what's more, Tab's point has come up already in TC39 in similar settings. I doubt this will fly. It's hard to see 'return' in an expression as different from 'return' at statement level. That's a readability problem that I suspect would sink this if it were to get to TC39.

I don't agree. The return-statement keyword is very much distinguishable from the return-lambda keyword. How often do you make the mistake for a function declaration vs function expression?

On Tue, Apr 17, 2012 at 6:05 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

This doesn't seem simpler than:

arr.map((x,y)=> '<' + x + 'class="' + this.getClassName(y) + '"/>');

Your other variants that shorten the 'arguments' name are better, but don't appear to offer much of a win.  They also prevent you from using the argument list to good effect, such as by giving them descriptive names or using destructuring and rest args.

I can see that point. However, as François points out, we very often use lambdas in contexts where the arguments don't really need a name in simple expressions, and could be named if you need slightly more complex lambdas. As for spread, you'll still have access to the arguments array (or $ or whatever you wanna end up with). A simple slice will suffice.

# Peter van der Zee (13 years ago)

On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich <brendan at mozilla.org> wrote:

... That's a readability problem that I suspect would sink this if it were to get to TC39.

On the subject of readability; I believe that a worded keyword; map(return $1+$2) gives a much stronger emphasis to "HEY, I'M DOING FUNCTION STUFF OVER HERE" than map((a,b)=>a+b) would. Of course that

could just be a matter of getting used to it.

I'm not against the current proposal, I just still fear that it's very parenthesized. It doesn't immediately make obvious what's going on. Douglas had a good word for it the other day. I've forgotten it. That fear might be unjust though and just come down to a matter of acquaintance.

# Brendan Eich (13 years ago)

Peter van der Zee wrote:

On the subject of readability; I believe that a worded keyword; map(return $1+$2) gives a much stronger emphasis to "HEY, I'M DOING FUNCTION STUFF OVER HERE" than map((a,b)=>a+b) would. $1 and $2?

We may have to disagree on this one. I am telling you TC39 is not going to go for it.

I'm not against the current proposal, I just still fear that it's very parenthesized.

I do not know what you mean. Single-argument => functions have no extra

parentheses.

# Dean Landolt (13 years ago)

On Tue, Apr 17, 2012 at 6:05 PM, Peter van der Zee <ecma at qfox.nl> wrote:

On Tue, Apr 17, 2012 at 10:11 PM, Brendan Eich <brendan at mozilla.org> wrote:

François REMY wrote:

I kinda like it.

I don't, but what's more, Tab's point has come up already in TC39 in similar settings. I doubt this will fly. It's hard to see 'return' in an expression as different from 'return' at statement level. That's a readability problem that I suspect would sink this if it were to get to TC39.

I don't agree. The return-statement keyword is very much distinguishable from the return-lambda keyword. How often do you make the mistake for a function declaration vs function expression?

On Tue, Apr 17, 2012 at 6:05 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

This doesn't seem simpler than:

arr.map((x,y)=> '<' + x + 'class="' + this.getClassName(y) + '"/>');

Your other variants that shorten the 'arguments' name are better, but don't appear to offer much of a win. They also prevent you from using the argument list to good effect, such as by giving them descriptive names or using destructuring and rest args.

I can see that point. However, as François points out, we very often use lambdas in contexts where the arguments don't really need a name in simple expressions, and could be named if you need slightly more complex lambdas. As for spread, you'll still have access to the arguments array

Was it ever the plan to eventually deprecate the arguments free var? Rest-args renders it irrelevant, at least -- it'd be a shame to add in something else that depended on it.

# Erik Arvidsson (13 years ago)

Yeah, I don't like this and I would vote against this.

For the reasons already stated.

# Andrea Giammarchi (13 years ago)

sorry mate, thumbs down here as well ... confusing with RegExp too, no easy spread, neither shorter, abuse of dollar sign within code and no nested possibility if not through arguments trap and extra vars declarations ... a bit "meh" compared with what's already in place as proposal.

br