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

[wren ng thornton]

Duncan Coutts wrote:
> 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).

These days I view folds as automatically defined by the data type, so I 
don't see any reason (on those grounds) to want to compare it to lists' 
foldr as opposed to any other arbitrary catamorphism.

One reason to prefer a single basis is that it simplifies the ability to 
do concatenation and the associated fusion. It still only has one 
termination point (unlike trees) so it's still possible to do augment 
fusion. But because there are two bases, concatenation needs to look 
like this:

     concat2 :: T a b -> (b -> T a b) -> T a b -> T a b

Whereas for the version with no Nil, it's just:

     concat1 :: T a b -> (b -> T a b) -> T a b

As for the usage, we'd be comparing these two:

     concat2 foo handler bar

     concat1 foo (maybe bar handler)

One of the nice things about not having a Nil is that it lets you easily 
be polymorphic over things ending in () ---a normal list---, (Maybe a) 
---a fallible list---, (Either a b) ---your progress type---, etc. 
Whereas the version that has both Nil and End forces us into the (Maybe 
a) scenario. A side effect of this is that the (Either a b) option isn't 
available because we can only construct t=Mx.(x*t)+(1+a+b) not 
t=Mx.(x*t)+(a+b).

-- 
Live well,
~wren