# [Haskell-cafe] Re: Proposal for restructuring Number classes

Serge D. Mechveliani mechvel at botik.ru
Sat Apr 8 14:16:53 EDT 2006

```On Sat, Apr 08, 2006 at 02:39:39PM +0200, Andrew U. Frank wrote:

> there has been discussions on and off indicating problems with the structure
> of the number classes in the prelude. i have found a discussion paper by
> tickets.
> i hope i can advance the process by making a concrete proposal for
> which i attach Haskell code and a pdf giving the rational. if i have not
> found other contributions, i am sorry.
>
> i try a conservative structure, which is more conservative than the
> structure we have used here for several years (or mechveliani's proposal).
> It suggests classes for units (Zeros, Ones) and CommGroup (for +, -),
> OrdGroup (for abs and difference), CommRing (for *, sqr), EuclideanRing (for
> gdc, lcm, quot, rem, div...) and Field (for /). I think the proposed
> structure could be a foundation for mathematically strict approaches (like
> mechveliani's) but still be acceptable to 'ordinary users'.
>
> i put this proposal for discussion here and hope for suggestions how it can
> be improved before i put it to haskell'!
>
> andrew frank
>

For a long time, there exist the following documents and programs

-- Basic Algebra Library for Haskell, which was a proposal for a
new "Num"-like library.

* A paper  "Haskell and computer algebra"
which describes the idea of BAL.

* A paper  "What should be an universal functional language",
which describes, what are the problems of Haskell as related to
algebra.

by clicking at BAL, and at the papers you choose.

The main problem with the  language  can be illustrated by the
following example.

The domain  Matrix(n, m)  of matrices  n by m

depends on the ordinary values. These  n, m  can be computed in
some cycle at run time.
But in Haskell, we need to model a  _domain_  as a  _type_,
with several  _instances_  for this type.
And these latter cannot evolve at run time.
For example the domain  Matrix(3, m)  must have
MultiplicativeSemigroup  instance
-- if  m == 3,
and must not have such instance otherwise.
And  m  may change at run-time.

This is the reason for why BAL looks so complicated
-- and why the proposal has been rejected.
(By the way, both these papers have been rejected by the conference
referrees of the Haskell community and FP community).

I think that without  dependent types  for a Haskell-like language,
it is impossible to propose any adequate and in the same time plainly
looking algebraic class system.

-----------------
Serge Mechveliani
mechvel at botik.ru

```