[Haskell] View patterns in GHC: Request for feedback

Claus Reinke claus.reinke at talk21.com
Wed Jul 25 09:39:53 EDT 2007

> 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..).

More information about the Haskell mailing list