This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]