[racket-dev] Blame and re-provided bindings

On Mon, Jan 17, 2011 at 9:28 AM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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.

I refer you to Casey's message again. That isn't possible in general.
You'd have to go to a much more complex setup, introducing another
layer of files.

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

Yes and I said so in my message too.

Robby