Lambda vs. function
waldemar at google.com
Thu Oct 16 13:55:59 PDT 2008
Dave Herman wrote:
>> I don't see enough of a benefit to warrant inclusion of a new lambda
>> concept. It's just another way of doing what local functions can do.
> As I see it, the major benefits of `lambda' are
> a) introducing a low-level and compositional primitive that is useful
> for code generation (as a target language for compilers, macros, or
> other language features defined by desugaring), and
> b) creating a clearer place in the language syntax to enforce tail
> calling by eliminating `return'
I don't understand what you mean in point b.
> These needs aren't addressed by `function' and almost certainly can't be.
>> If there is a bug with local functions, then fix that one instead
>> instead of sowing confusion by having two concepts.
> Recall that `lambda' does not include `return', `this', `var', or
> `arguments'. We're not about to eliminate those from `function'! (Nor
> would I advocate doing so-- even if we could somehow rewrite the entire
> Maybe you don't feel that the issues addressed by `lambda' are important
> enough to warrant the new feature, but "just change `function'" is a not
> a realistic argument.
Why isn't function a realistic alternative? You cited four differences:
return: Return from within a function returns from that function instead of doing a longjmp. I'd consider that to be a feature.
this: You have a point there.
var: Not an issue if you're not using var inside the lambda. Code generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not using the arguments array. If a code generator is updated for lambda, then presumably it will be updated not to use the arguments array.
More information about the Es-discuss