Putting aside the 8 (yeah, really) ways to report errors in Haskell, this is the option provided by the Maybe (data Maybe a = Something a | Nothing). While I see many benefits to this approach, I think contracts may provide a new way out. In most typed languages the major constraint seems to be that types are checked at compile time and limited in complexity. Contracts, however, have practically unlimited power. The trick is that one would have to incorporate some way to reify the calculation checked by the contract. If you could get a hold of the value produced by contract checking then no duplicate computation would have to occur inside the function. This is especially relevant for functions like string->number because the most obvious implementation checks validity during parsing -- checking the validity and parsing basically duplicate the function. <div>
<br></div><div>Also, if one sees a sort of "inner" function post-contract-check and an outer function including the contract check then one could even term the inner function as total and the outer function as partial.<div>
<br></div><div>The advantages of this approach, as far as I can see, are that it removes large amounts of failure checking and it encourages large amounts of precondition code to move into the contract. Not only is this good for documentation and interfaces, but it helps with my current project (random testing through contracts).</div>
<div><br></div><div>2c</div><div><br></div><div>Cheers,</div><div>Andy<br><br><div class="gmail_quote">On Tue, Mar 27, 2012 at 5:23 PM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Bug report 12652 reminded me of a topic that I brought up a while back, that I tried to incorporate into the Style Guide, and that I forgot to re-introduce here.<br>
<br>
Background: a lot of people think that consistency in naming, signature/contract, and functionality (for methods and functions) is a key element to successful software projects. If you saw Yaron Minsky's talk at POPL or if you are in a department where he delivered his OCAML is great for trading talk, you know what I mean. He formulates this point well, and he gives good examples.<br>
<br>
Topic: In our world, we have functions such as<br>
<br>
string->number<br>
string->path<br>
string->url<br>
bytes->string/utf-8<br>
<br>
The naming consistency is good, but they aren't really consistent at the signature or functionality level:<br>
<br>
string->number produces #f when called on "hello world" or "\0"<br>
string->path fails on "\0"<br>
string->url succeeds on "\0" and produces a url<br>
<br>
I consider this less than desirable. I understand arguments for #f and exceptional behavior in an ML-style world. In a Racket/Lisp style world, I see the behavior of string->number as ideal. I get two behaviors in one function:<br>
<br>
(1) parsing in the spirit of formal languages (is this 'string' accepted by this 'machine')<br>
(2) translation in the case of success.<br>
<br>
One advantage of such total functions is of course that they are performant. The signatures/contracts are simple and their functionality is easy to figure out. A disadvantage is that they deepen our dependence on occurrence typing, but so what.<br>
<br>
I could also understand providing two versions of the function:<br>
<br>
string->path : String -> Path u False<br>
string->path/exn: String -> Path | effect: exn:fail:contract?<br>
<br>
Q: Would it be worth our while to comb through the libraries and make the world consistent, even breaking backwards compatibility? I would be willing to run such a project.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Matthias<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>