1. At some point, we had a macro that opened up modules and made all module-level identifiers available. Wouldn't a flavor of this macro work here and, if so, wouldn't it be cheaper? Or is this what you call dumpster-diving, traversing the expansion and extracting ids from there?
2. Is it possible that we could solve the problem via a bootstrapping-only violation of our policy that you can add types to Racket w/o modifying existing modules? On May 23, 2013, at 9:22 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote: > On Thu, May 23, 2013 at 1:54 PM, Matthias Felleisen > <matth...@ccs.neu.edu> wrote: >> Can you raise the level of discourse one level and perhaps figure out >> whether this is needed at all? I.e., find a different way to solve the >> problem? (What is the real problem?) > > This is important, and it's the second implementation of this feature. > The previous one was substantially more painful, and involved > local-expand and "dumpster-diving". > > The reason we need a tool like this is that the expansion of some > macros (examples include `for`, `delay`, `quasiquote`, among others) > have runtime support functions that are not exported. Typed Racket > needs to specify the type of these operations. You can see these > specifications here: > https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-special-env.rkt > . That means that it needs to construct those identifiers, although it > never needs to execute code with those identifiers. > > The previous implementation was much slower here, remarkably. > > Sam _________________________ Racket Developers list: http://lists.racket-lang.org/dev
