Re: [racket-dev] Blame and re-provided bindings
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. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
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
Re: [racket-dev] Blame and re-provided bindings
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
Re: [racket-dev] Blame and re-provided bindings
This sentence makes no sense to me. Contracts are all about where things come from. How can it be irrelevant? On Sun, Jan 16, 2011 at 11:12 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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
