<br><div class="gmail_quote">On Mon, Dec 6, 2010 at 9:35 AM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Stevie Strickland wrote at 12/06/2010 11:58 AM:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br></div>
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.)<br>
</blockquote><div><br></div><div>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: </div><div><ol>
<li>accept inputs in particular formats </li><li>validate the input's soundness - if fails, reject the input </li><li>if successful - pass the input through </li></ol><div>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. </div>
</div><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Cheers,</div><div>yc</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>