But Casey says the _client_ broke the contract. It's irrelevant where things come from when the client breaks the contracts.
On Jan 16, 2011, at 11:06 PM, Carl Eastlund wrote: > On Sun, Jan 16, 2011 at 11:03 PM, Matthias Felleisen > <matth...@ccs.neu.edu> wrote: >> >> On Jan 15, 2011, at 5:05 PM, Casey Klein wrote: >> >>> On Sat, Jan 15, 2011 at 11:26 AM, Stevie Strickland >>> <sstri...@ccs.neu.edu> wrote: >>>> On Jan 15, 2011, at 12:19 PM, Robby Findler wrote: >>>>> I think that we are just throwing up stumbling blocks. It is really a >>>>> design choice (does a reprovide "carry over" the contract or does it >>>>> put a new one on there?) and I seriously doubt there are any places >>>>> where someone does a reprovide intending to change the contract in >>>>> this manner. To the contrary, I expect that nearly every place where >>>>> someone does a reprovide, they indented to use the exact same contract >>>>> (with different parties now). >>>> >>>> This is possible, but _which_ parties? Do you wish to export internals >>>> through an external interface that should now take on the positive blame, >>>> so that you don't leak your internals (via module names and such used as >>>> blame parties)? This seems to me what you'd want for something like redex >>>> [...] >>> >>> No, that's not the use case. >>> >>> There are three modules, each of which is an external interface: >>> >>> 1. redex/reduction-semantics, which provides the non-GUI portion of Redex, >>> 2. redex/pict, which provides the typesetting utilities, and >>> 3. redex, which provides all of redex/reduction-semantics and >>> redex/pict, plus some more. >>> >>> The redex module does an all-from-out provide on what it gets from >>> redex/reduction-semantics and redex/pict, making it the negative party >>> on the contracts. When a redex client breaks one of the contracts, >>> redex gets blamed instead of the client. >> >> This sounds like a plain bug. > > That's not a bug. The redex module entered into a contract, then > passed those values on to the client without protecting them at all. > If something goes wrong, redex is to blame. > > --Carl _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
