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
