This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
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.