I think it woudl be kind of cool to add abort and call/cc (plus a good
set of delimited operators, of course) to ASL or to define ASL+ as
including those. (Or maybe ASL-- and take out state?)
I can see John's point about the work involved, but it is hard to
imagine a better learning environment for continuations than ASL--
plus John's stepper!
Robby
On Wed, Nov 4, 2015 at 11:48 AM, Matthias Felleisen
<matth...@ccs.neu.edu> wrote:
>
> On Nov 4, 2015, at 12:21 PM, "'John Clements' via users-redirect"
> <us...@plt-scheme.org> wrote:
>
>> Following up on this, here’s a simple test case, written in the stepper’s
>> test case language. One amusing UI note: what should be highlighted as the
>> “before” of the invocation-of-continuation step? The application of the
>> continuation, or the whole program?
>>
>> ;; this is just a sketch...
>> (t 'call/cc m:mz
>> (+ 3 (call/cc (λ (k) (+ 1 (k 2)))))
>> :: (+ 3 {(call/cc (λ (k) (+ 1 (k 2))))})
>> ;; not sure what KONT-REP should be...
>> -> (+ 3 (+ 1 ({KONT-REP} 2)))
>
>
> According to my old work, two representations would work best here:
>
> (A) -> (call/cc (lambda (abort) (+ 3 (+ 1 ((lambda (x) (abort (+ 3 x))) 2)))))
>
> Option A is completely faithful to the language and essentially
> the execution (if you think of 'goto somewhere global' is the
> callcc-lambda-abort at the top).
>
>
> (B) -> (+ 3 (+ 1 ((lambda (x) (ABORT (+ 3 x))) 2)))
>
> Option B brings in a new feature, which is now available in
> racket/control but wasn't at the time. I consider this easier
> to understand and it is faithful to the library.
>
>
> Everything else John says stands. call/cc is a cute game and essentially
> useless. Use prompt/control/shift/reset/foo/bar instead.
>
>
>
>
>> ;; interesting how the highlight falls apart... what should be highlighted?
>> :: {(+ 1 (KONT-REP 2))}
>> -> {(+ 3 2)}
>> -> 5)
>>
>> John
>>
>>> On Nov 4, 2015, at 9:02 AM, 'John Clements' via users-redirect
>>> <us...@plt-scheme.org> wrote:
>>>
>>> First, apologies for bouncing this back to the list, hope that’s okay…
>>> =
>>>> On Nov 4, 2015, at 2:20 AM, Marco Faustinelli
>>>> <marco.faustine...@onebip.com> wrote:
>>>>
>>>>
>>>> What I definitely AM missing (I can't see why you contradict my personal
>>>> statement at the same time you are actually taking it into consideration
>>>> :-) is the educational value of being able to "see" the code contained in
>>>> a continuation, which is the core problem of whoever approaches call/cc.
>>>>
>>>> myCont = (lambda(_) ...)
>>>>
>>>> As the stepper is there for educational purposes, this is something that
>>>> would be spot-on with its core business; I am ready to believe that a text
>>>> dump of the code contained in the continuation is not easy to achieve (I
>>>> assume that the code has been interpreted on the fly into a tree or
>>>> something).
>>>
>>> Forgive me; I didn’t mean to suggest that it wouldn’t be educational. It
>>> would.
>>>
>>>>
>>>> But I see that the stepper is very good at substituting readable
>>>> expressions. That's the heart of its effectiveness, so there must be a way…
>>>
>>> Yep. There’s definitely a way, and if anyone was going to do it, it would
>>> probably be me :).
>>>
>>> Okay, I just thought about it for five minutes, and here’s what I think:
>>>
>>> 1) At a very basic level, the stepper is not currently enabled for any of
>>> the languages that include call/cc. IIRC, the first language that includes
>>> call/cc is advanced, which also includes mutation. Doing mutation right is
>>> kind of a bear. You should be able to enable half-baked stepper support in
>>> any language by setting the “PLTSTEPPERUNSAFE” environment variable.
>>> 1a) Okay, I just tried it, and it turns out that call/cc isn’t in Advanced,
>>> either. This means that you need to try this in full #lang racket, which is
>>> really not a language where the stepper is going to be too good at
>>> rendering.
>>> 1b) Hmm, interesting. I got a bit conservative in the 6.3 release, and
>>> currently PLTSTEPPERUNSAFE works for advanced but not for full #lang
>>> racket. I’ve just made a change that should allow this, but it DEFINITELY
>>> WON’T be a part of the 6.3 release.
>>> 2) You mention that “the stepper is very good at substituting.” In fact,
>>> for the most part, the stepper doesn’t know anything about substitution; it
>>> simply observes the computation as it proceeds. This actually turns out to
>>> be a big win for watching call/cc run; while the existing stepper has no
>>> idea how to render a continuation, as soon as you step *into* the
>>> continuation, the context should be correctly displayed. In my opinion,
>>> this is about three quarters of the way to
>>> understanding call/cc. Maybe I’m looking at the glass as more full than it
>>> is :).
>>> 3) The remaining piece would be to capture the current marks and associate
>>> them with the continuation. To do this, the stepper would have to know when
>>> a continuation was being captured. Not impossible, but interesting.
>>> 4) Rendering the continuation: this could be horrible, or easy. If you
>>> decide to try to render the continuation as a legal term in the language,
>>> it would be a good deal of the work. BUT… if you just deployed the existing
>>> mark-rendering machinery to render the set of marks as a context, and then
>>> put a special “kont-box” around it—that is, “this isn’t a legal term in the
>>> language, it’s a special context term that will replace the existing
>>> context if called”—it wouldn’t be too hard.
>>> 5) This is the unpleasant bullet. I’m at a teaching school, and I’ve got a
>>> whole bunch of exams to grade. This isn’t at the top of my list right now,
>>> and I’m not sure when it will be, especially given that call/cc doesn’t
>>> appear in Advanced; even if it worked as I suggest, using the stepper for
>>> call/cc would be like a trip to the jungle: “we’re going in here, to catch
>>> a glimpse of the jaguar. Whew! Done! Now, let’s retreat back to
>>> civilization.”
>>>
>>> Best,
>>>
>>> John Clements
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
