Re: [racket-users] Evaluating whatever expression halfway a debugging session

[Marco Faustinelli]

First thing, thank you all for the consideration you're giving to my
request.

A bit of background. I'm studying the meaning of continuations and their
role in building useful constructs; think at
generators/iterators/coroutines, as they're coming to JavaScript. I am kind
of smelling already that call/cc isn't the holy grail but nevertheless I
can't see anything else around that may assist my study.

There is a paper (
http://matt.might.net/articles/programming-with-continuations--exceptions-backtracking-search-threads-generators-coroutines/)
that uses call/cc idiomatically for doing apparently workable/useable
stuff. That's where I am at the moment, kinda stuck, and where I hoped the
stepper could help me understand.

I'd kept very kind memories of using the stepper along with the Little
Schemer ;-) and here I am. I couldn't help asking the list why call/cc
ain't supported but I'm afraid I cannot provide high-level feedback in this
discussion. However, I'd be glad to be of assistance as an alpha/beta
tester. I am also studying John's non-trivial example and thinking what I'd
like to be highlighted in that case.

I do believe A LOT of people in various communities (JavaScript, Haskell,
Java/Scala, you name it...) are wandering in the mist when it comes to
continuations, and it's a pity. I reckon the stepper could really come to
the rescue :-)

Have a good day,
Marco



On Wed, Nov 4, 2015 at 10:48 PM, Robby Findler 
wrote:

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

Re: [racket-users] Evaluating whatever expression halfway a debugging session

[Matthias Felleisen]

Yes, I agree that Mist is what is out there when I look a things such as 
node.js and other works of art that re-discover continuations and friends. 

I spent the first N years of my research life thinking and publishing about 
continuations. Simple conclusion: call/cc is not it. I introduced delimited 
continuations (and functional ones) by '88 precisely because programming with 
continuations for nearly 4 years showed just that. (Ditto for operational and 
denotational semantics.) 

My first PhD student (Dorai Sitaram) did the best job of describing what we 
really need (PLDI '94) and Matthew and three more of us explained how this 
flows together in a syetem that unfortunately already suffers from call/cc and 
its stupid continuations. 

Nobody in this day and age should continue to use or advertise call/cc. 

But I am too lazy to write all these papers again just so these people out 
there the idea is new and deserve respect. If they can't read old papers, too 
bad for them for re-inventing all the old mistakes. 

-- Matthias






On Nov 5, 2015, at 4:12 AM, Marco Faustinelli  
wrote:

> First thing, thank you all for the consideration you're giving to my request.
> 
> A bit of background. I'm studying the meaning of continuations and their role 
> in building useful constructs; think at generators/iterators/coroutines, as 
> they're coming to JavaScript. I am kind of smelling already that call/cc 
> isn't the holy grail but nevertheless I can't see anything else around that 
> may assist my study.
> 
> There is a paper 
> (http://matt.might.net/articles/programming-with-continuations--exceptions-backtracking-search-threads-generators-coroutines/)
>  that uses call/cc idiomatically for doing apparently workable/useable stuff. 
> That's where I am at the moment, kinda stuck, and where I hoped the stepper 
> could help me understand.
> 
> I'd kept very kind memories of using the stepper along with the Little 
> Schemer ;-) and here I am. I couldn't help asking the list why call/cc ain't 
> supported but I'm afraid I cannot provide high-level feedback in this 
> discussion. However, I'd be glad to be of assistance as an alpha/beta tester. 
> I am also studying John's non-trivial example and thinking what I'd like to 
> be highlighted in that case.
> 
> I do believe A LOT of people in various communities (JavaScript, Haskell, 
> Java/Scala, you name it...) are wandering in the mist when it comes to 
> continuations, and it's a pity. I reckon the stepper could really come to the 
> rescue :-)
> 
> Have a good day,
> Marco
> 
> 
> 
> On Wed, Nov 4, 2015 at 10:48 PM, Robby Findler  
> wrote:
> 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
>  wrote:
> >
> > On Nov 4, 2015, at 12:21 PM, "'John Clements' via users-redirect" 
> >  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 
> >>>  wrote:
> >>>
> >>> First, apologies for bouncing this back to the list, hope that’s okay…
> >>> =
>  On Nov 4, 2015, at 2:20 

Re: [racket-users] Evaluating whatever expression halfway a debugging session

[Robby Findler]

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
 wrote:
>
> On Nov 4, 2015, at 12:21 PM, "'John Clements' via users-redirect" 
>  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 
>>>  wrote:
>>>
>>> First, apologies for bouncing this back to the list, hope that’s okay…
>>> =
 On Nov 4, 2015, at 2:20 AM, Marco Faustinelli 
  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 

Re: [racket-users] Evaluating whatever expression halfway a debugging session

['John Clements' via users-redirect]

First, apologies for bouncing this back to the list, hope that’s okay…
=
> On Nov 4, 2015, at 2:20 AM, Marco Faustinelli  
> 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.

Re: [racket-users] Evaluating whatever expression halfway a debugging session

['John Clements' via users-redirect]

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)))
   ;; 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 
>  wrote:
> 
> First, apologies for bouncing this back to the list, hope that’s okay…
> =
>> On Nov 4, 2015, at 2:20 AM, Marco Faustinelli  
>> 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 

Re: [racket-users] Evaluating whatever expression halfway a debugging session

[Matthias Felleisen]

On Nov 4, 2015, at 12:21 PM, "'John Clements' via users-redirect" 
 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 
>>  wrote:
>> 
>> First, apologies for bouncing this back to the list, hope that’s okay…
>> =
>>> On Nov 4, 2015, at 2:20 AM, Marco Faustinelli 
>>>  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 

Re: [racket-users] Evaluating whatever expression halfway a debugging session

['John Clements' via Racket Users]

> On Oct 29, 2015, at 10:01 AM, Marco Faustinelli 
>  wrote:
> 
> This question has been asked in 2012 and the fact that no reply has been 
> posted makes me think this is a dead track. But nevertheless...
> 
> I see that during a debugging session I can hover above an expression and 
> rightclick to send its value to the console or so set! it something else.
> 
> What I would like to do is evaluate complete expressions at will using the 
> current context where the debugger is. For example, type expressions and 
> commands in the interactions area and see immediately their value.
> 
> It is a basic functionality offered by all developer tools of all web 
> browsers. Does Racket feature it too?
> 
> I'd love to know how to do this because I am studying call/cc and it would be 
> very useful to experiment with current continuations by feeding them values 
> out of the debugging loop and watching what they do. 
> 
> The maximum I can get now is to see that cc => # but that's 
> really of no help whatsoever.
> 
> Add here the fact that continuations are not examinable in the stepper and 
> soon you see that the assistance given by the environment is virtually none. 
> It's a pity. Am I missing something?

Short answer: no, I don’t think you’re missing anything. :)

Longer answer: evaluating *arbitrary* code while the program is halted would be 
difficult to reconcile with a compiled language. For instance, if my compiler 
has decided to inline a function, and in the debugger I alter the definition of 
this function, my compiled code is now invalid. It’s true that JavaScript can 
do this—essentially, JavaScript is so ludicrously hostile to compilers already 
that compiled code must (nearly) always assume that code can change 
dynamically, which makes evaluating arbitrary code at breakpoints no big deal.

About call/cc: stepper support for call/cc is theoretically possible. It’s an 
interesting problem. Essentially, the stepper would have to assemble the 
information that it has about the context into an internal representation of a 
continuation that would be rendered as a procedure. Somewhat fragile, but 
possible. Mutation would also be a thorny addition to the mix.

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.

Re: [racket-users] Evaluating whatever expression halfway a debugging session

[Alex Knauth]

> On Nov 3, 2015, at 3:01 PM, 'John Clements' via Racket Users 
>  wrote:
> 
>> On Oct 29, 2015, at 10:01 AM, Marco Faustinelli 
>>  wrote:

>> I see that during a debugging session I can hover above an expression and 
>> rightclick to send its value to the console or so set! it something else.
>> 
>> What I would like to do is evaluate complete expressions at will using the 
>> current context where the debugger is. For example, type expressions and 
>> commands in the interactions area and see immediately their value.

> Short answer: no, I don’t think you’re missing anything. :)
> 
> Longer answer: evaluating *arbitrary* code while the program is halted would 
> be difficult to reconcile with a compiled language. For instance, if my 
> compiler has decided to inline a function, and in the debugger I alter the 
> definition of this function, my compiled code is now invalid. 

Would it be possible if in this mode, set! was disallowed unless it was already 
mutable? (And if it's already mutable it wouldn't be inlined, right?)

That way it could never invalidate inlined code?

Or would it also be a problem if there is a break point within a function that 
happens to be inlined, and the arguments were constants, which were propagated, 
and the names aren't there in the environment anymore? Is that the problem?

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

Re: [racket-users] Evaluating whatever expression halfway a debugging session

['John Clements' via Racket Users]

> On Nov 3, 2015, at 12:32 PM, Alex Knauth  wrote:
> 
> 
>> On Nov 3, 2015, at 3:01 PM, 'John Clements' via Racket Users 
>>  wrote:
>> 
>>> On Oct 29, 2015, at 10:01 AM, Marco Faustinelli 
>>>  wrote:
> 
>>> I see that during a debugging session I can hover above an expression and 
>>> rightclick to send its value to the console or so set! it something else.
>>> 
>>> What I would like to do is evaluate complete expressions at will using the 
>>> current context where the debugger is. For example, type expressions and 
>>> commands in the interactions area and see immediately their value.
> 
>> Short answer: no, I don’t think you’re missing anything. :)
>> 
>> Longer answer: evaluating *arbitrary* code while the program is halted would 
>> be difficult to reconcile with a compiled language. For instance, if my 
>> compiler has decided to inline a function, and in the debugger I alter the 
>> definition of this function, my compiled code is now invalid. 
> 
> Would it be possible if in this mode, set! was disallowed unless it was 
> already mutable? (And if it's already mutable it wouldn't be inlined, right?)
> 
> That way it could never invalidate inlined code?
> 
> Or would it also be a problem if there is a break point within a function 
> that happens to be inlined, and the arguments were constants, which were 
> propagated, and the names aren't there in the environment anymore? Is that 
> the problem?

This is a question about the compiler, and … I’m really not qualified to answer 
it :).

With that said, I do see that if you could somehow limit yourself to purely 
functional calls, you might conceivably be okay.

Unfortunately, there’s another whole can of worms, which is the tower of module 
evaluations that’s necessary to compile code.  What if the code you try to 
write winds up referring to a module that’s no longer around, and can’t be 
recreated without re-simulating the whole compilation process? This sounds like 
a nearly insurmountable problem.

John



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

[racket-users] Evaluating whatever expression halfway a debugging session

[Marco Faustinelli]

This question has been asked in 2012 and the fact that no reply has been posted 
makes me think this is a dead track. But nevertheless...

I see that during a debugging session I can hover above an expression and 
rightclick to send its value to the console or so set! it something else.

What I would like to do is evaluate complete expressions at will using the 
current context where the debugger is. For example, type expressions and 
commands in the interactions area and see immediately their value.

It is a basic functionality offered by all developer tools of all web browsers. 
Does Racket feature it too?

I'd love to know how to do this because I am studying call/cc and it would be 
very useful to experiment with current continuations by feeding them values out 
of the debugging loop and watching what they do. 

The maximum I can get now is to see that cc => # but that's 
really of no help whatsoever.

Add here the fact that continuations are not examinable in the stepper and soon 
you see that the assistance given by the environment is virtually none. It's a 
pity. Am I missing something?

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