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
