Simple tail calls

# Peter Michaux (17 years ago)

I think tail calls is really an es-discuss (i.e. not es3.x-discuss) topic so I've added that list.

Brendan commented to me about tail calls

esdiscuss/2008-July/006566

I created a Mozilla ticket in response and one of my comments there talks about the arguments.caller problem

bugzilla.mozilla.org/show_bug.cgi?id=445363

I'm all for tail calls. I'd like to see implicit tail calls. Implicit tail calls would be necessary if tail calls are used in lambdas as there is no "return" statement in a lambda.

Peter

# Michael Day (17 years ago)

I created a Mozilla ticket in response and one of my comments there talks about the arguments.caller problem

arguments.caller is not defined by ES 3.0, right?

I think this feature is not helpful for efficient implementations, and it would be best to deprecate it.

I'm all for tail calls. I'd like to see implicit tail calls. Implicit tail calls would be necessary if tail calls are used in lambdas as there is no "return" statement in a lambda.

Personally I would prefer to have return statements in lambdas as well. Perhaps it is worth making a combined lambda + tail call proposal, given that the two features work well together.

# Mark S. Miller (17 years ago)

On Sat, Dec 6, 2008 at 2:39 PM, Michael Day <mikeday at yeslogic.com> wrote:

Hi Peter,

I created a Mozilla ticket in response and one of my comments there

talks about the arguments.caller problem

arguments.caller is not defined by ES 3.0, right?

I think this feature is not helpful for efficient implementations, and it would be best to deprecate it.

It is also not defined by ES3.1-nonstrict. ES3.1-strict does better than deprecate it. It defines it (along with arguments.callee, <function>.caller,

and <function>.arguments) to throw an error.

# David-Sarah Hopwood (17 years ago)

Michael Day wrote:

Hi Mike,

What about

function f() { try { return g(); } finally { h(); } }

Good point! Is there any solution other than to say that try { } disables tail calls?

try blocks generally disable tail-call optimization in other language implementations.

It seems that the h() inside the finally could be return h(), which would make it a tail call.

Yes, but 'return g();' still wouldn't be.

function f() { with (o) return g(); }

Okay, so the with statement modifies the scope chain, which must be undone after the call to g(). Off the top of my head, I would say that this should still be a tail call unless enough implementers complain :)

Probably not worth the hassle given the usage frequency of 'with'.

# Peter Michaux (17 years ago)
# Brendan Eich (17 years ago)

On Dec 6, 2008, at 2:39 PM, Michael Day wrote:

Hi Peter,

I created a Mozilla ticket in response and one of my comments there talks about the arguments.caller problem

arguments.caller is not defined by ES 3.0, right?

Not even in ES1. Same for f.caller (for some active function f). The
caller hack used by folks including the TIBET team, but it should not
be standardized. Stack backtracing by a reflection API is the way to
go, if we can agree on such a thing (post 3.1).

I think this feature is not helpful for efficient implementations,
and it would be best to deprecate it.

arguments.caller is not in Firefox -- what browsers still support it?

f.caller is still around but it's pretty broken (can't handle
recursion). It's also subject to security checks that censor its value
depending on who is looking at whom.

# Michael Day (17 years ago)

From what I understand, if lambdas are supposed obey Tenent's principle, then they cannot have a return statement/expression. Wrapping an expression in a lambda must not change the meaning of the program. the following would need to be equivalent.

Right, I personally think this is unnecessary; functions don't follow this principle, after all.

I think it makes sense for expressions to have the same meaning, but not control flow statements when moved into a new execution context.