algebra proposals

[S.D.Mechveliani]

It appears, there was a discussion on the library proposals,
by D.Thurston, maybe, others.
And people asked for my comments. My comments are as follows.

-----------------------------------------------------------------
(1) It is misleading to call this part of the standard library 
   `numeric': 
`numeric classes', `numeric Prelude', `Num', and so on.
Matrices and polynomials match many of the corresponding instances 
but hardly can be named `numeric' objects.
This is why BAL introduces the term Basic Algebra (items).

(2) The order of considering problems matters. 

First we have to decide how to program algebra and then - whether 
(and how) to change the standard. The idea of the first stage
forms the skeleton for the second.

(3) As I see, we cannot decide how to program algebra in Haskell.

Hence, it is better not to touch the standard - in order to save 
effort and e-mail noise.
-----------------------------------------------------------------


Comments to (2)
---------------
Anyone pretending to improve the standard has either to write any
sensible algebraic Haskell application or to study attentively 
(with computing various examples) any existing one.
A `sensible application' should show how to operate in parametric 
domains, not only in domains like  (Integer, Bool).
Example: polynomials in [x1..xn] with coefficients over a field 
(like rational numbers) quotiented by several equations.
For example, the data  
                      r = Residue (x+y) (Ideal [x^2+3, y^3-2])

represents the mathematical expression
              
                      squareRoot(-3) + cubicRoot(2)

The basis  bas = [x^2+3, y^3-2]  for  I = Ideal [x^2+3, y^3-2]

can be computed as the first class data.
And for many instances  <Inst>  
                        (<Inst> may be  Fractional, Field, ...)

the domain (type?) of  r  matches or does not match <Inst> 
depending on the value of  bas.
Even if the application builds the domains only statically,
when the compiler knows statically all the intended values of  bas,
Haskell would still meet difficulties.
 
On dependent types
------------------
Maybe, Haskell has to move to dependent types.
I am not sure, but probably, unsolvability does not matter.
If the compiler fails to prove the correctness condition (on p) for 
a type  T(p)  within the given threshold  d,  the compiler reports
"cannot prove ...". The user has to add annotations that help to 
prove this. Or to say "solve at run-time". Or to say "I postulate
this condition on  p,  put the correctness on me".

With kind regards,

-----------------
Serge Mechveliani
mechvel@botik.ru     *** I am not in  haskell-cafe  list ***