monad library

Thu, 31 Jul 2003 18:59:45 +0100

[sorry for not following this list closely, 
 hope this interjection is appropriate..]

given this recent excitement about Control.Monad and transformers,
this might be a good opportunity to point to a previous thread here:

Have these problems been addressed yet, i.e.:

- separating standard instances of common classes for common types
  from other stuff, unlike in the Monad hierarchy (which surprisingly
  adds instances of Functor/Monad for Either and ((->)a) just because
  those happen to be one way to implement Errors and Environments),

  As Haskell doesn't have parameterized modules, my preference
  would be to single out such instances (and only those which are
  unambiguously standard) in separate modules, which should make
  their contents obvious, and which could be imported by any
  other module needing these instances (without getting other
  stuff as well) *and wishing to export them*. 

- not stealing, e.g., the Monad instance for Either in
  Control.Monad.Error, for a not-quite standard definition.

  My preference would be use of newtype to define, e.g., an
  abstract type in terms of Either, and to have the instances
  defined for that abstract type. Haskell's module system gives
  no control over instances, but does give control over types.
That is, there would be one module providing, e.g., reader monads
*without* ursurping instances of "global" classes for "global" types
for that purpose, and *another* module providing "standard" instances
for "global" classes/types. The latter would be good for quick
hacks, the former for modular development - different purposes,
different modules.

Otherwise, there are conflicts when one combines two packages trying
to define their own versions of these instances as part of whatever
else they are trying to do (such as the Monad modules right now).

There seemed to be some support for these suggestions last time,
and as there seems to be a maintainer around now, this might be 
a good time to fix these things?-)