Differences between OO-style Interfaces and type classes. Any 'Haskell' way of doing it?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Differences between OO-style Interfaces and type classes. Any 'Haskell' way of doing it?

Aleksandar Dimitrov
Hello folks,

thanks for being such a very nice and helpful community :-) I have another
pretty boring question?

Today I noticed where type classes and OO-Interfaces differ. Up until now, I
treated the two notions as pretty much equivalent, but knowing that there are
some differences I do not yet understand. Now I do understand at least one of
them.

Say I have several types Type, Subtype, Subsubtype and so on. All are instances
of a type class Class. The constructors all look like

> data Type = Type (Maybe Subtype)
> data Subtype = Subtype (Maybe Subsubtype)

and so on. I would now like to build a tree structure with Data.Tree which only
holds the type constructors as partial functions and be able to fold over the
tree to yield a complete value of type Type. So a user could select any point of
the tree (whether leaf or not) and she would get this node's type combined with
all the parent's node's types. A small example:

0,Type
|
`- 1,A
|  `- 3,C
`- 2,B

Selecting node 1 would result in the type (Type (Just (A Nothing))) returned and
selecting node 0 would return (Type Nothing).

Assuming all types implement Class, I thought equipping the nodes of a Data.Tree
with a type like (Class a) => Node (Maybe a -> a) would work. Of course it
didn't, because it couldn't unify the Subtype with the Type.

The reason I need this is because I have a HaXml generated file with data types
from a DTD, and would like to display them in a GTK TreeModel so the user could
choose a type there and have it turned to XML. The class of all DTD-originated
types is, of course, XmlContent.

So, my problem here is: I'd like a tree to store partial functions of possibly
different types and then be able to compose a leaf's or non-leaf's payload with
all the parent's payloads to yield a final result.

Writing up my idea made me realise how ludicrous it is from a theoretical point
of view, and that Data.Tree might simply not be the correct data structure for
this (alas, it's required for TreeModels in GTK.) At least it can serve as an
example to people where type classes do not act like Interfaces ;-) And I'd be
very glad to hear about a solution to my problem, it would make some things a
lot easier for me :-).

Thanks again,
Aleks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/beginners/attachments/20090404/d1b94ce8/attachment.bin
Reply | Threaded
Open this post in threaded view
|

Differences between OO-style Interfaces and type classes. Any 'Haskell' way of doing it?

Brandon S Allbery KF8NH
On 2009 Apr 4, at 11:06, ?????????? ?. ????????  
wrote:
> So, my problem here is: I'd like a tree to store partial functions  
> of possibly
> different types and then be able to compose a leaf's or non-leaf's  
> payload with
> all the parent's payloads to yield a final result.

Have you considered using generics?

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/beginners/attachments/20090404/398039c2/PGP.bin