Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?

3 Dec 2009

      On Thu, 2009-12-03 at 12:34 +0100, Ketil Malde wrote:
...
Duncan Coutts  writes:
...
...
[1] http://hackage.haskell.org/package/failable-list
...
Nice.
I agree this is needed (or rather, would be nice to standardise).
Although I don't care for the cutesy naming suggested in the 'Train'
datatype, failable-list could be made more general.  Why is there a
specific constructor 'Done', instead of just allowing the user to select
a value of type 'e' (using 'Maybe b' if nothing else works)?
Perhaps we could also consider an infix notation, like:
data TerminatedList a e = Then a (TerminatedList a e)
                          | Finally e
(So you could do e.g:  4 `Then` 5 `Then` 1 `Finally` "success!". Of
course, you might prefer symbols instead.)
I agree the naming could do with some work and it's worth trying a few
variants to see what seems nicest.

I've got an open mind on the suggestion to amalgamate the two ways the
list could end. I'm not especially in favour of generalising for the
sake of generalising, especially if it looses the connection to the
notion of annotating your "ordinary" data structure with extra errors.
If I effectively always have to use an Either for the final value then
perhaps it does not buy anything and just makes the folds uglier (since
it might loose the connection with the ordinary fold). But it could make
even that use case simpler so it's worth looking at in a few examples
(eg the tar package).

Note that another similar use case is lazy progress reporting. In
cabal-install's dependency solver I've used:

-- | A type to represent the unfolding of an expensive long running
-- calculation that may fail. We may get intermediate steps before the 
-- final result which may be used to indicate progress and/or logging
-- messages.
--
data Progress step fail done = Step step (Progress step fail done)
                             | Fail fail
                             | Done done

It's a difference in emphasis but I think it may also have a different
Monad instance since we consider Progress to be a single value, not a
list. It's like the Either error monad but with extra writer style
logging.

Duncan