Sun, 11 Feb 2001 16:03:37 -0800, Ashley Yakeley pisze:

Apologies if this has been discussed and I missed it. When it comes to writing a 'geek' prelude, what was wrong with the Basic Algebra Proposal found in ftp://ftp.botik.ru/pub/local/Mechveliani/basAlgPropos/ ? Perhaps it could benefit from multi-parameter classes?

Let me quote myself why I don't like this proposal: - It's too complicated. - Relies on controversial type system features, like undecidable instances and overlapping instances. - Relies on type system features that are not implemented and it's not clear if they can be correctly designed or implemented at all, like "domain conversions". - Has many instances that should not exist because the relevant type does not have the class property; they return Nothing or fail, instead of failing to compile. - Properties like commutativity cannot be specified in Haskell. The compiler won't be able to automatically perform any optimizations based on commutativity. - belongs is strange. IMHO it should always return True for valid arguments, and invalid arguments should be impossible to construct if the validity can be checked at all. - Tries to turn a compiled language into an interpreted language. FuncExpr, too much parsing (with arbitrary rules hardwired into the language), too much runtime checks. - It's too complicated. - It's not true that it's "not necessary to dig into mathematics". I studied mathematics and did not have that much of algebra. - I perfer minBound to looking at element under Just under Just under tuple of osetBounds. - Uses ugly character and string arguments that tune the behavior, e.g. in syzygyGens, divRem, canFr. I like Haskell98's divMod+quotRem better. - Uses unneeded sample arguments, e.g. in toEnum, zero, primes, read. - Have I said that it's too complicated? There were lengthy discussions about it... -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

On Mon, 12 Feb 2001, John Meacham wrote:

My one request is that if at all possible, make some sort of partial ordering class part of the changes, they are just way to useful in all types of programs to not have a standard abstraction.

I like the idea of having e.g. (<) and (>) not necessarily total, and only total compare. It doesn't need to introduce new operations, just split an existing class into two. Only I'm not sure why (<) and (>) should be partial, with (<=) and (>=) total, and not for example opposite. Or perhaps all four partial, with compare, min, max - total. For partial ordering it's often easier to define (<=) or (>=) than (<) or (>). They are related by (==) and not by negation, so it's not exactly the same. I would have PartialOrd with (<), (>), (<=), (>=), and Ord with the rest. Or perhaps with names Ord and TotalOrd respectively? There are several choices of default definitions of these four operators. First of all they can be related either by (==) or by negation. The first works for partial order, the second is more efficient in the case it works (total order). We can have (<=) and (>=) defined in terms of each other, with (<) and (>) defined in terms of (<=) and (>=) - in either way. Or vice versa, but if the definition is in terms of (==), then as I said it's better to let programmers define (<=) or (>=) and derive (<), (>) from them. If they are defined by negation, then we get more efficient total orders, but we must explicitly define both one of (<=), (>=) and one of (<), (>) for truly partial orders, or the results will be wrong. Perhaps it's safer to have inefficient (<), (>) for total orders than wrong for partial orders, even if it means that for optimal performance of total orders one have to define (<=), (<) and (>): class Eq a => PartialOrd a where -- or Ord (<=), (>=), (<), (>) :: a -> a -> Bool -- Minimal definition: (<=) or (>=) a <= b = b >= a a >= b = b <= a a < b = a <= b && a /= b a > b = a >= b && a /= b We could also require to define one of (<=), (>=), and one of (<), (>), for both partial and total orders. Everybody must think about whether he defines (<) as negation of (>=) or not, and it's simpler for the common case of total orders - two definitions are needed. The structure of default definitions is more uniform: class Eq a => PartialOrd a where -- or Ord (<), (>), (<=), (>=) :: a -> a -> Bool -- Minimal definition: (<) or (>), (<=) or (>=) a < b = b > a a > b = b < a a <= b = b >= a a >= b = b <= a This is my bet. -- Marcin 'Qrczak' Kowalczyk