Simple tail calls
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.
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.
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'.
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.
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.
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