[Haskell-cafe] Re: I just don't get it (data structures and OO)
afalloon at synopsys.com
Tue Jun 5 10:20:49 EDT 2007
> Christopher Lane Hinson wrote:
>> Where "InsidenessMap a b c" represents a relationship where b's are
>> inside a's, and b's have a state of c. Then, you need to declare a
>> separate InsidenessMap for each possible relationship, but this
>> ensures that you'll never put a galaxy inside a solar system. Or you
>> can make 'a' be a reference to any type of object; there are options.
> Ketil Malde wrote:
>> Identity can be emulated by relatively straightforward means: store all
>> planets in a Map indexed by something that is useful as an identifier
>> (i.e. stays constant and is unique), and have a Galaxy keep a list of
> So basically you guys are saying I should rethink the data structure
> into a relational model instead of sticking to the OO model... I think i
> could do this pretty easily. a table would be a map of id to instance
> ...then another map for foreign keys, or maybe just as a member of each
> Is the relational model a better fit than the object model for
> functional programming ?
Of course it depends on what you are doing, but I actually have never
needed to encode a relational model like this, even when I have deeply
I find that my usual solution involves doing my transformations on the
data structure "all at once". By that I mean that instead of performing
a number of steps from the root of the data structure, I do all the
operations in one pass.
To keep the algorithms decoupled I usually end up passing the operations
to perform as an argument. Higher-order functions are your friend.
Because Haskell is lazy I don't really worry about doing "too much" and
if I really need it, I can use the result as part of the transformation
(its like recursion, but with values). Between laziness and HOF I rarely
need any kind of state.
Its not directly related to your question, but I found the iterative
root-finding and differentiation examples in "Why Functional Programming
Matters"  to be eye-opening about the "functional way" because they
are algorithms that are almost always described as stateful
computations, but are shown to be very elegant in a pure functional
More information about the Haskell-Cafe