The problem, and we've been through this before, is that it's very tempting to use types like Maybe because it's there, when it's better replaced with a custom algebraic data type.
i'm sure we have, and others before us. i was just arguing that one is not necessarily better than the other. i'm not using Maybe because its there, i tend to use Monad, so my code would work on either Maybe or your custom type, if they both implement the interface that allows me to encode and capture failure (and i need that interface, because i want to program with patterns and match failure in ways not hardcoded into the language syntax). of course, you might say that we shouldn't use Monad just because it is there, and that we should always define our own, more descriptive class with the same semantics?-) having descriptively named types is fine, but unless you really want to emphasize and verify that your Maybe is different from all other Maybes (in which case a newtype + deriving might be more suitable than a completely separate type), using Maybe encodes (by convention) the intended semantics, thus making code easier to comprehend. the question, i guess, is whether you want to communicate to readers of your code that your type is like Maybe, but distinguishable, or that it is an entirely new type, with some similarities to Maybe. specific names have to be offset against reuse of general understanding, but language features for combining both exist (if not as widely supported as they could be; nor as expressive as one might want, eg. one can rename constructors for expressions, but not deconstructors for patterns, which is why Connor keeps asking for pattern synonyms, or why i'd like to use view patterns for abstract deconstructors, with those funny Maybes behind the scenes..). claus