[racket-dev] Constructing an identifier to an unexported binding

On Thu, May 23, 2013 at 2:29 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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?

You're probably thinking of `require/expose`. This isn't the same
feature, because it gives you the right value, but not the right
identifier. But it works similarly to the way the code Eric posted now
works, using namespaces explicitly.

>
> 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?

No. We can't specify types inside `racket/base` without making
`racket/base` depend on Typed Racket.

Sam

>
>
>
>
>
>
>
>
> On May 23, 2013, at 9:22 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>
>> On Thu, May 23, 2013 at 1:54 PM, Matthias Felleisen
>> <matthias at 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
>