The Super (Lazy) Function

Here is a very interesting quote that illuminates much better an idea that I have been pondering over:

Machine language can be thought of as a concatenating language where the entire
memory state is the argument to a function (a machine instruction) and the next
entire memory state is the result. A program is one huge function
composition. (A detail I'm skipping here is that not only is the state of
the memory in the argument and in the result, but the state of the external world
is also part of that argument and result) --Jack Waugh on Uuu-devel mailing
list, Aug 30, 2006 10:33 AM. See post: [Uuu-devel] more languages

This is one of their posts on their list about the orthogonal transparent persistence. What it highlights is that a computer can be thought of as a function computer, where the state of the computer, and the state of the world is an argument. How is this applicable?

Well, in our lazy ways, we will say that a function f, takes the computer and world (c,w) as arguments f(c,w). Most functions only need a little of the total world of information. So we would make f a lazy function, that only calls for information when needed. Now the way this person has gone about it is to talk about machine level persistence. However, I feel like what is more important is the intent level persistence.

The key difference is that I am considering large scale functions f, rather than the machine code functions f, which are obviously much smaller. A key thing is that if we take the level of the functions to be intent level - like "make that text bold", or "get that text from the internet", then it might be possible, and I am pulling from thin air here, to move towards a fully lazy operating system, where all function calls are super lazy. That is, the file system itself is just a lazy machine, where if you apply a function to information on the hard drive, the function is recorded, but that is it.

What you need to store is only:

1. Pointers to the files/information that are being accessed, that is, the relevant pointer to c of f(c,w)
   
2. Actual caches of any information from the outside world that is received by the function, that is, a relevant copy of w, of f(c,w). Note that if the source also adopts a logging approach, we can simply move their entire log tree over to us, however that might involve a large scale information copy.
   

This also fits in with a hexagonal architecture + indirection layer architecture that surrounds all the edges of our architecture. However, it is true that all this laziness may have no real purpose, except as a way to achieve:

1. Very good bibliographies - all information is tracked from inception (that is, caches of information from outside world - including keyboard input, internet files etc. These input their selves may also be bibliographies)
2. Very good undo functions
3. Good exploration of where and how the information came to be
4. Good for analysts, although this is just a rehash of 3

Imagine a spreadsheet where all the information from each cell is directly traced to its source. Well, that is exactly what a formula is - it tracks the relationships, and ensures a good tracking tool. What this is then proposing is sort of a lazy, record file system, where functions are recorded.

The difference between a saved and unsaved file will then simply be that the unsaved file has a few more functions attached to the list. We can simply move about in time, looking at what the file looked like at various stages of its life.

How does this aid persistence? Well, persistence, which is: The computer stays in the same state even if you turn it off, behaving much like a TV or similar device. If the computer is turned off, we have all the files modified. If an unexpected turn off occurs, well, we still have

I even went as far as to consider what would happen if the file system was entirely composed of a log of operations done. The actual file content may not exist, although when such a system is optimized, we would invariably expect the actual file contents to be present, albeit in a cache or in temporary memory, or in some other construct.

The upside is that data structures are truly late made things - we only specify the process by which a file/information is created (the intent), rather than the actual physical, down to earth manifestation of it. Think of this as the super-meta-data-structure that can store anything at all - it is just a log after all. Of course, we will very definitely need to have optimized data structures if we want any practical efficiency.

But the benefit that comes from this lack of data structures is that now we have managed to separate it out from our minds. This gives us many potential benefits:

1. Data structure can be decided later. First design what the log entries will be - i.e. what you want to do
2. You can write several functions on the same information, except using different data structures. You can then write a structure converter. This upholds the hexagonal architecture
3. Flexibility increases
   

Although I wonder at the end usefulness of such an approach, since users will not be expected to directly interface with this, so it might be too much "behind the scenes work" for no outward gain.

So through this way, I have completely removed the need for reality, sanity of limits for computing. We have functions that are contract based - they do things, and they will be lazy about it. We have the world that they do things as a lazy world that does not exist, except as what functions have been applied. And we have a very busy demon, that ensures that everybody sees what they are supposed to see, magically.