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 > ftp://ftp.geoinfo.tuwien.ac.at/frank/numbersPrelude_v1.pdf > > if i have not found other contributions, i am sorry and hope to hear about > them. > > 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 Haskell list.) Peace, Dylan Thurston
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
