Software Lambdas are executable objects which act as small building blocks for creating ever larger programs with increasing sophistication. Lambdas differ from old style functions in several important ways:
These differences, from old style functions, allow the rapid development of larger and larger programs with ever increasing functionality.
The next wave of technological innovation must integrate linked organizations and multiple application platforms. Developers must construct unified information management systems that use the world wide web and advanced software technologies. Software Lambdas, one of the most exciting new developments in computer software technology, can be used to quickly and easily build integrated enterprise systems. The idea of having a software Lambda that can perform complex tasks on our behalf is intuitively appealing. The natural next step is to use multiple software Lambdas that communicate and cooperate with each other to solve complex problems and implement complex systems. Software Lambdas provide a powerful new method for implementing these next-generation information systems.
Nowhere is this more apparent than with modern Genetic Programming technology which can produce millions of complex analytic software Lambdas. None of these software Lambdas have a human author. They are all authored by machines. There are no human experts to guide in their deployment, to explain how they operate, or to describe the analytic techniques which they employ. Furthermore, just keeping track of the experimental results, of millions of analytic software Lambdas, can be a real housekeeping chore. It becomes rapidly obvious that a database capable of storing and serving analytic software Lambdas is necessary.
Analytic Information Server (AIS) is a database system designed to store and serve millions of analytic software Lambdas across the Internet, intranets, WANs, and LANs. Analytic Information Server is also capable of storing and serving vast quantities of XML data upon which these analytic software Lambdas perform their complicated analyses.
AIS is a powerful database environment combining Lambda technology and Internet server technology. It comes with a rich set of re-usable Lambda Libraries, a fast Lisp compiler, a built-in Lambda JavaScript compiler, an interactive Lambda debugger, and persistent Lambda repository with a flexible database schema. AIS is designed to store and serve software Lambdas which specialize in large volume data analysis, where microchip-level execution speed is a priority, and multiple gigabyte repositories are commonplace.
Any software Lambda served from AIS can be deployed directly over TCP/IP connections to any Internet browser on the World Wide Web, and can be deployed from any software product (MSWord, Excel, Project, etc) or user client application that can open a TCP/IP socket connection (which is to say almost all existing legacy applications).
An AIS Lambda is a concrete executable software object building block that is a fundamental unit of data stored in an AIS repository, and is mobile between copies of Lambda Information Server across the Internet. We make no a priori claims about the eventual capability of these Lambda objects; instead, we let any positive properties emerge naturally as the communities of these interacting Lambdas become more complex. In this manner of thinking, intelligence is not really a property of any one software Lambda object; instead, intelligence is an emerging property of a whole complex community of executable Lambda objects. For instance, it is very difficult to isolate any one human neural cell and make the claim that this particular cell is intelligent. However, one can grow billions of human neural cells in a complex interacting community (the human brain) under such conditions that most interested observers would consider the whole community of neural cells intelligent.
AIS Lambdas are concrete executable software objects with the following rudimentary capabilities. Lambdas are designed to work together in communities of other Lambdas forming complex adaptive applications. Lambdas can communicate with other Lambdas in the system, sharing information. An Lambda can reconfigure itself. If a situation arises that requires an Lambda to perform a new action, the Lambda can reproduce another Lambda and direct that Lambda to perform a different set of tasks. An Lambda has the rudimentary capability being goal-oriented, and may collaborate with other Lambdas to accomplish its goals. Lambdas have the ability to learn. Lambdas can be written in multiple computer languages, and can be executed under the control of multiple virtual machines. Lambdas can personalize the presentation of information. Lambdas can be asked to automatically perform small or tedious tasks such as locating a specific piece of information, or filtering through a large database looking for a set of conditions. Lambdas have the ability to execute at microchip-level speeds.
The ability of Lambdas to modify themselves as they learn and to interact with communities of other Lambdas, sharing knowledge and goals, presents opportunities for the development of powerful, adaptive data analysis solutions. Lambda data analysis applications may have adaptive user interfaces which learn the needs of different users and which adjust to changing data conditions.
Multiple Computer Languages
Each AIS Lambda is a concrete executable software object building block that is a fundamental unit of data stored in an AIS repository. Multiple computer languages can be expressed as executable Lambda objects. Analytic Information Server currently comes with a built-in Lisp compiler, a JavaScript compiler, an XML compiler, a natural language chatbot compiler, various Lambda query language compilers, and there is even an Lambda community which acts as a feature-based compiler compiler. It is certainly possible, and is currently often the practice to have communities of Lambdas which are not all produced by the same compiler. For instance, there are examples of parent Lambdas written in Lisp which have child Lambdas written in JavaScript and vice versa.
Analytic Information Server is agnostic in the choice of Lambda programming language. It is often the case that one computer language is preferable for certain data analysis applications while yet another computer language is preferable for other data analysis applications. AIS comes equipped with several Lambda compilers and rule-based tools for the easy creation of additional user-defined Lambda programming languages. The only caveat is that popular computer languages implemented in Analytic Information Server must be tailored to produce our executable Lambda objects, and to operate within the AIS runtime environment. AIS compiler development tools are not designed to create compilers for execution outside Analytic Information Server.
Multiple Virtual Machines
AIS Lambdas are designed to be write-once-run-anywhere executable objects. This is accomplished via the virtual machine concept of software Lambda execution. Lambda virtual machines are designed to be mapped onto the actual host microchip at the server location, providing faithful Lambda execution wherever the Lambda may travel on the Internet. There are currently several virtual machines operating within Analytic Information Server. The DRM virtual machine uses a Dynamically typed Register Machine model to provide portable Lambda execution from high level dynamically typed instructions all the way to super fast microchip-level register execution. The DRM virtual machine runs in emulation mode during the debug phase of Lambda development; while, during normal operation, the DRM virtual machine's just-in-time (JIT) compiler automatically converts Lambdas to run in the NATIVE code of the host machine. The NATIVE code is a faithful machine language translation of the execution rules in the DRM virtual machine onto the actual host microchip at the server location. DRM NATIVE virtual machine code always runs at microchip-level execution speeds.
Analytic Information Server is agnostic in the choice of Lambda virtual machine. It is certainly possible, and is currently often the practice to have communities of Lambdas which are not all running on the same virtual machine. It is often the case that one virtual machine model is preferable for certain data analysis applications while yet another virtual machine model is preferable for other data analysis applications. AIS comes equipped with several Lambda virtual machines and loadable library tools for the easy creation of additional user-defined Lambda virtual machines. The only caveat is that popular virtual machines (such as the Python, Java, or Smalltalk virtual machines) implemented in Analytic Information Server must be tailored to execute our executable Lambda objects, and to operate within the AIS runtime environment. AIS virtual machine development tools are not designed to create virtual machines for execution outside Lambda Information Server.
Microchip-level Execution Speeds
Analytic Information Server is primarily concerned with software Lambdas which perform high volume data analysis. Super fast execution speed is essential in such application domains. There are several levels of general computer program execution speeds. Disk based operations, such as those performed by SQL and other database system languages, are among the slowest executing animals in the program zoo. The next level of faster execution speed is achieved by programs performing memory to memory operations, such as those performed by COBOL and many other business languages. The fastest possible level of program execution is achieved by programs performing register to register operations on the microchip, such as those performed by assembler language.
The AIS DRM virtual machine provides very fast native execution of Lambdas performing disk based operations, memory to memory operations, and microchip-level register to register operations. Regardless of the data analysis domain, AIS allows the development of write-once-run-anywhere Lambdas which execute at the fastest possible speeds.
Multiple Programming Paradigms
AIS Lambdas are designed to operate in many different programming paradigms. Analytic Information Server is agnostic in the choice of Lambda programming paradigm. It is often the case that one programming paradigm is preferable for certain data analysis applications while yet another programming paradigm is preferable for other data analysis applications. AIS provides basic services and tools for: register to register programming; functional programming; object oriented programming; Lambda oriented programming; rule based programming; evolutionary programming; and natural language programming paradigms.
AIS comes equipped with basic services and tools for the easy creation of additional user-defined Lambda programming paradigms. The only caveat is that popular programming paradigms (such as the object oriented, evolutionary, or register to register) implemented in Analytic Information Server must be tailored to execute our executable Lambda objects, and to operate within the AIS runtime environment. AIS programming paradigm development tools are not designed to create programming paradigms for execution outside Lambda Information Server.
The Lambda object stores Lambda behavior and knowledge in a standard building block format (regardless of the original source language). The Analytic Information Server Lambda object contains the following properties:
| Av: | The arguments Structure object containing the Lambda's arguments. |
|---|---|
| EvalWhenDoomed: | The EvalWhenDoomed: property is set true iff the Lambda is to be evaluated, by the garbage collector, when it is doomed. |
| In: | The faces: Structure object containing the Lambda's published interface styles, current plans, goals, current capabilities, and any other information acquired during the learning stage. |
| Pc: | The Pcode Vector object containing the Lambda's virtual machine codes. |
| Pv: | The pvars: Structure object containing the Lambda's persistent variables. |
| Sv: | The svars: Structure object containing the Lambda's self object variables. |
| Cv: | The cvars: Structure object containing the Lambda's persistent class variables |
| Rv: | The regs: Structure object containing the Lambda's register variables |
| Nc: | The Native Code Vector object containing the Lambda's native machine code. |
| Sc: | The Source Code Vector containing the original language source for debugger display and recreation of the original Lambda. |
| Tv: | The vars: Structure object containing the Lambda's temporary frame variables. |
| Vm: | The Virtual Machine execution function (each Lambda may run on a separate virtual machine). |
An Lambda is a First Class Object. A First Class object in Lambda Information Server is any object that is fully exposed, i.e., all of the Structures are visible and modifiable by the other Lambdas in the system. All Lambdas have the following data structure elements: source code (Sc), pseudo code instructions (Pc), argument variables (Av), self object variables (Sv), persistent variables (Pv), persistent class variables (Cv), register variables (Rv), temporary variables (Tv), interfaces (In), native code (Nc), and the virtual machine emulator (Vm). All Lambda structures can viewed and modified by the programmer:
Each property is represented internally as a Structure Object. Any of the Lambda object properties can be displayed by referencing the Lambda and the property name using the Lisp or JavaScript dot operator (see the ref function).
The Lisp lambda function always returns an Lambda:
(setq anLambda (lambda(x)
faces:((english true))
pvars:(p1)
cvars:(c1)
vars: (t1)
regs: ((r1 Integer))
(defun child(x) (/ x p1))
(setq p1 100)))
Any of the Lambda properties may be referenced with the Lisp or JavaScript dot operator:
| anLambda.Pv | Returns | The Structure #{p1: #void child: #<Lambda 1234>} |
|---|---|---|
| anLambda.Cv | Returns | The Structure #{c1: #void} |
| anLambda.Tv | Returns | The Structure #{t1: #void} |
| anLambda.Rv | Returns | The Structure #{r1: Integer} |
| anLambda.In | Returns | The Structure #{ english: true } |
| anLambda.EvalWhenDoomed | Returns | false |
| anLambda.Cv.c1 | Returns | The value of the variable c1 |
Any of the persistent (Pv) attributes may be referenced directly with the dot operator:
| anLambda.p1 | Returns | The singleton #void |
|---|---|---|
| anLambda.child | Returns | The Lambda #<Lambda 1234> |
The special ref1 Lambda method may be used to set up an abstract Lambda event handler, which captures all access attempts (somewhat like a cell membrane):
(setq anLambda (lambda(x)
faces:((english true))
pvars:(p1)
cvars:(c1)
vars: (t1)
(defun child(x) (/ x p1))
(defun ref1(s) (writeln "Please do not touch my " s))
(setq p1 100)))
Notes & Hints
The ref1 Lambda method captures all access attempts (somewhat like an abstract cell membrane). When any other Lambda in the system attempts the following access anLambda.child, the access attempt will be intercepted and the String "Please do not touch my child" will be returned.
Analytic Information Server Lambdas are not designed to be run alone. They are designed to be run in small, medium, or large communities of other Lambdas. As the size of an Lambda community increases, its behavior can become increasingly complex, increasingly clever or intelligent. During the course of your contact with AIS, your will hear about many very complex Lambdas (such as the Alice natural language chat robot, or the parseLib compiler compiler Lambda). In actual fact, Alice and parseLib are not single Lambdas. They are large Lambda communities, working together to produce useful and complex results.
Any large community of Lambdas must designate some Lambdas to perform interface activities for the community. Lambdas in the community cannot all be equal. Many Lambdas, inside the community, must specialize in specific behavior for the good of entire community. Multiple internal areas of specialization is often the key to increasingly intelligent behavior.
In order for the terms inside and outside to make sense, when referring to an Lambda community, the community must designate one or more Lambdas to perform all interface tasks with other "outside" Lambdas. The designated interface Lambdas create an application interface supporting access conventions, for the community as a whole. Among other tasks, these access conventions protect the community's internal Lambdas from undesired access (analogous to the protections provided by a cell membrane or the skin of a biological community).
The simplest method for designating one or more Lambdas to perform all interface tasks is by proclamation. The designated interface Lambdas and the suported application interface and access conventions are published. Other external Lambdas are expected to behave honorably and abide by the published conventions. In situations where the trust between Lambdas is not absolute, Analytic Information Server allows Lambdas to inforce published access conventions, by making these reinforced Lambdas aware of any access attempts by other external Lambdas. Access attempts on any AIS Lambda are called events. Any AIS Lambda object may be made event aware. There are a number of designated events (which are described in the next section).
The following example shows how Analytic Information Server supports event handling for all Lambdas (see the table of Reserved Lambda Methods). Certain predefined events create conditions to which an Lambda may respond (if the designer so chooses). An interesting example of Analytic Information Server event handling support, is that an Lambda may be made aware of any attempt to access it. For instance, in the following nearly identical Lambdas, one is access aware and the other is not.
The parent1 Lambda, shown below, is unaware of the access attempts from any other Lambdas.
(defun parent1(x)
pvars:(p1)
(setq p1 x))
The parent2 Lambda, shown below, is aware of all access attempts from any other Lambdas and responds to the access attempt as programmed.
(defun parent2(x)
pvars:(p1)
(defun ref1(member) (* (myself).Pv[member] (myself).Pv[member]))
(defun set1(member) "Ouch! Please do not touch me.")
(setq p1 x))
Notes & Hints
For example, we can set the persistent memory of the parent1 and the parent2 Lambdas to see how an event unaware Lambda reponds versus how an event aware Lambda responds. The results are quite different depending upon whether the event unaware or the event aware Lambda is accessed.
| (parent1 10) | Returns | 10 |
| parent1.p1 | Returns | 10 |
| (setq parent1.p1 5) | Returns | true |
| parent1.p1 | Returns | 5 |
| (parent2 10) | Returns | 10 |
| parent2.p1 | Returns | 100 |
| (setq parent2.p1 5) | Returns | "Ouch! Please do not touch me." |
An Lambda community's designated interface Lambdas and suported application interface and access conventions are published via proclamation in the Interfaces section of each Lambda, and other external Lambdas are expected to behave honorably and abide by the published conventions. In situations where the trust between Lambdas is not absolute, Analytic Information Server allows Lambdas to inforce published access conventions, by making these reinforced Lambdas aware of any access attempts by other external Lambdas. Access attempts on any AIS Lambda are called events. Any AIS Lambda object may be made event aware.
Analytic Information Server supports reserved Lambda methods (child Lambdas) each of which has a special access event which it captures and manages. The reserved Lambda methods (if present) monitor and control actions taken upon the Lambda in response to these special access events, and can enforce the published access conventions of the Lambda community. These reserved methods are:
| Method | Trigger Event Syntax | Description of captured event |
|---|---|---|
| abortTrans | (abortTransaction anLambda) | Called when the abortTransaction built-in function attempts to abort a transaction with the Lambda. |
| beginTrans | (beginTransaction anLambda) | Called when the beginTransaction built-in function attempts to begin a transaction with the Lambda. |
| commitTrans | (commitTransaction anLambda) | Called when the commitTransaction built-in function attempts to close a transaction with the Lambda. |
| doClear | (clear anLambda) | Called when the clear built-in function attempts to clear the contents of the Lambda. |
| length | (length anLambda) | Called when the length built-in function requests the size of the Lambda. |
| new | (copy anLambda) (new anLambda) |
Called when the copy or new built-in functions attempt to clone or copy the Lambda. |
| ref1 | (ref anLambda x:) anLambda.x anLambda[0] |
Called when the ref built-in function, the dot operator, or the bracket operator attempt to access the Lambda with a single index argument. |
| ref2 | (ref anLambda 0 2) anLambda[0 2] |
Called when the ref built-in function or the bracket operator attempt to access the Lambda with two index arguments. |
| ref3 | (ref anLambda 0 x: 5) anLambda[0 x: 2] |
Called when the ref built-in function or the bracket operator attempt to access the Lambda with three index arguments. |
| set1 | (set anLambda x: newValue) (setq anLambda.x newValue) (setq anLambda[0] newValue) |
Called when the set built-in function, the dot operator, or the bracket operator attempt to alter the Lambda with a single index argument. |
| set2 | (set anLambda 0 2 newValue) (setq anLambda[0 2] newValue) |
Called when the set built-in function or the bracket operator attempt to alter the Lambda with two index arguments. |
| set3 | (set anLambda 0 x: 5 newValue) (setq anLambda[0 x: 2] newValue) |
Called when the set built-in function or the bracket operator attempt to alter the Lambda with three index arguments. |
| refImport | (importTab anLambda fileName) | Called when the importTab built-in function attempts to
import ascii tab delimited data directly into the Lambda.
Notes & Hints The refImport Lambda method captures all give me your next import record container requests by the built-in importTab function as it imports the contents of an ascii tab delimited file, record by record, directly into the Lambda. |
| setImport | (importTab anLambda fileName) | Called when the importTab built-in function attempts to
import ascii tab delimited data directly into the Lambda.
Notes & Hints The setImport Lambda method captures all please take this filled import record container requests by the built-in importTab function as it imports the contents of an ascii tab delimited file, record by record, directly into the Lambda. |
| refExport | (exportTab anLambda fileName) | Called when the exportTab built-in function attempts to
export ascii tab delimited data directly from the Lambda.
Notes & Hints The refExport Lambda method captures all give me your next export record requests by the built-in exportTab function as it exports the contents of Lambda directly into an ascii tab delimited file, record by record. |
One of the most important events occurs at the end of an Lambda's life span, just before the Lambda is destroyed. When an Lambda object is not longer referenced, the garbage collector may choose to destroy the Lambda. Before final destruction takes place, the Lambda will be sent a doomed message.
Each Lambda's EvalWhenDoomed property is initially set to false. Normally, garbage collecting an Lambda, causes nothing to happen (other than the destruction of the Lambda); however, if the Lambda's EvalWhenDoomed property is set to true, then the doomed Lambda is evaluated by the garbage collector BEFORE final destruction.
For instance, the following Lambda community opens a file and performs operations to the open file during the life span of the Lambda. When the Lambda is destroyed, we do not wish the file to be left open. The closeLog child Lambda has the task of responding to the doomed event and closing the file before final destruction.
This example shows how several Lambdas in a community can work together to open a file, keep it open during the life of the Lambda, and close the file before the Lambda is destroyed.
(defun fileLog()
pvars:(logFileHandle)
(defun closeLog() (setq logFileHandle (fileClose logFileHandle)))
(defun openLog(fileName)
(setq logFileHandle (fileOpen fileName))
(setq closeLog.EvalWhenDoomed true))
(defun writeLog(record) (fileWrite logFileHandle record))
;; Initialization
(setq logFileHandle false)
(setq closeLog.EvalWhenDoomed false)
true)
Analytic Information Server enforces strict Internet security as its default mode of operation. Obviously, for any Lambda database system, Internet security is a fundamental issue. Rather than suffer an unfortunate security breach, AIS enforces strict Internet security at all times.
Analytic Information Server supports three Internet (TCP/IP) protocols: HTML, XML, and AMP (Lambda Message Protocol) which is an XML extension protocol. Unless an Lambda declares itself as public (in the Interface section of the Lambda object), the Lambda remains unavailable to all Internet clients regardless of which protocol is being used by the client.
The AMP protocol allows individual Lambdas to be accessed by Internet clients being served by Analytic Information Server. The AMP protocol supports user security levels from 0 (lowest) to 7 (highest). In order to be available to an Internet client, using the AMP protocol, an Lambda object must publish its availability in its Interfaces section. The following example Lambda is accessible by AMP Internet clients with security levels of five or higher.
(defun clientHelper(msg)
faces:(;; This Lambda's interface proclamations
(public Amp:) ;; Is available to AIS clients using the AMP protocol
(security 5) ;; A client security level of five or higher is required
) ; end of Interfaces proclmations
pvars:(p1)
(eval msg))
Notes & Hints
Further details on the AMP Internet protocol may be found in the Lambda Message protocols reference guide.