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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
