[Haskell-cafe] what I learnt from my first serious haskell programm

Fawzi Mohamed fmohamed at mac.com
Mon Mar 19 06:20:37 EDT 2007

Thanks for the long answer David,
David House wrote:
> On 17/03/07, Fawzi Mohamed <fmohamed at mac.com> 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 
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
> libraries at haskell.org 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.


More information about the Haskell-Cafe mailing list