On Mon, Jun 21, 2010 at 3:49 PM, Robby Findler <ro...@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 sa...@ccs.neu.edu _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
