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

Re: Re:

In a unityped language like Scheme or in a typed language without 
this is correct and probably known since Adam and Eve or Steele and 

-- Matthias

On Thursday, August 14, 2003, at 03:01 PM, Felix Klock's ll1 list proxy 

> 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