bug-guile
[Top][All Lists]
Advanced

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

Re: shift and reset in ice-9 control


From: Wolfgang J Moeller
Subject: Re: shift and reset in ice-9 control
Date: Tue, 12 Apr 2011 15:11:03 +0200 (CEST)

On Tue, 12 Apr 2011, Andy Wingo wrote:

>[...]
> Have you tried this on Racket?  I would expect that it would do the
> right thing.  The difference, AFAIK, is that a prompt delimits full
> continuations there as well.  That's why they call them "composable"
> continuations instead of "delimited" continuations: because either kind
> can be delimited; the real question is what properties do they have.
>
> I think we're going to switch to do that in Guile 2.2 as well.

Careful! One might easily come up with a reason to use call/cc in order
to leave/reenter a "composable" continuation - after all, it's supposed
to behave just like another procedure, and for tasks like "backtracking",
you do want procedures e.g. to return multiple times.

It seemed to me that the original specification of shift/reset
didn't describe the consequences of transfer of control (via call/cc)
"across" reset - maybe because it wasn't targeted specifically at Scheme.
That's why I had doubts that my co-routine problem could be solved.
Now that it is, I've no more problems with the current implementation.

Anyway, inhibiting some uses of call/cc would be quite non-scheme-y ...

>[...]
> > Depending upon what I do with this snippet (auto-compile, load vs. include),
> > it sometimes gets accepted by GUILE V2.0.0:
> >
> >             auto,include    auto,load       noauto,include  noauto,load
> > ---------------------------------------------------------------------------
> > @toplevel   Error           Error           Error           OK
> > surrounded by
> > BEGIN       Error           Error           Error           Error
> > EVAL-WHEN   OK              OK              OK              Error
>
> Indeed.  If you need to evaluate previous expressions in order to expand
> later ones, you need eval-when.  That goes for forms within your
> prelude, and for the "users" of your prelude; Guile doesn't know that
> when it sees a `(load "prelude.scm")' that prelude.scm will define
> syntax definitions, so it won't pull in those definitions at
> compile-time, without an eval-when wrapping the load...
>
> I don't understand the noauto,load case there though.  Were some of your
> files compiled and some not?  Hmm...

By "noauto,load" I meant (load "prelude.scm") into "guile --no-auto-compile",
with care taken (as in all of the above ",load" cases ;-) that _no_ compiled
[& cached] files were in place. It's exactly this column that's confusing me
(still with Guile V2.0.0).

Btw, meanwhile I've found that wrapping the second (macro-using) part
in another (eval ...) - thus terminating the top-level definition context -
works just fine w/o EVAL-WHEN, and so my "new" prelude now can be LOADed
into GUILE V2 independent of auto-compilation, as well as into GUILE V1, etc.


Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]