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

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