On Fri, Jan 14, 2011 at 8:32 PM, Robby Findler <[email protected]> wrote: > On Fri, Jan 14, 2011 at 5:10 PM, Casey Klein > <[email protected]> wrote: >> On Fri, Jan 14, 2011 at 4:35 PM, Stevie Strickland <[email protected]> >> wrote: >>> On Jan 14, 2011, at 5:24 PM, Casey Klein wrote: >>> >>>> Regardless, though, I still think we need some way to re-export a >>>> contracted value that makes the re-importer the negative party on the >>>> contract. >>> >>> I'm not necessarily in disagreement, but currently I think this should be >>> an explicit action. >> >> Explicit is fine with me. I just want to avoid giving names to all the >> contracts and re-applying them in the re-provider. > > FWIW, I'm currently in the 'implicit' camp. (Yes this is a switch for me.) > > I think that most of the time that you re-provide something you really > wanted to put the same contract on it, so it seems like we should make > that easy. > > Robby
On the other hand, that means the number of requires and provides can seriously impact a program's performance if a function has a computationally intensive contract. I don't think we really want to put hidden "gotchas" into the module system. Also, I occasionally make use of the fact that re-provides are considered "the same binding" by the module system. So if A exports X, and B re-exports that X, C can require both A and B. The duplicate import of X doesn't cause an error because it's the same X. Changing module exports is a little bit easier because of this -- for instance, more than once I have used this property to keep (planet cce/scheme) compatible with changes to the core that added overlapping bindings. Adding a new contract means you suddenly have a different binding, which can be less convenient. --Carl _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
