Both reasons. I know the existing code is safe, but in my opinion pattern match warnings usually (often?) show that there's a better way to do things. In this case, having a type for non-empty stacks seems like a good thing, so you can then write functions that expicitely rely on this property, the type checker (rather than Catch) will ensure that they are never used unsafely. Plus, I like the Maybe monad and the pretty things you can do with it. Stack+modify looks basically like a poor reimplementation of parts of the Maybe module. e.g. finding all non-empty stacks (from a list of stacks) would just be a catMaybes. It's an easy function that's already written. David P.S. A more accurate translation of (modify d f x) would be ((fmap f x) `mplus` d)... but probably less useful than (Just . maybe d . fmap f). On Wed, May 23, 2007 at 09:22:38PM +0100, Neil Mitchell wrote:

Hi David,

I assume the warnings you are referring to in the subject are incomplete pattern matches? Catch has generated a proof that the pattern-match warnings are completely spurious. Also note that things like "head []" don't generate pattern-match warnings, despite being completely _|_. Perhaps {-# OPTIONS_GHC -fnowarn-pattern-match #-} is sensible to add, given you know its safe anyway.

If the reason is to make the code cleaner, then its still a good idea, of course.

Thanks

Neil

...

type Stack a = Maybe (NonEmptyStack a) data NonEmptyStack a = Node { focus :: !a -- focused thing in this set , left :: [a] -- clowns to the left , right :: [a] } -- jokers to the right

Then (modify Empty f) could just be (fmap f), and (modify d f) becomes (Just . maybe d . fmap f), which seems cleaner to me. This also allows nice use of pattern matching in the Maybe monad.

I like Maybe.