On Sun, Jul 31, 2011 at 4:55 PM, Marijn Haverbeke mari...@gmail.com wrote:
I've been throwing around some ideas about a simpler way to 'alias'
(non-owning reference) things with Patrick, and am in the process of
working out some ideas. A bunch of the possible directions, and the
ones that seem
I understand that tail calls aren't working with the current state of things,
and I won't get in the way. Fair warning: I am not promising I won't argue for
bringing them back at some point in the future.
- The alias-optimizing issues discussed earlier in this thread
I've been chatting with
I'll try to stick up for tail calls, at least down the road (I'd say having
them in the first release doesn't really matter).
A few points:
- As you guys have said, this issue seems pretty tied in with the memory
management semantics, particularly with refcounting. But I'm still not
convinced
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.
Perhaps it would be possible to apply some compile-time transformation to
mitigate the problem:
Transform
void f() {
.
f();
}
into
void f() {
take ownership
f1();
drop ownership
}
void f1() {
f1();
}
Marijn Haverbeke wrote:
I've been throwing
Perhaps it would be possible to apply some compile-time transformation to
mitigate the problem:
I don't really understand your transformation, but it seems like the
resulting code would still consume stack space for the 'tail' call.
___
Rust-dev
Hi
You are correct, my original transformation was not very well spelled out.
Effectively, I'm transforming a normal method into a method where the take
happens in the caller and the drop happens in
the callee.
It'll consume two stack frames - one for the original method, and one for the
extra
On Mon, Aug 1, 2011 at 7:56 AM, Noel Grandin noelgran...@gmail.com wrote:
That kind of coding is easily modelled by returning closures to a core event
loop routine.
Maybe I'm missing something here, but closures are typically
heap-allocated, whereas in Sebastian's scenario:
Sebastian
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
I've been throwing around some ideas about a simpler way to 'alias'
(non-owning reference) things with Patrick, and am in the process of
working out some ideas. A bunch of the possible directions, and the
ones that seem most promising to me at the moment, work poorly with
tail calls. Having the
10 matches
Mail list logo
