[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re:
On Thursday, August 14, 2003, at 01:01 PM, Robby Findler wrote:
> He's suggesting that continuations should probably not respond #t to
> procedure? (in other words, continuations should not have the same
> types as procedures do).
>
> And possibly you should have to write (something like):
>
> (throw k v)
>
> rather than:
>
> (k v)
>
> to invoke a continuation. That's the way that SML/NJ does it.
Was this really all there was to Matthias' comment? If so, I don't
understand what he was getting at either.
"Why," you ask? Because the restriction, as you describe it, has no
less power than the current situation.
Lets assume, for the purposes of argument, that things were like you
describe. Then (CALL/CC-OPAQUE p) would call p with an object K of a
new opaque "continuation" type, and you would invoke K with (THROW k v)
Look at this code:
(define (call/cc-as-proc P)
(call/cc-opaque (lambda (K)
(P (lambda (V) (throw K V)))))
Tada! call/cc-as-proc has the same semantics that the original call/cc
did. (Well, except that it doesn't handle continuations that receive
multiple-values properly, but that not hard to fix, it would just
complicate the example...)
I'll leave the other direction [defining the new call/cc-opaque in
terms of call/cc and a suitable opaque object definer such as
MzScheme's define-struct] as an exercise for the reader.
The only difference that I can detect that is a particular pattern of
usage is encouraged with CALL/CC-OPAQUE, where invocations of
continuations is encouraged to stand out in the source base with the
THROW keyword marking them.
-Felix
- Follow-Ups:
- Re: Re:
- From: Matthias Felleisen <matthias@ccs.neu.edu>
- Re: Re:
- From: Matt Hellige <matt@immute.net>
- References:
- Re:
- From: Robby Findler <robby@cs.uchicago.edu>