[racket-dev] Blame and re-provided bindings

On Fri, Jan 14, 2011 at 8:32 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> On Fri, Jan 14, 2011 at 5:10 PM, Casey Klein
> <clklein at eecs.northwestern.edu> wrote:
>> On Fri, Jan 14, 2011 at 4:35 PM, Stevie Strickland <sstrickl at ccs.neu.edu> 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