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]

Re: continuation and multi-threading


31-Jul-00 16:10 you wrote:
> 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?

Peoples - VERY rare. Automatic convertors - every now and then. Continuations
are used VERY often in ForeingLanguage->Scheme translators. Bad hadling of
continuations (and currently guile does it SLOW currently) will make
translators MUCH less feasible.

> Do we really need to solve it? (I've never used a continuation, so..)

See above. Of course if we plan drop translators idea then we can bother much
less about continuations.

> 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.

No, it will not :-(

>> 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?

It's part of Scheme language.

> I've heard continuation is not indispensable if we have a good exception
> handling and multi-threading support.  Must we support it?

Yes, we MUST. Of course with good exception handling in most cases you
can use exceptions and not continuation but call/cc is still part of
language and thus MUST be implemented (even if slow - with exceptions
speed of call/cc is not such a big issue since it'll be used less often).

> 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.

They are used in some programming techniques and they are part of language.
We can not drop them. We can have slow continuations and fast alternatives
for "common cases" (exceptions) but we can not drop them altogether.

> I think Guile is supposed to be a language for programmers, not for
> scientists.

Guile is supposed to be Scheme.

> Guile must be a useful Scheme implementation before being a perfect
> Scheme implementation.

First of all Guile must be SCHEME implementation. Scheme with slow continuations
is still Scheme with slow continuations. Scheme without continuations is not
Scheme anymore.

> 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.

Just one problem: it'll not be Scheme. It'll some usefull language (may be)
but it'll not be Scheme.

> If supporting continuation is so hard, I would choose to drop it.
> I don't expect Guile to tackle so hard problems.

We have MORE THEN ENOUGH "usefull languages" (PHP, Perl, Python, TCL). May
be it's time to develop something standards-compliant ?




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