[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Fwd: Comments on draft 6 about call/cc

On Mon, Feb 20, 2012 at 01:14:09PM +0200, Jussi Piitulainen wrote:
> Alaric Snell-Pym writes:
> > Now, is my understanding that (> call/pc call/cc) true in all cases,
> > or not? Does anybody know of any counter-examples?
> > 
> > Clearly, it's far too late for call/cc to be replaced by delimited
> > continuations for R7RS, but it would be nice to decide if it might
> > be worth considering for R8RS (along with immutable-by-default
> > pairs, perhaps? :-)
> Such things should be considered for the large language now. If they
> can be implemented in terms of the small language, great, let us have
> them as a library, and implementations may be able to do them more
> efficiently. If not, then there are weaknesses in the small language
> that need to be understood and removed.
> I wrote a generator library in terms of call/cc (and r6RS exceptions).
> It was inspired by a broken attempt by someone else. It might have
> been easier and more natural with delimited continuations, which I
> have only read about, and I'm still worried about its correctness, in
> the ways suggested in this thread, so I'm not entirely happy with
> call/cc. Do not remove it, but maybe do look for a replacement.


Moving it to a library paves the way for taking it out in a later version
of the standard, but also means yet another thing to add to your imports
statement when you do want to use it.  We shouldn't require the user to
type in loads of names just to get simple behaviour that you'd get with
R5RS without typing in anything.

Also, note that making the library optional makes a lot of things that
call themselves Scheme but are not really Scheme suddenly Scheme too.
This might be a good or a bad thing, depending on your perspective.
It could also be made optional in that hypothetical later standard which
provides better alternatives but kept required for now.

Also, I still am concerned about the fact that exceptions don't
implicitly cause [call-]with-* to close their associated port.
This is *extremely* error-prone and nonobvious, especially to new
users. It also requires *boilerplate* every time you use it and
possibly exceptions might be raised in subprocedures (and this requires
you to know exactly what the subprocedures do, which defeats
compositionality, or you end up adding the wrapper "just in case")

"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

Scheme-reports mailing list