On 11-08-01 07:45 PM, Rafael Ávila de Espíndola wrote:
On 11-08-01 10:18 AM, Marijn Haverbeke wrote:
Ah, I see what you mean now. But this kind of rewriting requires
knowledge of the tail-called function (which may be in another module,
or passed in by value), and a bunch of extra complexity. It doesn't
really have the elegance of classical tail calls.
I think we had decide to only allow tail calls inside a crate. In part because
of limitations on which calls llvm guarantees are tail.
But I would vote for dropping tail calls. Even if we do them inside crates only,
there is still a mismatch with rust where "tail" is a property of the call only
and llvm where the callee must know it is can be tailcalled.
Yeah. I concur. Tail calls are something I'm willing to give up for a
few reasons.
- Linkage models don't guarantee the ability to do cross-crate tail
calls. Sad but apparently true.
- Tail calling hurts optimization in the non-tail-call case a fair
bit, both in the codegen (stack movement) sense and in the sense of
permitting the compiler to pair up take/drop as Marijn noted.
- I agree with Sebastian that tail *recursion* is not the compelling
case of tail calls at all; that's nice for textbooks but the bigger
use-case is state machines. However: we have early returns and
mutable alias arguments; it's not really clear we need them nearly
as much as (say) a pure-expression language. They're really just an
optimization, to avoid the cost of doing a switch on a first class
value (current state gets encoded into the PC directly, rather than
a state variable). It's really not clear to me that this case is
a sufficiently important one to bend the rest of the language for.
Any champions for 'em? I have stood up for them many times in the past
but they continue to be a sticky cost we pay on many design choices, I'd
be ok ceasing to pay that.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
