Stevie Strickland wrote at 12/06/2010 11:58 AM:
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.
If you're talking about recovery from programming errors, I think that's an interesting and hard problem. (Example: programming error results in a bad value, which is detected; you now know that something is wrong, but you might not know the cause or impact, and perhaps coercing to a believed good value just creates a bigger problem.)
Regarding the current backward-compatibility situation being a good use case for a desirable mechanism, it might be, but I think you will want to flesh out the rationale more at some point. (Example devil's advocacy, just to clarify what I mean: "How is this preferable to simply making a new procedure for the new behavior? How does this relate to multiple dispatch? How is this preferable to the way practitioners have been doing backward-compatibility in mainstream OOPLs?")
-- http://www.neilvandyke.org/ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
