This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
continuation and multi-threading
Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> > After execution is done and the stack is cleared [...]
>
> And if not? How do you map the scheme execution model onto a stack
> centric execution model? For example:
>
> (define cont 0)
> (define (thunk)
> (call-with-current-continuation
> (lambda (kont)
> (set! cont kont)))
> (thunk2))
>
> (define (thunk2) (cont 1))
>
> If you execute that, the stack will grow and grow because those $n$
> thunk2's never return and thunk keeps creating new thunk2's on the
> stack.
I see. So it is like an infinite recursive call, right? But how often
do people use this kind of technique? Do we really need to solve it?
(I've never used a continuation, so..)
In the above particular case, since (cont 1) is at a tail position,
I can optimize the VM so as to clear the thunk2's frame before calling
cont. I don't know if this solves all cases.
> And what about multithreading? I think you'll have to copy the whole
> stack.
I don't quite understand this. Probably a new thread is executed
in a different VM which has its own stack. Why do I need to copy
the stack? (Shared variables are allocated on the heap.)
> AFAIK there are only 5 solutions for this problem:
>
> 1. Drop call/cc and threads and keep the stack centric model
> 2. Use special markers and copy the stack when necessary
> 3. Use stack segments
> 4. "The stack is the heap"; Henry Baker's "Cheney on the M.T.A"
> (we'll need a copying gc to implement that though)
> 5. Put all frames on the heap.
Is there any problem with dropping call/cc? I've heard continuation
is not indispensable if we have a good exception handling and
multi-threading support. Must we support it?
The other day someone said that continuation is helpful to write
translators, but hey, we have a VM. One may add any necessary
instructions to write a compiler. I don't see any reason why
continuation is so important.
I think Guile is supposed to be a language for programmers, not for
scientists. Guile must be a useful Scheme implementation before
being a perfect Scheme implementation. There are lots of good
Scheme implementations already, so we don't need to reinvent it.
I want to write something practically very useful, not something
academically interesting. (I am (supposed be) a scientist, too,
but..)
I think we can write a useful language without having continuation.
If supporting continuation is so hard, I would choose to drop it.
I don't expect Guile to tackle so hard problems.