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


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.

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