
Hello to everyone :) My name is Enrico, 40, and I write software for the industry at Beta 80 Group. After this short introduction, here is the help request: I'm managing the rewrite of an application, to port it to the 'classic' Java three-tiers architecture. Before I begin to feed the team, I want to see a fully functional prototype of the problem. I mean the app's functions, not the graphic. What I imagine is a data base of types and groups of functions. The idea is to study the problem, inject new functions while checking their coerence with the existing type infrastructure, and so on. In plain Java, I'd have wrote the Business Idea in informal language, extracted the types from it, assigned methods to types and then glued things together in some way. In Haskell I (should) have the opportunity to stay on the problem, decomposing it into sub-problems until I come to the soil. What I ask to this list is if and where Haskell is different from the object oriented way to decompose the problem. I'm very fresh on Haskell. Exactly... chapter 13 of SOE :) Are type classes different from Java classes? I think so, but I guess this means that one should ask different things to type classes, respect to what is being asked to Java classes. It is this difference that's unclear to me. Any help would be very appreciated Enrico

On Thu, 29 Jul 2004, Henning Thielemann wrote:
On Thu, 29 Jul 2004 enrico.santoemma@tin.it wrote:
I'm very fresh on Haskell. Exactly... chapter 13 of SOE :) Are type classes different from Java classes?
Type classes are a static issue. They are roughly speaking bundles of functions that can be overloaded.
To put it another way, they're closer to Java interfaces - though type classes are a more general idea, as demonstrated by the multi-parameter type classes supported by ghc et al. You can think of them as a predicate - "this type has implementations for these overloaded functions". -- flippa@flippac.org

To put it another way, they're closer to Java interfaces - though type classes are a more general idea, as demonstrated by the multi-parameter type classes supported by ghc et al. You can think of them as a predicate - "this type has implementations for these overloaded functions".
Ok, very clear. This should mean that I must concentrate on data/newtype, right? So, if I've understood well, <data> adds parameters (with pattern matching?) and recursion to structure definition. Still right? Enrico

At 14:50 29/07/04 +0200, enrico.santoemma@tin.it wrote:
Are type classes different from Java classes? I think so, but I guess this means that one should ask different things to type classes, respect to what is being asked to Java classes. It is this difference that's unclear to me.
I made some notes about this, but they're in no sense authoritative: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-mi... There was also a little discussion of these notes, starting around: http://www.haskell.org//pipermail/haskell/2003-December/013269.html and subsequently transferring to Haskell-cafe. There was some discussion of classes and their relation to OO style, but that seems to have been off-list. Some of the comments received have been added to my notes. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

Graham Klyne
I made some notes about this, but they're in no sense authoritative: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-mi...
I think it's easy for the OO-programmer to start designing programs using Haskell classes as if they were OO classes. Not necessarily bad, but I agree it is better to build your program first, and add classes later when and where it makes sense. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (5)
-
enrico.santoemma@tin.it
-
Graham Klyne
-
Henning Thielemann
-
Ketil Malde
-
Philippa Cowderoy