Re: continuation and multi-threading

[Ivan Toshkov <ivant at ifao dot net>]

On Mon, Jul 31, 2000 at 10:47:15PM +0200, Mikael Djurfeldt wrote:
> Keisuke Nishida <kxn30@po.cwru.edu> writes:
> 
> > 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.
> 
> We won't drop call/cc.
> 
> Guile is now essentially fully R5RS compatible, and we won't take any
> steps away from that.
> 
> Call/cc is not just a tool for language theorists.  It's a very
> powerful element from which you can build virtually any control
> structure.  The Guile policy has inherited the following from the R5RS
> report:
> 
> ** Fundamental rule of thumb
> 
> >From R5RS:
> 
> "Programming languages should be designed not by piling feature on top
> of feature, but by removing the weaknesses and restrictions that make
> additional features appear necessary."
> 
> Call/cc is exactly the kind of thing which makes additional features
> unnecessary.
> 
> In practise, however, a lot of people are unused to call/cc, so we
> provide additional features anyway.
> 
> Having call/cc enables us to benefit from many new implementations of
> Scheme tools which pop up now and then.
> 
> 
> Of course, when developing a VM, everything doesn't need to be
> finished immediately, but we also must make sure not to "build
> ourselves into a corner".
> 
> We will very probably not replace the current evaluator with a
> solution which doesn't support tail-recursive continuations.

I fully agree.

I think, the next best thing to having fast continuations is to have
*any* continuations, which don't get much in the way of the other
parts of the VM (is it possible?).  So, one can retain the full speed
of the VM if that's what one needs, but olso be able to use
continuations if that's needed.

What's more, if there is a strong demand for a certain control
structure to be faster, it can be implemented separately if the VM,
(e.g. catch/throw).

-- 
Ivan Toshkov