[racket-dev] RFC: "provide" via mutation

Oh, I see. Yes, that's tricky.

Robby

On Mon, Jun 21, 2010 at 3:22 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Mon, Jun 21, 2010 at 3:49 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> What is the general class of programs that have this difficulty? (Does
>> it include the example from Matthew's "you want it when?" paper about
>> structs?)
>>
>> I'm not getting why typed racket has to do something special here to
>> deal with this box. That is, by the time typed/racket gets a hold of
>> the expanded program things seems pretty simple. That is, where do the
>> savings come from by disallowing this program?
>
> It's probably easiest to explain this a little more fully.
>
> First, Typed Racket maintains a compile-time, mutable table mapping
> identifiers to their types.  This table is maintained by inserting
> code into each typed module which registers the type of each
> identifier at syntax time.  This is the technique that Matthew
> proposes in "You want it when?".
>
> Second, many of these identifiers can never appear in any other
> modules, and thus shouldn't need to be in the table, nor have their
> types re-registered every time the module is invoked.  In particular,
> unexported identifiers do not usually appear in any other modules.  It
> would be nice to save the code size and initialization time that these
> declarations require.
>
> However, unexported identifiers can appear in macro templates, and
> thus if any macros are exported by the module, all definitions in it
> are accessible.
>
> What Matthew's paper's example shows is that there's use for mappings
> from one value identifier to another, and thus that if any *value* is
> exported, all definitions are accessible.
>
> What the example I posted shows is that even if *nothing at all* is
> exported, all definitions are accessible, which means that the
> optimization I describe above is never safe, for any identifier.
> Similarly, no definition in a module can ever be found to be dead
> code, since it might be "provided" in this way.  This is why, for
> example, Chez has the concept of an 'indirect export', to specify
> which bindings are potentially needed in this fashion, and allow the
> compiler to drop others.  I'm not sure requiring such declarations of
> programmers would be valuable for the benefit of these optimizations,
> though.
>
> --
> sam th
> samth at ccs.neu.edu
>