[racket-dev] Removing Xexpr preference from Web Server

On Mon, Dec 6, 2010 at 9:35 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:

> 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.)
>

Coercion can go wrong when it tries to create good value over zealously, but
if applied judiciously it should be the same as input validation, which
performs the following:

   1. accept inputs in particular formats
   2. validate the input's soundness - if fails, reject the input
   3. if successful - pass the input through

Step # 2 is often done as a conversion step, since if the conversion is
successful the value is valid.  And if you have converted the values to an
internal representation already, it makes sense to simply pass on the
internal representation, instead of asking the inner function to do the
conversion again explicitly.

The key is that there isn't a general coercion mechanism, as you do not want
to convert all values into the same representation by tracing all coercible
routes.  But in limited environment it can save quite a bit of typing and
denotes intention clearly like a contract system.

The nice thing about the contract system is that it has the support of the
runtime to assign blame to the correct party, whereas an input validation's
error doesn't tell you who the caller is, so it's harder to track down the
offending input.  So having the ability to assign error to the correct
location provided by the runtime can aid people to develop their own limited
scope coercion mechanism.

Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101206/b514f2d0/attachment.html>