Stepper doesn't show steps for some programs

[justinpombrio]

In the stepper for "Intermediate Student with lambda", the program:

((lambda (x) (x x)) (lambda (x) (x x)))

doesn't show any steps, even though this program takes infinitely many evaluation steps. The stepper appears to run forever without finding the first step.

On the other hand, the program:

((lambda (x) (x x)) (lambda (x) ((x x) (x x))))

shows infinitely many steps like it should.

(This behavior seems to be sensitive to alpha-renaming, so my guess at a cause is that the stepper is suppressing steps that yield a syntactically identical program.)

[jbclements]

On Feb 15, 2016, at 12:49 PM, Justin Pombrio notifications@github.com wrote:

In the stepper for "Intermediate Student with lambda", the program:

((lambda (x) (x x)) (lambda (x) (x x)))

doesn't show any steps, even though this program takes infinitely many evaluation steps. The stepper appears to run forever without finding the first step.

On the other hand, the program:

((lambda (x) (x x)) (lambda (x) ((x x) (x x))))

This is a known issue, and you’re absolutely right about the cause. Stephen Chang added this behavior, to support laziness. Stephen, thoughts on this? (Apologies for my … unsportsmanlike behavior?)

John

[stchang]

Yes, this has come up before with no solution. http://bugs.racket-lang.org/query/?cmd=view%20audit-trail&database=default&pr=13469 http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=13637

I'll see if I can add in some special cases to handle this though no easy solution is immediately apparent since the (lazy and non-lazy) reconstruction code is pretty intertwined.

As a short term solution, I would be fine with restoring proper (non-lazy) stepper behavior, and opening a lazy stepper bug.

[jbclements]

On Feb 15, 2016, at 2:02 PM, Stephen Chang notifications@github.com wrote:

Yes, this has come up before with no solution. http://bugs.racket-lang.org/query/?cmd=view%20audit-trail&database=default&pr=13469 http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=13637

I'll see if I can add in some special cases to handle this though no easy solution is immediately apparent since the (lazy and non-lazy) reconstruction code is pretty intertwined.

As a short term solution, I would be fine with restoring proper (non-lazy) stepper behavior, and opening a lazy stepper bug.

Stephen, what kind of bugs would appear in the lazy stepper if this were removed?

John

— Reply to this email directly or view it on GitHub.

[rfindler]

At some level, the stepper must know if it is stepping a lazy program or not. (At a min, DrRacket can tell it?). Could something be done only for the strict stepper so students in classes don't run into this problem anymore?

[stchang]

what kind of bugs would appear in the lazy stepper if this were removed?

Other than duplicate steps, I'm not sure. Let me review the marks I added to Lazy Racket.

[jbclements]

On Feb 15, 2016, at 2:07 PM, Robby Findler notifications@github.com wrote:

At some level, the stepper must know if it is stepping a lazy program or not. (At a min, DrRacket can tell it?). Could something be done only for the strict stepper so students in classes don't run into this problem anymore?

That would be far too simple :).

Stephen, this seems like the obviously right solution to me. To you, too?

John

[stchang]

At some level, the stepper must know if it is stepping a lazy program or not

It was a design goal that it would not know. And the lazy stepper does mostly reuse existing stepper code. I'll probably wind up having to distinguish the lazy marks somehow though. Previously, I tried to avoid this solution, which is why these bugs have not been fixed yet.

[jbclements]

On Feb 15, 2016, at 2:27 PM, Stephen Chang notifications@github.com wrote:

At some level, the stepper must know if it is stepping a lazy program or not

It was a design goal that it would not know. And the lazy stepper does mostly reuse existing stepper code. I'll probably wind up having to distinguish the lazy marks somehow though. Previously, I tried to avoid this solution, which is why these bugs have not been fixed yet.

Interestingly, avoiding direct comparison of reconstructed source terms was kind of one of my design goals :). Not a major one, though... Also, this check occurs outside of the main reconstruction loop, so treating lazy specially here doesn’t seem as intrusive as getting down into reconstruct.

John

[stchang]

Interestingly, avoiding direct comparison of reconstructed source terms was kind of one of my design goals

Yes, I think I knew that. The changes I did have to make to the stepper code were not particularly elegant. I'm surprised you havent really complained about it :/. But the lazy marks and the surface steps dont align as well as the beginner langs do, hence the need to hide steps.