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.

Compiz and Information arrangement

What is it htat windows (the actual physical square boxes where you put your applications, not the MS product) do? THey provide a hand method to arrange your information into separate rectangles of information. HOw does this fit in with the model viewer controller worldview where there is information, there is functions that modify informatioin and there is viewers that take inforamtion and produce an output?

Well, the answer is that when we have lots of information that we want to see, we have what we call an arrangement of the inforamtion. An arrangement is simply a metaviewer that allows arbitary arrangement of viewers. Of course, when we have tables, we have table metaviewers that automatically tabulates each viewer. This is a similar thing, except for lots of information. So our metaphor still works. But we have just added an extra layer of complexity.

Now we face a more difficult question. What about the newfangled 3d information managers, such as the Mac style 3d graphics accelerators, things like Compiz+Aiglx combos for linux, and what has been proposed for the windows Longhorn? They propose a model where all windows are rendered onto planes that are t hen arranged into a 3d space. THis gives you really cool desktops, where you can literally have the sides of a cube as a desktop. Unfortunately, this does not seem to fit our viewers.

So far all I have said a viewer is something that manifests information - that is, it takes information (probably binary bits and pieces), and then it "realises" it into physical manifestations, such as 2d pictures or 1d sound. A meta viewer is something that allows the composition of informatin. Preferably, these containers would be both useful, and graphically pretty. So really, viewers are just special functions, where they take information and output information of type real-stuff. Where 2d and sound both inherit off. Thus things like compviz can be visualised as just another layer between the viewers and the actualy screen.

What we now have is :
Individual Viewers --> ( 3d plane --> Composition Manager --> 2d projection)--> Screen
We would probably implement this via implementing a general layer class, that joins communications between classes. Then all calls to the other class is redirected through the layer class. THis way, you can arbitrarily redirect your information without any recoupling of the compnents of hte viewers and the screen. Of course, somehow this layer class must be able to handle multiple incoming and multiple outcoming.

THis is just another layer using a more complex internal working, but externally it is all ok...

However, we get problems when we ask how we can make uses interact with the layers theirselves. I will tell you when I figure out. But it is to do with a semantic interface.

Implicit search

Implicit search is one of the new features that windows vista and some linux clones (they say they aren't clones) have. The idea is that as you type into a keyboard, the computer auto-detects when you have typed important (meaningful i supppose) keywords, and then applies a search to that. This seems just to be a version of lazy searching to me - where a search function is applied lazily to a word stream. So as you type, these words are automatically searched and the results displayed (or viewed) for you. As you can see, the concept of a viewer is very useful here, as we do not actually want many files opening, but rather to see them.

Another interesting feature is the smart folder idea used in Mac and the windows vista clone (they say they aren't clones). The idea is that a search query can be saved, and then used just as you would a normal folder. I suppose this goes to the concept of first-class objects, and all this is doing is making a search query a first class object which can be viewered as the results of the search. With appropriate system level hooks, this operation takes constant time. (if u hash). That also links to another point of my idea, where the entire operating system is just a really cool hash function, but that is another story.

Protocols - Shortcuts to Authorship

Protocol (diplomacy), the etiquette of diplomacy and affairs of state
Protocol (politics), a logbook or other artifact of a political meeting between persons from different nations
Protocol (treaty), a treaty or international agreement that supplements a previous one
Communications protocol, a set of rules governing communication between electronic devices
Protocol (computing), a set of rules governing communication within and between computing endpoints
Protocol (object-oriented programming), what or how unrelated objects use to communicate with each other in object-oriented computer programs

A protocol a contract that binds communicating parties. That is, a protocol states what messages and what responses will be communicated. In a sense, the event function defines the protocol. Protocols mean that we do not have to do everything, we can rely on some contracts being fulfilled.