Type design question
Mon, 28 Jul 2003 15:40:52 +0200
> Well, I may not exactly qualify, but I can give you a few suggestions,
> > data Floating a =3D> Vector a =3D Vector !a !a !a
> > deriving (Eq, Show)
> Here. Do not use 'data C x =3D>'. It's essentially a useless part of =
> language that really should have gone away. What you want is just:
> | data Vector a =3D 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: disallow=
> 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=20
doesn't, other than historical accident? It looks like a useful feature t=
> There are actually two problems. First, you want to write fmod as:
> | fmod x y =3D x - y * fromInteger (truncate (x/y))
OK, that's obvious.
> otherwise the type is wrong. Secondly, since you're using truncate, yo=
> need to be in RealFrac, not in Floating. Changing the signature to:
> | instance RealFrac a =3D> ...
> fixes this problem.
OK, that looks reasonable too (but the multitude of number classes does n=
yet look reasonable to me - I'll have to print a description and put it n=
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
> 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 =
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=20
multiple universe types in the same program, but qualified imports are no=
solution either, as there will be a lot of code referring to generic=20
More fundamentally, I consider the module system in its present form a ma=
weak point of Haskell. There is only one global module namespace, which=20
therefore is a scarce resource. If, as I have seen proposed in some book,=
use up a global module name for each abstract data type, then I can almos=
expect to get name clashes as soon as I try to use my code together with=20
someone else's (who thought that "vector" would be a great name for somet=
slightly different). I have seen the proposal for hierarchical libraries,=
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 specif=
yet wide application domain (scientific computing), which explains the ne=
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=20
difficult problem for many languages, in fact I suspect that it's the mai=
reason why languages like Fortran or C++ never got to the point of having=
sufficiently general libraries (I stopped counting the C++ matrix librari=