Tue, 15 May 2001 16:10:20 +0400, S.D.Mechveliani <mechvel@math.botik.ru> pisze:
The matter was always in parametric domains ...
The solution is simple: don't model domains as types. Model them as values (records with operations). Some simple domains can be also modelled as types for convenience. But it doesn't work in general. Similarly as standard sort :: (Ord a) => [a] -> [a] is not as expressive as soryBy :: (a -> a -> Ordering) -> [a] -> [a] even though it's more convenient in case it works. It doesn't work when various instances of the same kind of algebraic structure over the same carrier set are considered. And it doesn't work when a domain should be parametrized by something which is hard to express by a type. And it constrains programs which want to choose the domain dynamically. Carrier sets are modelled as types, OK. But it won't work for all algebraic structures. About program transformation possibility: I don't see how it would be applied in practice. There is no use of associativity of (+) for the compiler. It can do many optimizations, but it won't rewrite x+(y+z) to (x+y)+z nor vice versa. Sample arguments are ugly, almost always unnecessary, and constrain interfaces (functions like 'sum :: Num a => [a] -> a' would have to have a different intreface). They are a solution to a wrong problem: some domains should not have been modelled as types in the first place. Algebraic operations don't belong to elements of algebras; they belong to algebras. In simple cases they can be deduced from the types of elements if the given carrier has a reasonable default interpretation of these operations (e.g. (+) on Integers), but it's not general. I don't believe that dependent types would come into Haskell in the near future. And they are unnecessary for the discussed purpose: domains which would require them should not be modelled as types. Don't abuse types to model values. Haskell's types are too static for that. The class hierarchy is unacceptable for me as standard Haskell. It's way too complex. Currently I have to define instances of Eq, Show, Num and Fractional to have field operations. With BAL I would have to define instances of Eq, Show, Set, Additive, AddSemigroup, AddGroup, Multiplicative, MulSemigroup, Ring, CommutativeRing, GCDRing, EuclideanRing, FactorizationRing and Field. They require such things as specifying an arbitrarily chosen set of properties of the domain and partially defined versions of most operations... The hierarchy contains many unnecessary superclass relationships. For example Show, specifying bounds and conversion from 'Expression String' are not necessary for Ord, where your classes artificially require them. There are no class synonyms in Haskell, so classes like OrdAddGroup can't be treated as implicit. Later parts are too heavy for me to understand them well, but I see some ugly points, like abusing Char arguments to virtually extend the function name, or requirement to provide reflection capabilities at the very beginning by every type wanting to use overloading of basic operations, or requirement that the programmer knows more advanced math than should be necessary to use Haskell. I hope that a similar proposal won't go into standard Haskell. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK