[Haskell-cafe] Proposal for restructuring Number classes
dthurston at barnard.edu
Mon Apr 17 23:52:29 EDT 2006
On Mon, Apr 10, 2006 at 12:13:55PM +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 can be found at
> if i have not found other contributions, i am sorry and hope to hear about
> 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 agree with Henning Thielemann about putting 'zero' in 'CommGroup'
and 'one' in 'CommRing'. What is your thinking here? I would also
argue for putting 'fromInteger' in 'CommRing', as discussed in the
NumPrelude proposal. 'EuclideanRing' is a misnomer; a Euclidean Ring
is a particular type of ring where GCD, etc. can be defined (see
http://planetmath.org/encyclopedia/EuclideanRing.html), but there are
other such rings, namely any Principal Ideal Domain or PID.
'IntegralDomain' is also a misnomer; I don't know what you're getting
at there, but there is a well-established mathematical term 'integral
domain' that means something different.
o On enforcing properties: there's not currently any way to enforce
properties (e.g., monad laws are not enforced); however, I believe
that expected properties should be documented.
o ^ and ^^ (which can actually be combined, see our proposal) are in
fact quite useful, and can be implemented considerably more
efficiently than a general exponentiation. If you want a complete
proposal, you do need to go further.
o You do impose some additional burden by changing the name of the
'Num' class, and it is worth noting that.
o Mechvelliani's implementation could not be built on top of your
base, because he needs to have a sample argument to 'zero' to
determine, e.g., the right zero for modular arithmetic. Henning
mentioned this in his response. To implement modular arithmetic with
these signatures, as far as I know, you need to either separate Zero
constructors or do something like the Kiselyov-Shan paper. (See,
e.g., Frederick Eaton's linear algebra library recently posted to the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060417/02b963f8/attachment.bin
More information about the Haskell-Cafe