Re: Re:

["Felix Klock's ll1 list proxy" <address@hidden>]

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