[Haskell-cafe] haskell programming guidelines

[Cale Gibbard]

On 24/02/06, John Meacham <john at repetae.net> wrote:
> On Fri, Feb 24, 2006 at 12:39:27PM -0500, Cale Gibbard wrote:
> > I look at the above as generating a proof obligation for me as the
> > programmer that the lookup will never fail, or at least the ability to
> > convince myself. :) If you want to handle errors, you should actually
> > handle them, not let your users get "Irrefutable pattern failed"
> > messages. Also, if someone else later comes along and wants to catch
> > that error, they have to either do it in IO, which can be fiddly if
> > the error occurs deep in the evaluation of some structure, or they
> > refactor your code so that it returns the error explicitly. Sure,
> > irrefutable pattern matches are useful, but they shouldn't be used if
> > you expect they'll ever fail.
>
> Ah, perhaps I wasn't clear. I don't ever expect these to fail. The
> reason I prefer irrefutable pattern matches to handwritten 'error'
> messages (at first) is so many months later when I introduce a subtle
> heisenbug I don't get a
>
> error: This shouldn't happen
> or worse
> error: Prelude.undefined
>
> but rather a nice error pointing right to the line number.
>
> anything I ever expect to fail for any reason other than a bug I put in
> a failing Monad with a suitably user digestable error message. So, I was
> comparing them to handwritten 'error' messages for announcing
> programming bugs. not handwritten 'error' messages for users to see
> (which really should be using 'fail' in a monad anyway).
>
>         John
>
Well, this is an issue. Perhaps a version of error which makes the
line/column number available to its parameter would help... something
along the lines of

type SourcePos = (Integer, Integer)
    -- possibly a data/newtype with a nicer Show instance
errorPos :: (SourcePos -> String) -> a

This would give all the benefits normally acquired from the expansion
of the syntax sugar while allowing you to additionally add any extra
messages you'd like. Further, you'd not be required to work in, say
the identity monad, in order to get line number messages for failures
(though in GHC at least, irrefutable pattern match failures in lambdas
and let also get line numbered).

I'm actually really against the inclusion of fail in the Monad class,
so finding a reasonable replacement for any constructive uses it might
have had is important to me.

 - Cale