I'm not completely clear here: Stevie seems to be talking about some more general purpose operation and I don't see much of a connection to the issue of what happens with re-provided bindings. While I agree that other operation is what happens "under the hood" for my proposed change to re-provided bindings, I don't see why that is relevant to the design decision of how re-provided bindings should behave.
So, let me ask this: Stevie, do you think that the current world for re-provided bindings is the right design decision (ie act as if they were all written like (provide/contract [f any/c])), or do you think this change I'm suggesting (act as if the contract were written a second time) is the right behavior (assuming we can solve the performance and single-binding issues Carl raised). Matthias: ditto. Robby On Sat, Jan 15, 2011 at 11:49 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > I am totally with you. (I don't understand how you can satisfy Carl's > scenario and keep it inexpensive but all the power to you.) > > > > > On Jan 15, 2011, at 12:42 PM, Stevie Strickland wrote: > >> On Jan 15, 2011, at 12:32 PM, Robby Findler wrote: >>> But I don't think we should think of it as 'changing the positive >>> blame information' -- I agree anything phrased like that sounds wrong. >> >> But I think you _do_ want this in some cases, where you're reproviding >> internally contracted things to an outside world, and don't want specifics >> of your implementation to leak. Again, this seems to be what you'd actually >> want for redex, right? You're reproviding things you've contracted >> internally (to make sure you are using them appropriately in your >> implementation) to the outside world, and at this point there's no reason >> for the outside world to know that the function `redex-mangle-names' is >> defined in the module contained in the file >> $PLTHOME/collects/redex/private/mangler/nomnomnom.rkt; it'd be better for >> the user if the blame was just the current blame you'd get if it were >> contracted in the external interface, or maybe even something like >> `(collection redex)'. >> >>> Instead, I think we should be thinking "what is (provide f) shorthand >>> for?". In the past I argued it was shorthand for "(provide/contract [f >>> any/c])" but now I think that maybe we should be thinking of it as >>> "(provide/contract [f >>> <the-contract-f-was-imported-with-or-any/c-if-there-wasn't-one>])". >>> >>> Does that make more sense? >> >> I do understand what you're saying. Whether or not we made that change >> (which pretty much puts us back in the old negative blame calculation >> world), I'm just wondering whether we also want an operation like that I've >> described above for use in collects, PLaneT packages, and the like. >> However, that one really would need to be explicit, since you wouldn't want >> it to happen all the time. (And to be fair, I'd still argue it'd be the >> right thing for the re-exporting that you're describing for redex, where >> you're re-exporting internal values to the outside world for use.) >> >> Stevie >> _________________________________________________ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
