Ah, right. Rats. Robby
On Mon, Aug 8, 2011 at 10:25 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > At Mon, 8 Aug 2011 10:12:36 -0500, Robby Findler wrote: >> > Another possibility is to redirect the `set!' on `f' to the >> > underlying `proc', and somehow make the optimized call to `core' >> > happen only when `proc' is never mutated. Due to the order of macro >> > expansion, whether `f' is mutated is not necessarily known when a >> > call to `f' is expanded. The expansion of a call to `f' would have >> > to embed the condition that `proc' is not mutated. >> >> How about adding an extra indirection? That is, you can have core be a >> simple wrapper function that calls some other function, and have proc >> also call that. Then the set! can be redirected to this thing that >> both call (you'd probably have to wrap the right hand side of the set! >> in some kind of argument protocol adjustment thing but if we're >> set!'ing procedures maybe we should have to pay for that). > > A use of `f' in a position other than an application position expands > to just `proc'. If `f' is mutated to something other than a procedure, > those uses of `proc' need to see the new value, so `proc' cannot be a > wrapper. > > I considered redirecting a mutation of `f' to both `proc' and `core', > but I worry about turning an atomic assignment operation into two > steps. > > A non-application use of `f' could expand to `(get-f)' instead of > `proc', and maybe there's a way for a single assignment to adjust both > `core' and `(get-f)', but I don't quite see it --- at least not without > destroying the direct use of `core' that enables inlining in common > cases. > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
