[racket-dev] Blame and re-provided bindings

On Jan 17, 2011, at 10:10 AM, Robby Findler wrote:

> On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>> On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>> So far as I understand it, we have: Stevie opposed, Matthias neutral,
>>> Robby and Casey for, with everyone agreeing that we should try to
>>> preserve the "Carl constraints" of 'single contract wrapper' and 'same
>>> identifier-ness'.
>>> 
>>> Note that in the current world we are *forced* to break the first of
>>> the Carl constraints. So I consider this a bonus if we achieve it (and
>>> so if we don't in some cases, I don't think we should care).
>>> 
>>> Is that a correct summary of the status?
>> 
>> Given the performance impacts of rewrapping, it seems like solving
>> that problem should be a prerequisite for changing the semantics of
>> `provide' to automatically add non-trivial contracts.  I think it
>> would be pretty problematic to suddenly add repeated list traversals
>> to any code that reprovides identifiers.
> 
> At the moment, we're force to rewrap to get the right semantics.
> 
> That is, show me a (real) module that re-exports contracts with any/c
> and I'll show you a way to blame that module and the solution will
> have to be a rewrapping (or a moving of the contracts). And I'm
> talking about real code, not made up examples, of course.


My hunch is that the proper response to Sam is to remove the 
contracts from 'private' modules to reduce the double hit. In 
a sense I was hoping that this would happen if we forced deveoplers
to re-state the contract if re-provide means any/c. But I guess this 
is not going to happen. 

But I do see Sam's reply as another argument against implicit 
rewrapping given the implicit performance hit.