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

For the record: letrec and the stepper are more in sync than
your original message appears to suggest.

(letrec ((x e)) b) allocates a cell cx, evaluates e, stuffs the
value of e into cx, and then evaluates b in a context where x
denotes cx.

The stepper does exactly that. Renaming first is finding the
name cx. Lifting the evaluated definition to the top is the
allocation step. The substitution of x with cx means "use
cs for x in this scope."

You are correct of course in that the stepper doesn't
model the gc step (as in Felleisen/Hieb 91 or
Morrisett-Felleisen-Harper 94). Doable

-- Matthias




On Jan 23, 2006, at 1:30 PM, Robby Findler wrote:

> 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]
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme