Lambda vs. function

Thu Oct 16 18:44:08 PDT 2008

```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