Re: Re:

[Matthias Felleisen <address@hidden>]

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

-- Matthias

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

>
> 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