Personal tools

Heterogenous collections

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m
(Editting and formatting)
Line 6: Line 6:
 
=== The problem ===
 
=== The problem ===
   
Is some kind of collection of object with different types in Haskell
+
Does some kind of collection of objects with different types in Haskell exist? Obviously, tuples are an example, but they have a fixed length. To compare tuples vs lists:
exist? Except the tuples, which have fixed length. I find this
 
   
* Tuples heterogeneous, lists homogeneous.
+
{| border="1" cellpadding="2" align="center"
* Tuples have a fixed length, or at least their length is encoded in their type. That is, two tuples with different lengths will have different types.
+
|-
* Tuples always finite.
+
!Tuples!!Lists
  +
|+
  +
|Heterogeneous||Homogeneous
  +
|+
  +
|Fixed length (per tuple type)||Variable length
  +
|+
  +
|Always finite||May be unending
  +
|}
   
But I need something which is heterogeneous and non-fixed length. I'm
+
However, the need is for heterogeneous and non-fixed length. When one is used to Java, with its loose typing of collections,not having this immediately and
used do Java, and this switch to functional languages is very strange to
+
easily available seems strange. As an example, the need is for something like LinkedList<Object> from java.
me. So, to be clear, I need something like LinkedList<Object> in java.
 
   
   
=== Algebraic Datatypes ===
+
=== Algebraic datatypes ===
   
If the number of types to cover is fixed, then I suggest a data type
+
If the number of [[type]]s to cover is fixed, then the problem can be solved by a list of data types such as
like
 
   
 
<haskell>
 
<haskell>
Line 39: Line 39:
 
</haskell>
 
</haskell>
   
This is a very basic solution, and often preferable. Limitations: You
+
This is a very basic solution, and often preferable. Limitations: You have to type-switch all the time if you want to do anything with the objects in the List, and the collections are clumsy to extend by new types.
have to type-switch all the time if you want to do anything with the
 
objects in the List, and the collections are clumsy to extend by new
 
types.
 
   
   
   
=== HLists, OOHaskell, Type-Level Programming ===
+
=== HLists, OOHaskell, type-level programming ===
   
This is the cleanest solution, but very advanced and a little
+
This is the cleanest solution, but very advanced and a little restrictive. Read these two articles:
restrictive. Read these two articles:
 
   
 
* http://homepages.cwi.nl/~ralf/HList/
 
* http://homepages.cwi.nl/~ralf/HList/
Line 52: Line 52:
 
There is also some related material here:
 
There is also some related material here:
   
* http://www.haskell.org/haskellwiki/Extensible_record
+
* [[Extensible record]]
   
   
=== Existential Types ===
+
=== [[Existential types]] ===
   
Depending on your needs and your comfort level with fancier types, the
+
Depending on needs and comfort level with fancier types, the existential approach to ADTs might solve the problem. The following code is a demonstration you can cut-and-paste-and-run.
existential approach to ADTs might solve your problem. The following
 
code is a demonstration you can cut-and-paste-and-run.
 
   
This is example akin to upcasting in Java to an interface that lets
+
This is example akin to upcasting in Java to an interface that lets you print things. That way you know how to print every object (or do whatever else it is you need to do) in the list. Beware: there is no safe downcasting (that's what Typeable would be for); that would likely be more than you need.
you print things. That way you know how to print every object (or do
 
whatever else it is you need to do) in the list. Beware: there is no
 
safe downcasting (that's what Typeable would be for); that would
 
likely be more than you need.
 
   
There are other ways to do this with existentials (e.g. bounded
+
There are other ways to do this with existentials (e.g. bounded existentials), but this is what came out of my head when I read your post. Existentials seems to be the "Haskellish" way to reduce a heterogenous list to a collection of objects with common operations. [[HList]] would be the Haskellish way for more static and flexible assurances.
existentials), but this is what came out of my head when I read your
 
post. Existentials seems to be the "Haskellish" way to reduce a
 
hetergenous list to a collection of objects with common operations.
 
HList would be the Haskellish way for more static and flexible
 
assurances.
 
   
 
<haskell>
 
<haskell>

Revision as of 20:12, 17 November 2006

This page is a very hasty and ad-hoc summary of a common discussion on the haskell-cafe list. If you find it hard to read, please complain there and somebody hopefully will come to help.


Contents

1 The problem

Does some kind of collection of objects with different types in Haskell exist? Obviously, tuples are an example, but they have a fixed length. To compare tuples vs lists:

Tuples Lists
Heterogeneous Homogeneous
Fixed length (per tuple type) Variable length
Always finite May be unending

However, the need is for heterogeneous and non-fixed length. When one is used to Java, with its loose typing of collections,not having this immediately and easily available seems strange. As an example, the need is for something like LinkedList<Object> from java.


2 Algebraic datatypes

If the number of types to cover is fixed, then the problem can be solved by a list of data types such as

data T =
     ConsInt    Int
   | ConsString String
   | ConsChar   Char

or:

data Object = IntObject Int | StringObject String
 
objectString :: Object -> String
objectString (IntObject v) = show v
objectString (StringObject v) = v
 
main = mapM_ (putStrLn . objectString) [(IntObject 7), (StringObject "eight")]

This is a very basic solution, and often preferable. Limitations: You have to type-switch all the time if you want to do anything with the objects in the List, and the collections are clumsy to extend by new types.


3 HLists, OOHaskell, type-level programming

This is the cleanest solution, but very advanced and a little restrictive. Read these two articles:

There is also some related material here:


4 Existential types

Depending on needs and comfort level with fancier types, the existential approach to ADTs might solve the problem. The following code is a demonstration you can cut-and-paste-and-run.

This is example akin to upcasting in Java to an interface that lets you print things. That way you know how to print every object (or do whatever else it is you need to do) in the list. Beware: there is no safe downcasting (that's what Typeable would be for); that would likely be more than you need.

There are other ways to do this with existentials (e.g. bounded existentials), but this is what came out of my head when I read your post. Existentials seems to be the "Haskellish" way to reduce a heterogenous list to a collection of objects with common operations. HList would be the Haskellish way for more static and flexible assurances.

{-# OPTIONS -fglasgow-exts #-}
 
module Test where
 
data PrintPackage = forall a . PrintPackage a (a -> String)
 
instance Show PrintPackage where
   show (PrintPackage val showMethod) = showMethod val
 
list = [ PrintPackage 3 show
      , PrintPackage "string" show
      , PrintPackage 3.4 show
      ]
 
main = print list