Continuously Evaluated Functions
A software pattern is continuously evaluated functions where the idea is that y = f(x) where x and y are two seemingly conventional pieces of variable data in the machine and f is a constant function.
(By constant I don’t mean that y does not depend on x, but that f does not change while x and y may change.)
x may be modified by certain classical methods, such as store commands, and that modification results in immediate or imminent change to y as sensed by load commands.
The magic is when neither the logic that reads y nor the logic that sets x need be aware of the arrangement and further that the execution of the code that evaluates y not be needlessly performed.
When I say that code X is “not aware” of function Y I mean that the code that arranges this magic Y need not be in the address space of code X.
In some systems such as Keykos, application code can get notification of stores into certain parts of other address spaces.
This is highly analogous to the trick with Keykos segment keepers to maintain a distributed mutable segment of several machines.
Here is the logic in Scheme.
The Quagmire of make
When the computing platform is able to run a program in an environment where its references to external data can be observed, then programs like the Unix make command can be replaced by much simpler mechanisms.
The make utility is not in a position to notice which header files are read during a particular compilation and thus requires such information be supplied in a Makefile.
There are auxiliary programs that attempt to derive this information from source files but those programs are language sensitive and error prone.
It is very difficult to remember to run those programs when it becomes necessary.
In Keykos it is possible to run the compiler and make note of the include files actually referenced during the compilation.
The information required in the Makefile is automatically generated as a natural byproduct of the compilation and the mechanism that keeps these relationships need know nothing of the language.
Write access to include files by editors can transparently signal that the most recent compilation of the source is no longer accurate and that the .o file is thus out of date.
When dependencies disappear this is learned immediately.
This cascades and no program like make need consider file modification dates to know what work is necessary to bring the build products up to date.
Http hash protocol
There is an http protocol to query the hash of a page.
(See “Content-MD5” in RFC 2616.)
No server implements this, I think, because available platforms provide no file change notification which could be used to maintain a coherent cache of file hashes.
Application to the Model-View-Controller Pattern
The Model-View-Controller Pattern is a natural candidate for this discipline.
Indeed this solves a vexing security problem as well as ensuring that the view logic of an application cannot corrupt the state of the model, which by definition it must not do.
The part of the application responsible for the view is charged with producing pixels or some other form of presentation.
It needs only sensory access to the data model.
The view logic can be relegated by top level application logic to a factory and instances are thus not in a position to corrupt the model proper.
This also plugs a covert channel from the user to the model if the display logic is privy to window layout as is commonly the case.
Lazy evaluation is a special case of continuous evaluation.
continuous evaluation is about the same as reactive programming.