[racket-dev] Removing Xexpr preference from Web Server

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Mon Dec 6 12:35:32 EST 2010

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?")


Posted on the dev mailing list.