On Dec 6, 2010, at 12:08 PM, Carl Eastlund wrote: > On Mon, Dec 6, 2010 at 11:58 AM, Stevie Strickland <sstri...@ccs.neu.edu> > wrote: >> On Dec 6, 2010, at 11:42 AM, Robby Findler wrote: >>> But this seems to perhaps be developing into something more >>> interesting. Maybe there is something more general than contracts and >>> we should have a contracts+X system that supports that, somehow. >> >> Every time I discuss contracts with a visiting researcher, the first or >> second thing they always ask is, "What if you coerced to a good value >> instead of throwing an error?", so I'm not surprised that Jay indeed wants >> just that. I think he's just found an excellent first use case for it in >> our own system, and so now we should take a look at supporting such, as you >> have said above. > > I'm commenting on the general principle, not Jay's particular case, > but to me the main benefit of the contract system is helping uncover > bugs and giving good feedback about them. This kind of coercion > sounds like it is masking bugs, not uncovering them. It seems > directly counter to the purpose of contracts. In reasoning about > programs in ACL2, where every input is treated as a good input, I find > it harder to reason about the resulting programs, not easier. > Personally I would not want to see Racket go down the same road. If > we're going to have a coercion system, I would like to see a clear > line between the coercion system and the contract system. Muddying > the distinction between the two seems like a big potential problem to > me.
Right, I'm not saying that contracts and coercions should be synonymous in our system. I'm just saying that there are lessons (and subsystems) that we can take from implementing an excellent contract system. If we want, we can apply these lessons to make an excellent coercion system, and perhaps now we _should_ start looking in that direction and see what results. Stevie _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
