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@botik.ru