|Version 11 (modified by 10 years ago) (diff),|
Issues with Standard Classes
This page collects issues and proposals for the standard classes. Many of the proposals involve additional superclasses, which would be less burdensome with class aliases or something similar, but such features are not yet implemented.
- Standard Haskell Classes of Haskell 98
- Standard Prelude of Haskell 98
- Algebraic structures in WikiPedia
- DoCon the Algebraic Domain Constructor
- Numeric prelude project
The Functor class
- Add instances for
The Monad class
- Monads are really functors, but programmers can't always assume that
fmapis defined for them, and so must use
liftMinstead. Similarly, code parameterized by
Functorcannot be used with monads.
failmethod was added to the class in Haskell 98 to implement pattern match failure in
doexpressions. However the assumption that errors are strings can be problematic (e.g. cf the
Errorclass in Control.Monad.Error, or for internationalization).
- Add instance for
Functora superclass of
Monad. This would impose an extra burden on those who just want to define a
joina method of
Monad, interdefined with
- A more extreme step down this road would be to interpose the new Applicative class between
Monad, with corresponding renaming of methods.
The Haskell 98 numeric classes are adequate for Haskell 98 numeric types, but other mathematical objects do not fit. If the Haskell 98 classes were retained for backwards compatibility, but with a more refined class hierarchy, the change would impact mostly on those defining instances (and these are the people inconvenienced by the current system). Clients of the classes would notice only some more general types.
The Num class
Showdon't make sense for functions under lifting.
(*)doesn't make sense for vectors.
signumdon't make sense for
Complex Integer(Gaussian integers), vectors, matrices, etc. In general,
signummake it hard to lift
Numthrough type constructors.
- A group-like class with
- (Could be further split with a monoid sub-class.)
- A ring-like subclass adding
fromInteger, with the existing
Numclass as a further subclass.
- (Could be further split with a semiring subclass, e.g. for natural numbers.)
Note that the
Double instances will not satisfy the usual axioms for these structures.
The Fractional class
fromRationalcan be lifted to functions, but many of the pre-requisites can't be defined for these.
- Add a division ring-like superclass adding these operations to the ring-like class. (A division ring has the same operations as a field, but does not assume commutative multiplication, allowing structures such as quaternions.)
- Add default
fromRational x = fromInteger (numerator x) / fromInteger (denominator x)This is independent of all the other proposals.
The Integral class
modalso sense for rationals, polynomials and Gaussian integers, but
toRationaldon't make sense for polynomials and Gaussian integers.
remassume an ordering.
Other standard classes
The Read class
The Enum class
- The default definitions of
enum* would make more sense if
- Some doubt that it makes sense to have
- It is wierd that
The Ix class
- There is no portable way to report indexing errors accurately.
Showa superclass of
Ix, so that the offending index and range can be shown in exceptions. (All instances of
basepackage are also instances of
The Bits class
Numsuperclass may unduly restrict instances. The only thing actually needed from
bitSizemethod is not defined for all instances, and there is no general way to test whether it can be safely called.
The Storable class
- Some interfaces require clients to manage the memory for objects, but to treat them abstractly. In such cases one wants to define
alloca), but not