IsWith - Your ComCom Networking

Entrelac aims to become a real Operating System. However Building such a piece of software from scratch is not a single man project.

So, as a proof a concept, Entrelac prototype will be yet an other virtual machine on top of some existing software stack -typically a GNU/Linux system-.

This prototype may be divided into several components:
* "the arrows space"
* "lambda barre"
* "arrows publishers"
* "arrows subscribers"
* "arrows evaluators"

These components are delimited by clean interfaces. Possibilities are:
* programmable interfaces so that components are libraries.
* network interfaces so that components are stand-alone process, running either as clients or servers. These network interfaces may possibly be based upon persistent HTTP connexions.

==Arrows space==

Firstly, the "arrows space" was introduced in former posts. This component provides:
* un-redondant storage of atomic arrows (binary strings) and composed arrows (pointed pair) into persistent storage (disk).
* memory level automatic management aka 'orthogonal persistence'. See it as a software based cache in front of a disk based storage. Algorithm similar to a CPU cache algorithm. That's not to be confused with a disk cache algorithm. Remember disk paging is useless since there is no spatial locality inside the arrows space.
* very fast arrows retrieving. The arrows space is designed as a single open-addressed hash-table. Each arrow is indexed 3 times at 3 different hashes. Hashes are computed according to arrow head, queue or both. Binary strings are hashed by checksums.
* arrows rooting. Some arrows are said to be rooted. These arrows and all its ancestors are spared by the arrows sweeping mechanism. On the other hand, arrows which aren't rooted and don't belong to rooted arrows neither are candidate to deletion.
* unreferenced arrows sweeping. This feature looks similar to an incremental garbage collector.
* arrows set filtering and combination. This feature looks similar to the set of usual RDB query primitives.
* transactional disk write. Arrows creation and sweeping is cached in higher memory levels until transaction ends. The principle is similar to a /write-back/ cache. At transaction end, changes are recorded to disk as a linear writing log (for performance purpose). When system idle, the writing log is read and changes are dispatched to their real locations.

In some ways, the "arrows space" is similar to a classical multi-client RDBMS with advanced querying and 'triggers' features.

==Lambda barre==

The second major system component is called "Lambda barre" (TODO: english translation). This is the primordial engine which makes the whole system runs. It looks like a lisp machine but is even simpler. It handles the overall system interaction loop ; something like :
repeat forever: read one input arrow and compute {behavior := behavior(input)}

In other means, "Lambda barre" handles published arrows -sent by publishers as described hereafter- one by one and applies the system behavior function to it. This evaluation process is called a system iteration. Note each iteration is confined into a storage transaction so that Entrelac iterates between stable persistent states.

This system behavior function is actually defined by a root context. This "context" corresponds to flagged arrows among the arrows space, aka "rooted arrows".

Rooted arrows may be seen as pattern based rewriting rules. They defines how arrows may lead to some other generated arrows.

Actually, rewriting rules are recombination rules. They are based upon combinators, that is operators which don't relay on "variables". As is, "Lambda barre" language is nearest from "combinatory logic" theoretical language (see wikipedia:CombinatoryLogic) than "lambda calculus". It is almost as rudimentary as combinatory logic except from some additional operators related to arrows deconstruction and rooting.

Generated arrows may lead to persistent system knowledge change (through dedicated operators) or various side effects thanks to "arrows subscribers" which converts outgoing arrows into actions.

==Arrows publishers, subscribers, evaluators==

Arrows publishers, arrows subscribers, and arrows evaluators are software components located at system boundaries.

Arrows Publishers work mainly as "proxy" agents. They are representative agents of external (human or digital) agents such as logged users or connected external programs. They convert user input (eg. mouse & command line...) or protocol messaging (eg. http requests...) into published arrows. Arrows are built into the "arrows space" on the fly then forwarded to the "lambda barre" engine.

On the other hand, Arrows Subscribers convert back system generated arrows into external network messages or user graphical/textual messages or some hardware device commands. Subscriber agents receives system generated arrows they've subscribed for. The subscription mechanism is based upon a kind of arrows pattern matching. Subscribers work as representatives of the system from some external agents point of view. Arrows subscribers may be seen as arrows-to-effects gateways.

On this purpose, "Lambda barre" provides an explicit operator to "output" arrows. The "output" operator handles the routing of the generated arrow to subscribers according to the subscription table. Note, the overall process is asynchronous. There is no way for subscribers to immediatly return back a "result" of their job.

Therefore a complete communication channel (e.g. an user terminal) corresponds both to an arrows publisher and subscriber.

As a whole, the arrow subscribing/publishing logic is similar to a publish/subscribe messaging bus.

Arrows evaluators are somewhat similar to arrows subscribers. They are plugged into the "Lambda barre" process according to a subscription pattern as well. However, arrows evaluators are directly plugged into the evaluation process of "Lambda barre". They are provided with the "normal form" of any computed arrow which doesn't match any rewriting rule and matches their subscription patterns. Arrows evaluators do return a "result" which is substitued to the original arrow. The overall process is synchronous. An example of arrows evaluator is a mathematical expression evaluator which will substitutes an arrow based mathematical expression into its computed result (e.g. from "2 + 2" to "4"). When returning a computed arrow, an evaluator tells "Lambda barre" whether the result is cachable or not.

Arrows publishers, subscribers and evaluators are *not* powered by the system itself. They run at a lower level. Considering the Entrelac prototype, this lower level corresponds to the Linux host system. It means that this agents are not subject to system reflexivity. Even if some theoreticians might disagree, I want to notice human brain can't deeply change body machinery neither.

==Note==
Note about the universal cache feature: By default, all arrows imported by publishers, generated by evaluators, or produced during the Lambda Barre evaluation process are subjects to caching. They are kept in arrows space as long as possible. It allows formally imported binary strings or intermediate computed arrows to be recovered from system memory. This feature works both as a data cache (see http://en.wikipedia.org/wiki/Cache) and a computation cache (see http://en.wikipedia.org/wiki/Memoization). Work in progress.