Lambda vs. function

[Waldemar Horwat]

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 
> web.)
> 
> 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.

    Waldemar