[Haskell-cafe] Re: I just don't get it (data structures and OO)

[Al Falloon]

Phlex wrote:
> 
> 
> 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
>> identifiers.
>>   
> 
> 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 
> data
> 
> 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 
nested structures.

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" [1] 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 
implementation.

[1] http://www.math.chalmers.se/~rjmh/Papers/whyfp.html