Thanks for the long answer David,
David House wrote:
On 17/03/07, Fawzi Mohamed <[EMAIL PROTECTED]> wrote:
[...]
Surely within a group of related types there'd be no overlapping names
anyway?
yes, but I found out that I would have an overlap with functions that I
wanted to use and function I wanted to define, resulting in quite some
qualifying.
Also arrays, inset,... have quite some overlapping.
For array the use of the IArray typeclass kept the things nice also
using Arrays and UArrays together, but adding IntSet to the whole worked
only qualifying, and then I also wanted to define a fold for my type...
I found Data.Foldable, but then in the end I just prefixed my operation
names which is what you did for record names.
Is this recommanded? It makes it difficult to change types, but at least
is easy to memorize...
So I am wondering how people cope with them, share your opinion,
for me the best thing seem to be to try to use one
module per "big" type, and then "import qualified x as y", what are
good coding practices?
A practice I've seen a lot in small- to mid-sized programs is to have
a Types module that contains definitions of the types used in the
program.
ok I will think about it
* vector & matrices *
A thing that bothered me a little was the absence of good standardized
vectors and matrices, for now I rolled my own 3x3, I have seen numerical
prelude, maybe in the future thre will be a standard interface for
matrixes...
Rolling my own mattrixes/vectors I have hit against some limitations of
classes, nothing terrible, but not so nice, and something that I
gather is
known for example the fact that you cannot overload + or (in haskell 98)
you cannot have overlapping instances.
Why not write up your module then send it off to the
[EMAIL PROTECTED] mailing list? If this has frustrated you then
it's probably frustrated others. Why not contribute something back and
polish this problem off?
I thought about it, the problem is that I need just a partial
implementation of it, but if I will have an enough cleaned and version I
will do it.
And you can overload (+), just make your matrix type an instance of
Num. If some operations shouldn't be supported (like signum, perhaps),
the general strategy is just to use error (this is basically due to
the fact that Num has too many methods because we don't have a sane
way of splitting up type classes. Type class synonyms -- google for
them -- look like a good solution, but are lacking an implementation).
This is is very ugly in my opinion, because for me a type class should
represent something more than just a way to overload, is something is
not a number then it should not have the class Num.
In this I liked very much the approach of aldor where being an instance
of a class is separated from overloading, and must always be explicit,
so that a type class can be used also to advertise that something (for
example) is commutative and it can have exactly the same functions as
another class.
Maybe here I should say something explicitly that I realized I had
completely forgotten to say: I like haskell very much and I enjoyed
using it, but there are some areas where coming from other languages do
not seem too well rounded (but maybe it is just that I am not yet fully
*in* haskell.
by
Fawzi
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
