Expansion and "enriching"

In Racket Mode I have a cache of fully expanded syntax. Some users of the cache need it to be "enriched", as done by expand (as opposed to expand-syntax).

In one case I want to "warm" the cache from a compiled load handler, which uses a compile handler, which expects un-enriched syntax (AFAICT) --- so I need to use expand-syntax. The question is, for the cache, can I reuse some of that work done by expand-syntax, i.e. avoid doing a whole other expand from scratch?

  1. One idea is (expand (expand-syntax stx)). This seems safest (?). The idea is that expand will avoid expansion work per se (stx is already fully expanded by expand-syntax). But expand might need to navigate a huge fully-expanded syntax object (?). So probably I should thunk that, to do only if/as/when needed. This isn't terribly tricky, but it's a complication.

  2. I wonder if (namespace-syntax-introduce (expand-syntax stx)) would suffice (and be faster, so no need to delay thunk etc.) On Slack someone pointed out that expand is really (expand-syntax (namespace-syntax-introduce stx)), not (namespace-syntax-introduce (expand-syntax stx)). So this wouldn't be the same order. But does it matter? After all, this seems to be what eval (as opposed to eval-syntax) does, in case it gets un-enriched syntax from expand-syntax. Can't I just do the same?

And so I have a commit ready that does the first thing, and "it works" (more testing needed). But I just wonder if I'm needlessly complicating it and the second thing (or some third way?) would suffice.

1 Like

In one case I want to "warm" the cache from a compiled load handler, which uses a compile handler, which expects un-enriched syntax (AFAICT)

After thinking more and looking at more Racket source, I think it's fine for the compile handler to just go ahead and do the full expand. The default compile handler does that anyway, (expand-syntax (namespace-syntax-introduce stx)) ~= (expand stx).

So it's fine both to put that same value in the cache and return it from the compile handler.