Oh, I see. Yes, that's tricky. Robby
On Mon, Jun 21, 2010 at 3:22 PM, Sam Tobin-Hochstadt <[email protected]> wrote: > On Mon, Jun 21, 2010 at 3:49 PM, Robby Findler > <[email protected]> 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 > [email protected] > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
