Lambda vs. function
Waldemar Horwat
waldemar at google.com
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
> 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
More information about the Es-discuss
mailing list