Page Numbers: Yes First Page: 1
Heading:
January 29, 1977 8:34 PM [IVY]<KRL>document>proc-formal-run
CHAPTER 5 -- INTRODUCTION TO THE INTERPRETER
Contents:
A. The structure of the interpreter
1. An interpretive framework based on semantics rather than structure
2. An interface between declarative representation and procedural specification.
3. The Master Function "Run"
4. LISP as the underlying procedural language
(including forward references to chapter 12)
B. Data structures in the interpreter
1. Semantic descriptions at the model level
2. Functional specification by description
3. Data types in KRL-1
(cf. note on data types at the end of <bsmith>interpreter.bravo)
4. Interpreter Records
(mostly forward refernces to chapter 9)
C. The reasoning process
1. The basic processes revisited
(more stuff from matshspecs -- in more detail)
a. Five Basic Functions
b. Category Hierarchies
c. Primary Anchors
d. Grounded Descriptions
2. The five main interpretive functions
a. Create
b. Describe
1. Parameters
2. Standard Functionals
3. Examples
4. Simple Cases
c. Seek
1. Parameters
2. Standard Functionals
3. Examples
4. Simple Cases
d. Match
1. Parameters
2. Standard Functionals
3. Examples
4. Simple Cases
e. Schedule
A. -- The Structure of the Interpreter
A.1 --
A.2 --
A.3 -- The Master Function "RUN"
As we all know, KRL-1 does not yet provide a general method of specifying procedures, and users must therefore still write there programs in INTERLISP. The KRL-1 Interpreter is a program which provides the user with the ability to interface with the declarative facilities that make up so much of KRL-1, providing as much of a process environment as we have worked out, including the multi-process agenda, frameworks for describing, seeking, and matching, and the ability to define new units and slots.
The interpreter that was provided with KRL-0 carried out these tasks by giving the programmer a large number of different INTERLISP functions, each designed to do one of the types of manipulation of KRL-0 data structures foreseen as necessary in writing programs. Entire classes of functions were "spec’d", although only a fraction of them were ever implemented.
In KRL-1, however, we have replaced this plethora of functions with a single function called RUN (but written as "$" in code). This means that all "calls" to the interpreter have the syntactic form:
($ aProcedureDescription)
such as for example (actually lots of functionals are defined so that you don’t always have to write this much out each time):
($ \a Describe with
anchor = SelfAnchor(’Fido)
newDescriptionForm = \a Dog /)
All of the complexities of specifying what kind of function you want, what parameters it should have, etc., have been moved to this single argument to RUN, which is a KRL-1 description of the interpretive procedure that you want executed. We can do this because we have worked out a coherent enough sense of what everything means to define the language and interpreter in terms of the infamous standard units (currently residing on [KRL-1]<bsmith>standardUnits.krl-1). By defining units for MatchProcess, DescribeProcess, etc., it is possible to describe all the subtleties of procedure specification within the syntax of the language, and the programmer can use those descriptions directly in writing his or her code.
This does not mean, of course, that the function RUN is magic -- it is easy to construct "sensible" descriptions of processes which do not fall within the capabilities of the interpreter. However the decision to specify interpretive functions in this descriptive way has a number of advantages:
1. The user does not need to learn numerous new syntaxes for how to specify arguments (such as how to specify only a few of a set of optional arguments, what order arguments come in, etc.), since the basic KRL-1 syntax already has methods of doing just those things.
2. We are committed to specifying in the standard units just what the design specifications of the interpreter are. By using those very definitions in actual code, the correspondence between usage and definition will be very strict.
3. In KRL-2 and its successors, as we learn more about how we really want to describe, rather than specify, processes to be run, descriptions of procedures will be cast within the declarative constructs of the language. This current convention is a step in that direction.
All calls to RUN have the same simple syntax, since it takes only one argument, which should be a KRL-1 description. However there is a subtlety about this function regarding its argument: if the argument is a quoted KRL-1 form (i.e. starts with the character "\"), it is common to want to have inside that quoted form some LISP expression which you would like evaluated before the whole argument is taken off and used. This can be done by prefixing any term that you wish evaluated with the prefix character bang ("!"). Any term which is prefixed this way will be evaluated, and the resulting LISP value will be used in place of the prefixed expression.
[What really happens is that before RUN hands its argument off to the KRL-1 reader, it changes any occurrence of "!" to "@whichIs LVIT ’ " (for "LISP Value at Interpretation Time"), which causes the reader to quote the appropriate term and put it into a standard footnote. Then, before using the description returned by the reader, RUN scans its argument for any such footnote, evaluates the LISP form, and then substitutes in the value instead of the original indirected description.]
For example, if you execute the code:
($ \a Schedule with
function = ’Foo
arguments = !<x y z> /)
then when RUN finally gets its argument the two filler pairs will be filled in with a LISP name and a LISP list which has as elements the values of the three variables x, y, and z. The schedule process will then schedule an apply of the function Foo to that list.