I'm currently hearing a lecture on programming paradigms which has left me rather fascinated. Up to now, it has primarily been about the Haskell Language, which seems to be based on simple and elegant concepts.

As a side note, this is my first time getting in practical touch with functional programming and working with such a language, so I might get things wrong.

Basically, in functional languages there's no state and all functions calls lead to some kind of evaluation (or rather transformation) of expressions that return a value. This is totally different from what is contemporarily known as OOP.

Like every so often I have some gut feeling but can't put a finger on it. So I feel like dumping a WIP.

As you might know, I design an object system. Or maybe I'm creating some Frankensteinian monster out of several systems and concepts that influenced my thoughts, most notably Smalltalk, Self, Newspeak and maybe Lisp (despite not ever having written a line of code in any of them, except for the first one).

Anyways, let me explain how the concept looked the last time I worked on it (which already was several months ago).

struct Object
{
    const struct Object* const slots[SLOTS_SIZE];
};

(Of course, the level of detail has been reduced heavily.)

A message send in this system, for example a foo: b (to use Smalltalk syntax), is just syntactic sugar for the evaluation of a code object stored in the specified slot (for example in slot foo:), using appropriate parameters (foo value: b).

A code object, or rather code generally, is a closure (comparable to a Smalltalk block), which basically is a lambda expression whose free variables have been bound.

When an execution context is set up, a certain variable (this/self) is defined to reference the object receiving the message. This way, we can use the well-known programming style of methods.

Since we're using the capability security model, there are no globally accessible objects and no objects can be accessed that have not been passed as a parameter. Note that since everything is an object, it follows that there is no global state. The accessibility relation, however, is transitive, so one can chain multiple message sends and probably have access to a vast part of the object graph.

Also note that both pointers and pointees are const. This means that all objects and all indirectly reachable ones are immutable[1]. In other words, our message sends are referentially transparent or maybe even pure, probably with the downside of complex "hidden" state.

But this seems backwards. What use is a immutable operating system? The real world does have state.

This is a requirement of versioning. At each point in time, the system is in a fixed state. A historic state can not be changed by definition. However, with the blink of an eye you can go backwards im time, fork a new branch of evolution and switch between several of them -- on an object/subtree level, of course.

Currently, I plan to use few special types of transparent native references, primarily for improving capability security. In this text, the focus lies on an update-following reference used to give its owner the impression that the current state of the system is mutable by allowing certain objects to always automatically reference the latest version of another object.

Unfortunately, a update-following reference reintroduces side effects, even if they are restricted to certain situations.

Consider the following snippet of code for such a system:

f := [ ... ].
((f value: x) = (f value: x)) ifFalse: [
    self error: 'Referential transparency?'.
].

Now that snippet will always pass if it is run in a context in which references are not automatically updated when a new version of an object is created[2].

Such modification of the context is required anyways. After all, we want to be able to "check out" historical state and continue to work from there. This requires even automatically updated references to point to the latest version of an object as it was at that point in time. Similarly, the context can be set up to only include object versions whose date is smaller or equal to the date the snippet was started to be evaluated.

This raises several questions. Can this simple and elegant[3] scheme reduce side-effects significantly? Can it improve the quality of the system? Is object-orientation without/with less/with controlled side effects possible?

Furthermore, code evaluation in this system is still following the execution-pattern and is not designed to be thought of as transformation of expressions. So, can such an object-oriented scheme provide a practically usable way to evaluate expressions lazily?

---

1. Let's ignore const-casts, the code above is just an illustration
2. This might not be completely true. How is nondeterminism handled, e.g. random numbers and external events/input?
3. Well, at least I hope it is simple and elegant.

Today, I decided to patent all of my ideas.

Just kidding.

But some days ago I found out that it wouldn't be strange (if it wasn't me). Apple has filed several patents for what could be used as a fine-grained versioning system stored in the cloud.

Boiling it down, someone using an application could request and then navigate a historic view of the content associated with the application in the past. Then the user could restore whatever they wanted of that previous state. Plus, by implementing the history in the earlier form of the application, users don't have to learn yet another piece of software or scroll through long lists of files.

This sounds similar to what I'm designing currently. However, among several differences, the concept I'm working on is orthogonal to the whole OS and ideally there won't be applications any more, since I opt for goal-orientedness.

Obviously, while having to be usable by default, the solution also has to be flexible and users should be able to control and reconfigure it if they want to.

Maybe the importance of having control over your data has become clearer to some after the recent failure of Amazon's cloud and the consequential loss of data. Maybe the importance of having control over your data will become clearer to some after the next failure, when the cloud may start to leak.

While clouds can be a good thing, shooting everything into the sky certainly is a recipe for disaster.

But all of what I've just been talking about is, in fact, nothing new[1]. I'm not going to lie and claim that these were my ideas.

Nanos gigantium humeris insidentes.

---

1. And that's not because Apple filed patents for it.

Ikiwiki

Finally, I don't have to write this blog by hand anymore.

Ikiwiki is a flexible and powerful wiki compiler. It is completely filebased, uses the revisions control system of your choice as backend and integrates well with your already existing project. There are various plugins, making it usable for issue tracking, blogging and various other tasks. See their homepage for further information.

The concept behind ikiwiki is really powerful, but, unfortunately, since it integrates very well with other software, its implementation suffers on traditional operating systems. However, it is still much better than other software available.

As you can see, I've already switched. This blog runs in passive mode, since I don't have the possibility to install the ikiwiki software on this server.