On May 20, 2011, at 4:42 PM, Sam Tobin-Hochstadt wrote: > On Fri, May 20, 2011 at 4:39 PM, Matthias Felleisen > <matth...@ccs.neu.edu> wrote: >> >> -- I think my preferred solution would be to wrap letrec so that >> continuations grabbed during the setup set up a continuation mark that >> labels them as 'dangerous'. When you reinvoke them, the existence of the >> mark tells you that the reference cells should be reinitialized (probably >> only the ones on the control flow from the continuation point). >> >> -- An alternative could be to stick a lexical identifier into letrec >> declarations that gets removed from the scope once the letrec is >> established. It would reappear when you invoke a continuation from the RHS >> and thus you'd know to reini the ref cells. BUT, this requires a mechanism >> that is not expressible at the surface of Racket. And it's odd. > > I think the key missing piece here is that Matthew wants to avoid > having the reference cells *at all*. If you use `let*', you don't get > any reference cells.
He wants an optimizer that compiles away ref cells for recursive declaration constructs when possible. I think that this is much more easily doable with an internal define compiler that goes around the letrec intermediate steps. So I am proposing to leave letrec around for the cases when you need an extremely general recursion construct AND to modify it so that it is safe against call/cc. I would go as far as giving up on ref cell elimination for letrec. Yes, I forgot to add that this means we need to eliminate letrec from the code base in many cases. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
