[Indigo]<KRL>document>match-access!1

The basic calls to the matcher (Align, Seek, etc.) are CLISP forms. When first encountered, the access compiler is called. It checks to see if the signal table argument is of a form it recognizes and knows how to compile. If so it examines the arguments (typically each a nexus) and if it can, compiles a set of direct accesses which avoid going through the overhead of setting up the full matcher data structures. If for any reason, it cannot provide specialized code, it compiles the CLISP form into a call to the generalized matcher.

Note that this means that the environment in which a trigger or trap is run will depend on whether the call to Align which set it off is specialized by the access compiler, or is made into a general matcher call. The conventions for procedural attachment are designed so that a trigger or trap which is written to work in the simple (access-compiled) environment will have the same effect in the more complex environement provided by the full matcher. Whenever one is invoked, the variable FULLALIGN will be available to test. Triggers which do more complex things involving effective descriptions, goals, etc. need to check it before proceeding.

Detailed design of the compiler is not included here, since Rich has already done much of it and we need to coordinate. Details of the cases it handles are those of the associated signal tables. It may also turn out that for initial versions of the implementation, it will not handle the full flexibility of the binding and action Do meta-descriptions, and that the full Aligner will be run when they are used. It is possible to extend the compiler incrementally, since there is a fall back for anything it recognizes it can’t handle.

Many of the calls to the basic access functions of KRL-1 (Seek, Describe, and Match) will contain quoted descritpion structures specifying somthing about the access that is desired. For such calls, the general call to an interpretive function can be replaced (in Clisp fashion) by a more specific composition of function calls. This document indicates by example what some of the replacements may be, and by implication, what the underlying system access functions are.

Seek takes four arguments:
initialDescription: the thing being looked for,
resultDescription: what it should return,
stopDescription: how it should know when it has found it,
processDescription: and limitations on the process.

(Seek \the typicalSlot from a TypicalUnit thatIs !X/
returning \A Pointer/
stoppingFor \WhichIs Coreference/
allowing \WhichIs AccessOnly/)

where the key words identify each of the arguments to the seek form. This allows some of the argurments to be left out, and and set to default values. This call might be converted into:

GetPointer finds a coreference descriptor if it exists, and returns a pointer. Coreference descritptors include unit coreferences, slot coreferences, and Lisp entities.(What would a pointer be to a slot coreference. Does this include compact perspective which are primary?)

To simplify life, we have a standard set of defaults which we use with Seek. In general the resultDescription and the stop Description work as a pair. The defaults for \WhichIs IdentifiedAs (A Coreference) is to return \A Pointer/ and to allow triggerAccess. (The name of the trigger to identify an entity is needed here. I will will call it "ToIdentify" right now). The default for \A Labelled Anchor/ is to return \An AnchorForm/. It usually will allow AccessOnly, and no triggers.

Some more examples:

(Seek \the !Y from a Foo with s=1 thatIs Bar/
returning \An AnchorForm/)

converts into:

(GetFiller Y (GetPerspective ’Foo ’Bar \A Foo with s = 1/))

converts to:

(IF (temp ← (GetPointer (GetFiller ’s (GetPerspective ’U X)))) THEN temp
ELSE (BIND UNIT←X (FireTrigger ’s ’U ’ToIdentify)))