[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
> 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
More information about the Haskell-Cafe
mailing list