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

[Serge D. Mechveliani]

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
> mechveliani but i have not found a concrete proposal on the haskell' list of
> 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

* BAL library (implemented, downloadible) 
  -- 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.

These three items can be downloaded from   www.botik.ru/~mechvel

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