Re: [Caml-list] Purity and lazyness

[Petter Urkedal <paurkedal@gmail.com>]

On 2011-01-08, Florian Weimer wrote:
> * Elias Gabriel Amaral da Silva:
> 
> >> As specified, Haskell is not a pure language because every pattern
> >> match can have side effects.  The Haskell community is split between
> >> those who think that this is a good thing, and those that consider it
> >> problematic.  (Obviously, there is a large pure subset, much more
> >> useful than Erlang's pure subset and covering almost the whole
> >> language; you just avoid lazy I/O and use unsafePerformIO only for
> >> correcting the type of functions imported through FFI.)
> >
> > Wait, a pattern match can have side effects? Can you provide some
> > example code? (do you mean, pattern match failure / exceptions / run
> > time errors?)
> 
> <http://article.gmane.org/gmane.comp.lang.haskell.prime/3083>
> 
> It uses seq instead of pattern matches for clarity.  But laziness
> means that you could hide the side effect in any pattern match
> whatsoever.

Do you mean that pattern matching could be used instead of seq in this
example?  But the example is do demonstrate that hGetContents has side
effects, whereas seq is only used to force two different evaluation
orders.

IIUC, the issue with pattern matching is that it may throw an exception,
and exceptions are impure because *if* and *where* they are thrown is
hard to predict, and may affect the outcome of a program witch tries to
catch it.

My experience with Haskell is limited, but I suspect a pattern matching
failure is to be considered a bug, and that the exception mechanism
doubles as a software diagnostic system, like in many languages.  That
is, a program should not try to catch those exceptions, except at the
for bug-reporting and recovery purposes.  From this point of view,
shouldn't a pattern match be considered pure in a bug-free program?