Thanks for the long answer David, David House wrote:

On 17/03/07, Fawzi Mohamed 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 libraries@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. by Fawzi

Quoth Henning Thielemann, nevermore,

On Mon, 19 Mar 2007, Fawzi Mohamed wrote:

...

...

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

I'd avoid that and suggest a more decentralized design, where each module contributes one main type and according functions.

That sounds like a kind of stateless object-oriented approach. Interesting. I probably do something like that but have never really formalised my thoughts on the matter. Nice one! -- Dougal Stanton

Robert Dockins wrote:

On Mar 19, 2007, at 9:56 AM, Henning Thielemann wrote:

...

On Mon, 19 Mar 2007, Fawzi Mohamed wrote:

...

...

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

I'd avoid that and suggest a more decentralized design, where each module contributes one main type and according functions.

I'd just like to mention that I've used the central "Types" module myself on occasion. The main reason is to avoid the need for mutually recursive modules, and not because its a particularly nice design. I try to arrange the user-visible API around some coherent organizing principle, such as the one Henning proposes, but that sometimes leads to module dependency cycles; factoring out a Types module is one way to break the cycles.

Rob Dockins

I used a "Types" module for most of the types in the all haskell regex-* backends I wrote. Doing anything else tended to lead to cycles, like Rob mentioned. This seems to be a result of "module/import" being the one-true-and-unique-way to create a namespace combined with almost no support for recursive modules. Thus data types that (indirectly) refer to each other must be in the same namespace. Thus one cannot even have a "all data types go in separate modules" policy. As I write the above, I wonder: if a new variant of "module" that only defines data constructors and types could be created then could compilers support these if they have mutual recursive imports/references? The other alternative being: Make one "Types" module file that has a new variant of "sub-module" that defines module namespaces inside the file. This is much that same as concatenating all the separate type modules into a single file. -- Chris

Robert Dockins wrote:

The main reason is to avoid the need for mutually recursive modules, and not because its a particularly nice design.

Chris Kuklewicz wrote:

This seems to be a result of "module/import" being the one-true-and-unique-way to create a namespace combined with almost no support for recursive modules.

I'd like to remind you that the Haskell98 report explicitly allows recursive modules http://haskell.org/onlinereport/modules.html However, it's a real pity that Hugs doesn't support them at all and that you have to take extra pains with .boot-files to get them in GHC. Recursive modules are the lazy evaluation of modules and "One should not obstruct access to such a vital tool". I want recursive modules for free! Regards, apfelmus

David House wrote:

On 19/03/07, Fawzi Mohamed wrote:

...

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.

Num is a collection of types whose members can be added and subtracted and so on. As numbers are the most common example of this, one could say the members of Num _act like numbers_, rather than are numbers in themselves.

Really typeclasses are all about overloading. For example, Eq is the collection of types that the equality predicate (==) applies to. I don't see this as ugly; quite the contrary, in that if you know a type instantiates Eq you can use (==) without worrying about using a type-specific equality predicate. E.g. it's nice to see the same (==) everywhere rather than seeing (say) (Int.==), (Bool.==) and so on.

Maybe I did not express me clearly enough, I think that classes are useful (and the language that I was speaking of, aldor, has them), but it is not nice that the only way to have an overloaded function is to define a type class, or that you need to fully implement a class just to overload one function of it. Vectors don't act like numbers, a vector space is not a field, even if they have some common operations. I find it misleading to define something a number when it does not satisfy all the properties of numbers. The numerical prelude might fix this, but still I think that class and overloading should be distinct concepts. Fawzi

Hello Fawzi, Monday, March 19, 2007, 8:26:33 PM, you wrote:

Maybe I did not express me clearly enough, I think that classes are useful (and the language that I was speaking of, aldor, has them), but it is not nice that the only way to have an overloaded function is to define a type class

overloading without using type classes (as it is implemented in C++) is hardly compatible with type inference. imagine that you has two functions: f :: String -> Int f :: Int -> Int and write (f a). what should be type of a? it becomes a list of possible types. because type inference mechanism pushes inferred types up and down, the whole information about type of each term will become much more complicated. compare this to current requirement to overload using only type classes. in this case, you know that 'a' belongs to some class, so possible variants don't multiply at each inference step -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Fawzi, Tuesday, March 20, 2007, 1:47:48 PM, you wrote:

That was the reason that is spoke of aldor ( http://www.aldor.com ), as it has type inference, but yes indeed this makes type inference much more difficult and undefined in some cases (also haskell extensions make inference in general impossible).

the problem is not only implementation, but error messages. are you want to see a message like "a should be Int, b should String, and ñ should be Double; or x should be String and y Int; or ñ should be [Int]" ? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Fawzi, Tuesday, March 20, 2007, 5:37:45 PM, you wrote:

ambiguous function call at line xxx. Possible instances are: f: Int -> String -> Double -> a f: String -> Int -> [Int] -> a please explicitly annotate the type to disambiguate

Note that you want to use also the type of the result to disambiguate. Not easy, but doable, and done, again I can understand why haskell did not do it.

you not yet realize the whole problem :) in traditional languages, all type information flows in one direction and when compiler see f(x,y,z) call, it already knows x/y/z types because they should be declared earlier. but in haskell types of these variable may be defined by subsequent calls. so imagine several such overloaded calls - "f x y z", then "g (h x) (h y)", and more and more. error messages will become so complicated that you will shoot the compiler :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

The nice thing about Haskell's overloading is that every function, like f, has a type. Not two different types, but one general type you can give it. It's a different approach to overloading. -- Lennart On Mar 20, 2007, at 14:37 , Fawzi Mohamed wrote:

Bulat Ziganshin wrote:

...

Hello Fawzi,

Tuesday, March 20, 2007, 1:47:48 PM, you wrote:

...

That was the reason that is spoke of aldor ( http:// www.aldor.com ), as

ehm http://www.aldor.org

...

it has type inference, but yes indeed this makes type inference much more difficult and undefined in some cases (also haskell extensions make inference in general impossible).

the problem is not only implementation, but error messages. are you want to see a message like "a should be Int, b should String, and ñ should be Double; or x should be String and y Int; or ñ should be [Int]" ? :)

ambiguous function call at line xxx. Possible instances are: f: Int -> String -> Double -> a f: String -> Int -> [Int] -> a please explicitly annotate the type to disambiguate

Note that you want to use also the type of the result to disambiguate. Not easy, but doable, and done, again I can understand why haskell did not do it.

Fawzi _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

David House wrote:

On 19/03/07, Fawzi Mohamed wrote:

...

Vectors don't act like numbers, a vector space is not a field, even if they have some common operations.

As I said in my previous email, this is because Num is too big. We need to split it down, but there's no sane way of doing this without your average numeric function needing about a thousand different constraints on it. Type class synonyms [1] look promising, but no-one's implemented them yet AFAIK.

[1]: http://repetae.net/john/recent/out/classalias.html

I might missing something fundamental but what is the advantage of a class alias with respect to multiple inheritance? i.e. class alias FooBar a = (Foo a, Bar a) vs class (Foo a, Bar a) => FooBar can an alias be implemented a posteriory without modifying the code of FooBar? because what one really wants to do is to split Num even if Num is not splitted, but this would create problems with type inference... Fawzi