On Thu, 2009-12-03 at 19:49 -0500, wren ng thornton wrote:
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.
Sure the fold is defined by the data type, except when we are pretending that one data type is another. This type is intended as a list that is annotated with errors. So I want to be able to switch between list versions and this version just by adding an extra error-handling parameter to the ordinary list fold. As another example of this, consider the VersionRange type in Cabal. It provides two different folds depending on what view you want. Neither matches the underlying constructors exactly. Duncan