You may find these papers relevant, especially the first. (Yes, you can catch and recover from head []!) http://research.microsoft.com/en-us/um/people/simonpj/papers/imprecise-exn.h... http://research.microsoft.com/en-us/um/people/simonpj/papers/asynch-exns.htm Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On | Behalf Of Jack Waugh | Sent: 12 August 2011 20:35 | To: libraries@haskell.org | Subject: Re: There are too many error handling conventions used in library code! | | In re | http://thread.gmane.org/gmane.comp.lang.haskell.libraries/6382 | | I read this thread (as I found it populated on 2011-08-12) | with interest even though I have not written three lines | of Haskell. | | I am trying to invent a programming language with | referential transparency and I am thinking about what | construct(s) it should provide to catch errors. Catching | errors is necessary because I want the language to be | suitable for building systems that run code by various | contributors without trusting the integrity of the system | as a whole to the contributions. Errors should be caught | and reported to the responsible programmers. | | Let "RT" stand for referential transparency or | referentially transparent as grammatically appropriate in | each instance. | | I wanted to learn from the experience with Haskell because | Haskell is one of the few pure functional programming | languages in use (I'm not sure about the ML family, and I'm | pretty sure that Erlang and the E language are not pure). | At least with Haskell I know for sure it is pure, so | I think that the community around Haskell has advanced | understanding of how to go far within a purely RT world. | | So I start poking around to figure out how errors are | caught, and the upshot, from this thread, seems to be, | that errors cannot be caught in Haskell. I see you all | talking about how libraries' APIs should incorporate | error reporting, but these seem like really exceptions | rather than errors, in that you, the library prorammers, | have to plan to detect them and you are just looking | for a non-noisy way to pass them back through the API, | since these "errors" represent cases that for good reason | shouldn't dominate the body of your code (all of us would | prefer, and with excellent reason, that the bulk of our | code reflects programming for the normal and happy cases). | Maybe these error cases you're discussing, some of them, | reflect an error on the part of the programmer of the | _client_ code _calling_ the library, and that's why you | want to use the term "error". But a true programming error | (for example, in the library code) might not be possible | to anticipate and program around; after all, it's an error. | A programming mistake. | | For example, what happens if we try to take the head of | an empty list? Everything dies, right? Haskell won't | catch that, right? | | So, here's what I'm thinking for my language. Every data | type (I don't think I'll need Unit) will have implicitly | some error indications as possible values. | So for example, if an Integer is expected, we might get | an integer, such as 3 | for example, but we could instead receive an error | indication. It should be possible to test explicitly | for an error indication, and on finding one, it should be | possible to test it for membership in various interesting | classes of errors (including programmer-defined ones) and | it should be possible to dig into the error indication and | extract a brief explanation in natural language of what | went wrong. I'm thinking location information such as | source file name (or something like that) and line number | could fit in there as well. | | Functions that are not designed for the explicit purpose of | looking for error cases, for example `+`, would propagate | errors along to their results if such were found in one or | more essential inputs (False && error could return False | rather than the error). | | Now if it looks as though I'm just reinventing | something that a monad can do elegantly, I'm not sure. | The monadic examples I have been seeing all seem to | require the use of the bind function to glue together | the function applications that could encounter an error. | A reader of the code can't tell that the order of the | binds doesn't matter. It looks like I/O code, where the | order definitely does matter. But if I want to return for | example a/b + c/d, and either division could accidentally | attempt to divide by zero, I don't want to specify which | division comes "first" in some chain of binds; that's | overspecification, isn't it? Because the result does | not depend on any ordering of the addends. Addition is | commutative, and it remains commutative if we extend the | domains to include error indications. Error some_specs | + 3 = Error some_specs; 3 + Error some_specs = Error | some_specs; still commutative. | | If I adopt this scheme, have I learned everything I can | about error catching from Haskell and incorporated that | learning into my design? | | I apologize for posting off topic in your thread, but | this is a branching topic closely related to your topic | and if I can get the advice of people who are experienced | in pure functional programming and who have thought about | the problems of error reporting, I might be able to avoid | making some really stupid design mistake. | | I suggest the subject "Learning from Haskell -- Catching | Errors" as the subject for any followups to this message. | | Thanks loads for any response. And if you think my idea | is crackpot, please don't hold back on your opinion. | I am trying to make a useful contribution, and if I am | barking up the wrong tree, that purpose will not be served. | Please feel free to tell me I should read one thing or | another that my question indicates I have missed, before | trying to design a new RT programming language. | | Again, my question is "If I adopt this scheme, have I | learned everything I can about error catching from Haskell | and incorporated that learning into my design?" | | Jack Waugh http://jackwaugh.com/ | | | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries