# algebra proposals

S.D.Mechveliani mechvel@math.botik.ru
Wed, 16 May 2001 14:42:13 +0400

```It appears, there was a discussion on the library proposals,
by D.Thurston, maybe, others.

-----------------------------------------------------------------
(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.
-----------------------------------------------------------------

---------------
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,

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 ***

```