[plt-scheme] Stylistic (I hope!) question regarding driver loop

Instead extra non-determinitic GC steps, did you consider just building
a GC cleanup into every step? That is, when a definition is unused in
the rhs of a step, it is just gone, right away.

(that's what the letrec example I posted does, fwiw.)

Robby

At Mon, 23 Jan 2006 09:53:24 -0800, John Clements wrote:
> 
> On Jan 21, 2006, at 2:41 PM, Felix Klock's PLT scheme proxy wrote:
> 
> >
> > On Jan 21, 2006, at 3:24 PM, Robby Findler wrote:
> >
> >> (FWIW, You can test this out yourself. This program:
> >> <<snip>>
> >
> > It would be nice if one were able to switch to the HtDP languages  
> > and then use the stepper to illustrate these ideas, rather than  
> > just relying on inferences based on how the computer is behaving as  
> > memory usage grows.  After all, a user could have instead inferred  
> > that DrScheme itself had a memory leak, rather than the program text.
> >
> > Unfortunately, I wasn't able to run Robby's first example in the  
> > HtDP languages; the semantics for letrec in the Student Languages  
> > seems to be different than in the Pretty Big language.
> >
> > I tried adapting the examples to programs that the Student  
> > languages could handle, but eventually I realized that the Stepper  
> > doesn't ever "garbage collect" the intermediate definitions that it  
> > generates (when it processes local/let/letrec), so the only way to  
> > use it to illustrate tail recursion is to tell the human viewer to  
> > do the garbage collection in their heads.
> >
> > To make this concrete: type the following into DrScheme under the  
> > Intermediate Student language
> >
> > (define (f x) (local ((define y x)) (f 1)))
> > (define (g x) (local ((define y (g 1))) y))
> > ; (f 1) ;; uncomment this after you see what stepping through (g 1)  
> > does
> > (g 1)
> >
> > And then compare what hitting the Step button gives you for (f 1)  
> > versus (g 1).  The main problem is that (f 1) generates a series of  
> > y_0, y_1, y_2, ... definitions, but the y_i's are never referenced  
> > by the expression at the bottom of the Step, so they should be  
> > garbage collected if you want to illustrate that the memory usage  
> > of (f 1) is bounded using the stepper.
> 
> Yes, I believe this would be nice, and probably not too hard to  
> implement, using weak boxes. Let's see if I can find time tomorrow  
> (BTW, the smart money is on "no").
> 
> A side point: adding this moves the stepper away from a deterministic  
> reduction semantics by introducing a GC step.  Worse, the GC step  
> will likely be "folded in" to one of the other steps.  Nevertheless,  
> I think that the resulting stepper will be more useful to more people.
> 
> John
> 
> 
> ------------------------------------------------------------------------------
> [application/#f "smime.p7s"] [save & open]