Lambda vs. function

[Waldemar Horwat]

Dave Herman wrote:
>>> 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.
> 
> Consider two different syntaxes for a function performing a tail call:
> 
>     lambda(x) { f(x) }
>     function(x) { return f(x) }

What is your point?  To write a recursive factorial I'd write either:

lambda f(x) {
  if (x == 0)
    1;
  else
    f(x - 1);
}

or:

function f(x) {
  if (x == 0)
    return 1;
  else
    return f(x - 1);
}

Either one is subject to having to jump out of try-catch blocks if you have them.  You still have all the same issues of whether f is in the tail position or not.

> The traditional semantics of `return' is 1) evaluate the argument to get 
> a value and 2) jump to the caller (i.e., pop the stack frame) with that 
> value. If we try to graft tail calls on top of `return', we reverse the 
> semantics: 1) jump to the caller with an unevaluated expression and 2) 
> evaluate the subexpression.
> 
> But what if the `return' occurs in a try-block? Then popping the whole 
> activation frame would be incorrect (it would unwind the exception 
> handler too soon). So now we have to say the semantics of `return' 
> depends on its context:
> 
>     1) if the `return' is in tail position, then
>        1.1) jump to the caller and
>        1.2) evaluate the subexpression
>     2) if the `return' is not in tail position, then
>        1.1) evaluate the subexpression and
>        1.2) jump to the caller

Maybe you're mixing semantics with implementation.  They all first evaluate the subexpression and then jump to the caller.

    Waldemar