haskell programming guidelines

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

haskell programming guidelines

Christian Maeder
Hi,

haskell admits many programming styles and I find it important that
several developers of a prject agree on a certain style to ease code review.

I've set up guidelines (still as plain text) for our (hets) project in

http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt

These were inspired by C programming guidelines,
http://haskell.org/hawiki/ThingsToAvoid and the problems I came across
myself.

It like to get comments or proposals for our or other haskell
grogramming guidelines.

Thanks Christian
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Henning Thielemann

On Mon, 20 Feb 2006, Christian Maeder wrote:

> I've set up guidelines (still as plain text) for our (hets) project in
>
> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt

It seems we share the preference for 'case', 'let', 'map', 'filter' and
'fold'. :-)

I prefer a definite choice between all_lower_case_with_underscore and
camelCase identifier style.

'you should probably"'  -- should probably what?

Is the function size restriction still sensible for Haskell? I think
Haskell functions should be at most a few lines, but not "one or two
screenfuls of text".

formJust -> fromJust


> These were inspired by C programming guidelines,
> http://haskell.org/hawiki/ThingsToAvoid and the problems I came across
> myself.
>
> It like to get comments or proposals for our or other haskell grogramming
> guidelines.

http://www.haskell.org/hawiki/UsingQualifiedNames
http://www.haskell.org/hawiki/PairsOfIdentifiers
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Christian Maeder
Henning Thielemann wrote:
> I prefer a definite choice between all_lower_case_with_underscore and
> camelCase identifier style.

me too and I prefer camlCase (but it was too late already, when I wrote
these guidelines)

> 'you should probably"'  -- should probably what?

you should look into the section "Good Programming Practice" (i.e.
decompose your stuff, but I'll rephrase that)

> Is the function size restriction still sensible for Haskell? I think
> Haskell functions should be at most a few lines, but not "one or two
> screenfuls of text".

good point.

> http://www.haskell.org/hawiki/UsingQualifiedNames

When reading (compilable) code unqualified names can be looked up using
the haddock index.

> http://www.haskell.org/hawiki/PairsOfIdentifiers

What about the pair (insert, delete) from Data.Set and Map?

Thanks for your comments
Christian
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Bugzilla from robdockins@fastmail.fm
In reply to this post by Christian Maeder

On Feb 20, 2006, at 12:48 PM, Christian Maeder wrote:

> Hi,
>
> haskell admits many programming styles and I find it important that  
> several developers of a prject agree on a certain style to ease  
> code review.
>
> I've set up guidelines (still as plain text) for our (hets) project in
>
> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/ 
> CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-
> Guidelines.txt
>
> These were inspired by C programming guidelines, http://haskell.org/ 
> hawiki/ThingsToAvoid and the problems I came across myself.
>
> It like to get comments or proposals for our or other haskell  
> grogramming guidelines.

I personally disagree with your preference for custom datatypes with  
a value representing failure to lifting types with Maybe.  I tend to  
like using the Maybe monad for composing large partial functions from  
smaller ones, but your suggestion makes that impossible.  Also, if  
you bake in your failure case into your datatype, you can't use the  
type system to differentiate explicitly partial functions (which use  
Maybe X), from ones that are not expected to be partial (which just  
use X).  Final point, using Maybe gives you an easy route to go to  
"Either String X" or some other richer monad to represent failure.



Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Henning Thielemann

On Mon, 20 Feb 2006, Robert Dockins wrote:

> I personally disagree with your preference for custom datatypes with a value
> representing failure to lifting types with Maybe.

I understood that part of the guidelines as a pleading for Maybe.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Bugzilla from robdockins@fastmail.fm

On Feb 20, 2006, at 2:26 PM, Henning Thielemann wrote:
> On Mon, 20 Feb 2006, Robert Dockins wrote:
>
>> I personally disagree with your preference for custom datatypes  
>> with a value representing failure to lifting types with Maybe.
>
> I understood that part of the guidelines as a pleading for Maybe.

Humm.  Well clearly I read it the opposite way.  I suppose that means  
that whatever technique is being recommended should be put forth with  
more clarity ;-)



Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

ajb@spamcop.net
In reply to this post by Christian Maeder
G'day.

Quoting Christian Maeder <[hidden email]>:

>
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt

As mentioned in an earlier discussion, I strongly disapprove of the use
of multiple ($) applications in the same expression.  Or, for that matter,
most uses of ($).  I also disapprove of avoiding parentheses for the hell
of it.

The guideline that I use is: If what you are expressing is a chain of
function applications, the correct operator to express this is function
composition.  Low-priority application may then be used to apply this
composed function to an argument.

So, for example, f (g (h x)) can be expressed well as:

    f . g $ h x          -- only use if you need to distinguish h
    f . g . h $ x        -- better

And poorly as:

    f $ g $ h x
    f $ g $ h $ x
    (f . g . h) $ x      -- except as an intermediate step in refactoring

Cheers,
Andrew Bromage
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Donald Bruce Stewart
In reply to this post by Christian Maeder
maeder:
> Hi,
>
> haskell admits many programming styles and I find it important that
> several developers of a prject agree on a certain style to ease code review.
>
> I've set up guidelines (still as plain text) for our (hets) project in

Perhas you'd like to put up a Style page on thew new Haskell wiki,
perhaps under the Idioms category?

You could take some hints from the old style page, http://www.haskell.org/hawiki/HaskellStyle

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

John Meacham
In reply to this post by Christian Maeder
There is a more straightforward way to get localized error messages
rather than using 'maybe' and hand-writing an appropriate error, and
that is to rely on irrefutable bindings.

f x = ... y ... where
        Just y = Map.lookup x theMap

now if the lookup fails you automatically get an error message pointing
to the exact line number of the failure. or if the failure message of
the routine is more important than the source location you can do

f x = ... y ... where
        Identity y = Map.lookup x theMap

it is anoying you have to make a choice between these two possibilities,
but this can be mitigated with CPP magic or the SRCLOC_ANNOTATE pragma.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Christian Maeder
In reply to this post by Donald Bruce Stewart
Donald Bruce Stewart wrote:
> Perhas you'd like to put up a Style page on thew new Haskell wiki,
> perhaps under the Idioms category?

I cannot promise it, but I'll try. If someone else is willing to do it,
I would support this.

Rob Dockins wrote:
>> I understood that part of the guidelines as a pleading for Maybe.
>
> Humm.  Well clearly I read it the opposite way.  I suppose that means  that whatever technique is being recommended should be put forth with  more clarity ;-)

done (use Maybe or another Monad)

Andrew Bromage wrote:
> So, for example, f (g (h x)) can be expressed well as:
>
>     f . g $ h x          -- only use if you need to distinguish h
>     f . g . h $ x        -- better

I see this differently. Expressions may be succinct! I find "$" and "."
similar enough for non-obfuscation. But I collect cases where "$" does
not work (i.e. for the kind #). Bad would be cases where "$" works
differently than (reasonably) expected.

John Meacham wrote:
> f x = ... y ... where
>         Just y = Map.lookup x theMap
>
> now if the lookup fails you automatically get an error message pointing
> to the exact line number of the failure. or if the failure message of
> the routine is more important than the source location you can do
>
> f x = ... y ... where
>         Identity y = Map.lookup x theMap

These are potential runtime errors, that may be not so obvious to see in
the source (ie. for user defined types) and even the compiler (ghc) does
not emit a warning.

Thanks for all your comments
Christian
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: haskell programming guidelines

John Meacham
On Wed, Feb 22, 2006 at 01:14:41PM +0100, Christian Maeder wrote:

> John Meacham wrote:
> >f x = ... y ... where
> >        Just y = Map.lookup x theMap
> >
> >now if the lookup fails you automatically get an error message pointing
> >to the exact line number of the failure. or if the failure message of
> >the routine is more important than the source location you can do
> >
> >f x = ... y ... where
> >        Identity y = Map.lookup x theMap
>
> These are potential runtime errors, that may be not so obvious to see in
> the source (ie. for user defined types) and even the compiler (ghc) does
> not emit a warning.

Indeed, that is the entire point of the construct. ghc definitly should
not emit a warning in this case as it is what lazy pattern matching
is for.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: haskell programming guidelines

ajb@spamcop.net
In reply to this post by Christian Maeder
G'day all.

Quoting Christian Maeder <[hidden email]>:

> I see this differently. Expressions may be succinct! I find "$" and "."
> similar enough for non-obfuscation.

But they're _not_ similar!

Compare this notation:

    f . g . h $ x

with the one you suggested:

    f $ g $ h $ x

Advantages of the first one:

    - Encourages the idea that there is function composition going on.
      Function composition is one of the features of functional
      programming, so this should be highly encouraged.

    - Protects your code against the day when the committee realises that
      ($) has the wrong associativity.  (It's the opposite of what you'd
      expect, since normal function application is left-associative.)

Disadvantages:

    - None whatsoever.  It's just as succinct and uses just as many
      parentheses.

Cheers,
Andrew Bromage
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Christian Maeder
[hidden email] wrote:
> Compare this notation:
>
>     f . g . h $ x
>
> with the one you suggested:
>
>     f $ g $ h $ x

I suggested:

       f . g $ h x

or
       f $ g $ h x

Christian


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Christian Maeder
In reply to this post by John Meacham
John Meacham wrote:
>>>        Identity y = Map.lookup x theMap
>> These are potential runtime errors, that may be not so obvious to see in
>> the source (ie. for user defined types) and even the compiler (ghc) does
>> not emit a warning.
>
> Indeed, that is the entire point of the construct. ghc definitly should
> not emit a warning in this case as it is what lazy pattern matching
> is for.

I prefer to be explicit about this kind of partiality (by using 'error
"<qualified function name>"')

Christian
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

John Meacham
On Thu, Feb 23, 2006 at 11:16:11AM +0100, Christian Maeder wrote:

> John Meacham wrote:
> >>>       Identity y = Map.lookup x theMap
> >>These are potential runtime errors, that may be not so obvious to see in
> >>the source (ie. for user defined types) and even the compiler (ghc) does
> >>not emit a warning.
> >
> >Indeed, that is the entire point of the construct. ghc definitly should
> >not emit a warning in this case as it is what lazy pattern matching
> >is for.
>
> I prefer to be explicit about this kind of partiality (by using 'error
> "<qualified function name>"')

I prefer the exact opposite :)

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Cale Gibbard
In reply to this post by John Meacham
On 20/02/06, John Meacham <[hidden email]> wrote:

> There is a more straightforward way to get localized error messages
> rather than using 'maybe' and hand-writing an appropriate error, and
> that is to rely on irrefutable bindings.
>
> f x = ... y ... where
>         Just y = Map.lookup x theMap
>
> now if the lookup fails you automatically get an error message pointing
> to the exact line number of the failure. or if the failure message of
> the routine is more important than the source location you can do
>
> f x = ... y ... where
>         Identity y = Map.lookup x theMap
>
> it is anoying you have to make a choice between these two possibilities,
> but this can be mitigated with CPP magic or the SRCLOC_ANNOTATE pragma.
>
>         John
>

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.

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

John Meacham
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

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Cale Gibbard
On 24/02/06, John Meacham <[hidden email]> 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

John Meacham
On Mon, Feb 27, 2006 at 10:57:17PM -0500, Cale Gibbard wrote:
> 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


Yes, this is what jhc's SRCLOC_ANNOTATE addreses, more or less.

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

Well, the benefit of the Identity monad is so that the user of a routine
can choose to recover gracefully by using a different monad, you only
use the Identity monad when you are making a choice to bottom out on
errors. using 'error' directly is not an option in said cases because it
would take away the ability of the user of a routine to catch errors
properly. error should only be used for reporting bugs that should never
happen, not user visible failure.

The writer of a library shouldn't decide how (non-buggy) failure should
be handled, the user of it should.

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

I know you keep saying this, We start with the exact same premises and
goals, yet somehow come to the exact opposite conclusion. I have not
quite figured out why.

However, a quick survey shows that _every single_ monad defined in the
standard and fptools libraries has an interesting non-error 'fail'
method other than Identity, whose sole purpose is to turn 'fail's into
errors.  Separating out a MonadError with 'fail' seems rather odd as
every monad will be an instance of it! (including Identity, since
turning fails into errors is its main purpose)

(the monads like 'Reader' and 'Writer' are actually just shorthand for
ReaderT a Identity, the inner monad determines the failure mode)

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: haskell programming guidelines

Cale Gibbard
On 27/02/06, John Meacham <[hidden email]> wrote:

> On Mon, Feb 27, 2006 at 10:57:17PM -0500, Cale Gibbard wrote:
> > 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
>
>
> Yes, this is what jhc's SRCLOC_ANNOTATE addreses, more or less.
>
> > 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).
>
> Well, the benefit of the Identity monad is so that the user of a routine
> can choose to recover gracefully by using a different monad, you only
> use the Identity monad when you are making a choice to bottom out on
> errors. using 'error' directly is not an option in said cases because it
> would take away the ability of the user of a routine to catch errors
> properly. error should only be used for reporting bugs that should never
> happen, not user visible failure.

I'd argue that it would be better for the user to simply catch the
value returned which indicates error explicitly, and throw the error
themselves. This indicates that they have put thought into the fact
that the function may fail.

> The writer of a library shouldn't decide how (non-buggy) failure should
> be handled, the user of it should.

Right, which is why minimal types for expressing the failure should be
used, and the user should convert from those types to whatever larger
environment they have in mind. If your function is simply partial, use
Maybe, if you want to report error strings, use Either String. These
types easily lift into any monad which support similar functionality.
It also gives the users of your library more information about the
exact way in which your functions may fail, just by looking at the
type signatures, and gets them thinking about handling that failure.
An arbitrary monad m doesn't indicate anything about the failure modes
present.

>
> > 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.
>
> I know you keep saying this, We start with the exact same premises and
> goals, yet somehow come to the exact opposite conclusion. I have not
> quite figured out why.
>
> However, a quick survey shows that _every single_ monad defined in the
> standard and fptools libraries has an interesting non-error 'fail'
> method other than Identity, whose sole purpose is to turn 'fail's into
> errors.  Separating out a MonadError with 'fail' seems rather odd as
> every monad will be an instance of it! (including Identity, since
> turning fails into errors is its main purpose)
>
> (the monads like 'Reader' and 'Writer' are actually just shorthand for
> ReaderT a Identity, the inner monad determines the failure mode)
>
>         John

Well, that means that Reader, Writer and State, and any monad based
upon them or their transformers does not have a meaningful fail. IO
also does not have an interesting fail. It also means that all custom
monads based on state transformers, say, don't have interesting fails.
This is a very large chunk of the monads which people use in everyday
code! The List monad and Maybe monad have nice fails, and that's why
they should be in MonadZero.

I disagree that Identity, Reader, Writer, or State should be an
instance of MonadError or MonadZero. They should simply not be used
for that purpose. I'd like a monad hierarchy where if there is an
instance of a class for a monad, then none of the methods of that
class are identically bottom. It seems disingenuous to me to say that
some type constructor implements certain functionality, and then
implement it in a way which crashes the program. If you need failure
in your monad, add it explicitly via a transformer, and if you use
failure, you should express that via a class. Types and classes should
be meaningful and informative about this sort of thing.

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12