[racket-dev] [racket] keyword args static checking and optimization

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Aug 8 11:32:55 EDT 2011

Ah, right. Rats.

Robby

On Mon, Aug 8, 2011 at 10:25 AM, Matthew Flatt <mflatt at 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.
>
>



Posted on the dev mailing list.