Functional Programming – Modeling Entities with Identity and Mutable Persistent State

functional programmingobject-oriented

In an answer to this question (written by Pete) there are some considerations about OOP versus FP. In particular, it is suggested that FP languages are not very suitable for modelling (persistent) objects that have an identity and a mutable state.

I was wondering if this is true or, in other words, how one would model objects in a functional programming language. From my basic knowledge of Haskell I thought that one could use monads in some way, but I really do not know enough on this topic to come up with a clear answer.

So, how are entities with an identity and a mutable persistent state normally modelled in a functional language?

Here are some further details to clarify what I have in mind. Take a typical Java application in which I can (1) read a record from a database table into a Java object, (2) modify the object in different ways, (3) save the modified object to the database.

How would this be implemented e.g. in Haskell? I would initially read the record into a record value (defined by a data definition), perform different transformations by applying functions to this initial value (each intermediate value is a new, modified copy of the original record) and then write the final record value to the database.

Is this all there is to it? How can I ensure that at each moment in time only one copy of the record is valid / accessible? One does not want to have different immutable values representing different snapshots of the same object to be accessible at the same time.

Best Answer

The usual way to go about state changes in a pure language like Haskell is to model them as functions that take the old state and return a modified version. Even for complex objects, this is efficient because of Haskell's lazy evaluation strategy - even though you are syntactically creating a new object, it is not copied in its entirety; each field is evaluated only when it is needed.

If you have more than a few local state changes, things can become clumsy, which is where monads come in. The monad paradigm can be used to encapsulate a state and its changes; the textbook example is the State monad that comes with a standard Haskell install. Note, however, that a monad is nothing special: it's just a data type that exposes two methods (>>= and return), and meets a few expectations (the 'monad laws'). Under the hood, the State monad does exactly the same: take the old state and return a modified state; only the syntax is nicer.

Related Solutions

Immutability – Differences Between Immutable Value Types and Reference Types

You are defining value types and reference in a language agnostic way, but doing so only by example in terms of changing of data members. Logically, making the types immutable makes you lose the only difference guaranteed by your definition (and the answer might be "no").

However, once we start looking at particular programming languages, then yes: there are more differences.

Consider the following C# example.

void increment()
{
    lock (synchro)
    {
        total++;
    }
}

private int total = 0;
private SomeType synchro;

If SomeType is a reference type, this counter will be thread safe. If SomeType is a value type, then, due to boxing, each thread is locking a copy of synchro and increments may be lost under concurrency.

Of course, there are no genuine immutable types in .NET in the most abstract sense, as the monitors involved are implemented using hidden fields (akin to the C++ mutable keyword that can declare mutable members in otherwise immutable types). But on Stack Overflow, everyone will understand your question to refer to anything that their platform calls "immutable".

Imperative vs Functional – Differences in Language Debuggers

Deep under the hood, any functional language with heavy roots in lambda calculus is compiled to code, closely following some abstract computation model. For haskell it is STG-machine, for ocaml/caml-light it was CAM-machine. This execution model usually has something like local variables and clear route of execution and source code translates into code for abstract machine by clear, well-defined algorithm. So, breakpoints can be inserted in haskell (for example) code and something like local variables can be determined, when expression with breakpoint is evaluated.

For haskell and other lazy languages, however, the problem is that it does not make much good (except profiling). REPL allows coding expressions with easy, as no side-effects goes away from function body definition, so no real need to debug functions locally and asserts will locate error for sure. The real source of bugs usually is space leak due laziness in wrong place, and completely different tools, inspecting heap structure, are needed (and some are available).

Best Answer

Related Solutions

Immutability – Differences Between Immutable Value Types and Reference Types

Imperative vs Functional – Differences in Language Debuggers

Related Topic