Type design question

[Konrad Hinsen]

> Well, I may not exactly qualify, but I can give you a few suggestions,
> nonetheless...

Thanks!

> > 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 =
the
> 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=
s
> 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=
o=20
me.

> 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=
u
>
> 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=
ot=20
yet look reasonable to me - I'll have to print a description and put it n=
ext=20
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=20
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=
t a=20
solution either, as there will be a lot of code referring to generic=20
universes.

More fundamentally, I consider the module system in its present form a ma=
jor=20
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,=
 I=20
use up a global module name for each abstract data type, then I can almos=
t=20
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=
hing=20
slightly different). I have seen the proposal for hierarchical libraries,=
 but=20
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=
ic=20
yet wide application domain (scientific computing), which explains the ne=
ed=20
for generality. I haven't seen this issue addressed in any of the Haskell=
=20
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=
n=20
reason why languages like Fortran or C++ never got to the point of having=
=20
sufficiently general libraries (I stopped counting the C++ matrix librari=
es,=20
for example).

Konrad.