[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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.
- Re: Re:
- From: "Felix Klock's ll1 list proxy" <email@example.com>