Why must essential mutable derived data have an inverse function?

Question

I was reading the paper Out of the Tar Pit authored by Ben Moseley and Peter Marks when I came across the following section on page 25 regarding essential mutable derived data:

Essential Derived Data — Mutable

As with immutable essential derived data, this can be excluded (and the data re-derived on demand) and hence corresponds to accidental state.

Mutability of derived data makes sense only where the function (logic) used to derive the data has an inverse (otherwise — given its mutability — the data cannot be considered derived on an ongoing basis, and it is effectively input). An inverse often exists where the derived data represents simple restructurings of the input data. In this situation modifications to the data can simply be treated identically to the corresponding modifications to the existing essential state.

I don't understand why essential mutable derived data must have an inverse function. For example consider the following JavaScript code:

inputbox.onchange = function () {
    outputbox.value = md5(inputbox.value);
};

Here inputbox.value is input to the system and outputbox.value is the essential mutable derived data. It is derived from inputbox.value using the md5 function. However the md5 function doesn't have an inverse. Nevertheless inputbox.value is still essential, mutable and derived.

So what do the authors actually mean when they say that “mutability of derived data makes sense only where the function (logic) used to derive the data has an inverse (otherwise — given its mutability — the data cannot be considered derived on an ongoing basis, and it is effectively input)”?

Do you have any examples to elucidate their point?

Answer 1

When they say immutable derived data, think of the derived value as always being calculated by a function, so the output is never changed except as a result of the input changing first. Put another way, if you have a GUI with an input box and a derived output box, that output box would be read only. The function is immutable, even if its input isn't.

For your md5 example, since it isn't invertible, you would never change the md5 value in the GUI and derive new input data from that. You have to change the input data. If you don't want to store that input (for example if it's a password), then the md5 data must become an input after it is calculated.

For an example of mutable derived data, consider a color picker that shows both rgb and hsv representations of a color, but stores it as rgb. The hsv can be considered derived data, but it doesn't need to be immutable because it has an inverse. If you change the hsv value directly, you can get an rgb value from that to be your input.

Answer 2

Not being the authors, I can only guess, but I think they're hinting at the difference between mutable data and time-variant data. If the user can actually modify outputbox.value arbitrarily, then it's truly mutable, but it's also not derived data (it only uses derived data as a default value of sorts). If, on the other hand, outputbox.value changes on its own in tandem with inputbox.value, but the user can't change it directly, then it's no longer mutable but time-variant instead.

A good example of data that is both truly mutable and truly derived is so-called views. Imagine we have a complicated and efficient data structure for storing list of a certain type of value, but we want the users to be able to use it as though it's an ordinary mutable array. We might specify any number of helpful operations on the data, but in the end, the easiest way is to expose an array as derived mutable data: in other words, we allow the users to convert our data structure to an array, and then when they change the array, we change our data structure in tandem. This is what is meant by derived mutable data having an "inverse"; if I wanted to be a bit more mathematically precise, I might call it an adjoint.

The difference between mutable data and time-variant data is a fundamental one, and is at the heart of much of the confusion of newcomers to Functional Reactive Programming. If you are interested in this kind of thing, I would highly recommend looking into Elm, especially this high-level overview of FRP.