> Well, I may not exactly qualify, but I can give you a few suggestions, > nonetheless...
Thanks! > > data Floating a => Vector a = Vector !a !a !a > > deriving (Eq, Show) > > Here. Do not use 'data C x =>'. It's essentially a useless part of the > language that really should have gone away. What you want is just: > | data Vector a = Vector !a !a !a deriving (Eq, Show) > > The Floating constraint can come in on the functions. > > (I say this feature is useless because it only does one thing: disallows > you to construct Vectors whose elements aren't instances of Floating. > However, the useful thing that it might do -- namely, allow you to *use* > the fact that the elements are instances of Floating -- it doesn't.) That was indeed what I expected it would do. Is there any reason why it doesn't, other than historical accident? It looks like a useful feature to me. > There are actually two problems. First, you want to write fmod as: > | fmod x y = x - y * fromInteger (truncate (x/y)) OK, that's obvious. > otherwise the type is wrong. Secondly, since you're using truncate, you > > need to be in RealFrac, not in Floating. Changing the signature to: > | instance RealFrac a => ... > > fixes this problem. OK, that looks reasonable too (but the multitude of number classes does not yet look reasonable to me - I'll have to print a description and put it next to my keyboard). > And here's the problem. When 'u' is 'OrthorhombicUniverse x', it > doesn't know that this 'x' is supposed to be the same as the 'a'. One Indeed... > way to fix this is to parameterize the Universe data type on the > element, something like: OK, that works. But it doesn't make my code any nice, it means many more type constraints all over the code. > This is beginning to get a little ugly, but I think that's largely > because you're using type classes in too much of an OO style (this is I am coming from OO indeed... > similar to this, I moved away from that). However, not knowing more > about the domain of discourse, I don't know what to suggest. Perhaps > using the module system would serve you better. Instead of having a > universe class, simply put each universe in a separate module and > provide the same functions in each. Then you just import them > selectively, or qualified. I don't think this would be appropriate to me. I want to be able to use multiple universe types in the same program, but qualified imports are not a solution either, as there will be a lot of code referring to generic universes. More fundamentally, I consider the module system in its present form a major weak point of Haskell. There is only one global module namespace, which therefore is a scarce resource. If, as I have seen proposed in some book, I use up a global module name for each abstract data type, then I can almost expect to get name clashes as soon as I try to use my code together with someone else's (who thought that "vector" would be a great name for something slightly different). I have seen the proposal for hierarchical libraries, but that seems to be no more than a proposal at the moment. My intention is to write rather low-level library-style code for a specific yet wide application domain (scientific computing), which explains the need for generality. I haven't seen this issue addressed in any of the Haskell books or Web sites I know, so I would appreciate any pointers. It's a difficult problem for many languages, in fact I suspect that it's the main reason why languages like Fortran or C++ never got to the point of having sufficiently general libraries (I stopped counting the C++ matrix libraries, for example). Konrad. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
