There are too many error handling conventions used in library code!

[Jack Waugh]

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/