On Mon, Jan 17, 2011 at 9:28 AM, Matthias Felleisen <[email protected]> wrote: > > On Jan 17, 2011, at 10:10 AM, Robby Findler wrote: > >> On Mon, Jan 17, 2011 at 8:55 AM, Sam Tobin-Hochstadt <[email protected]> >> wrote: >>> On Mon, Jan 17, 2011 at 9:41 AM, Robby Findler >>> <[email protected]> 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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
