Page Numbers: Yes First Page: 1
Heading:

April 26, 1979 7:34 PM[IVY]<krl>document>proc-signal

5.1 Signal Tables

Procedural parameterization in KRL-1 is done through a signal mechanism similar to that of KRL-0. A signalTable is a list of signalResponses, each consisting of a signalName followed by a list of actions. On a call to

(Signal signalName signalTable OKForNoAction)

if a response keyed by signalName is found in signalTable, the list of actions is performed. Each action can be one of the following:
a standard response OK, SKIP, STOP, or ABORT;
a function name (an atom other than a standard response);
a form for evaluation.
If the action is a standard response, that atom is returned as the value of the action. If the action is any other atom, it is applied as a function of no arguments. Otherwise the form is evaluated. The value of the last action is returned as the value of Signal. Any function which calls Signal is expected to be able to handle any of the standard responses. The intended meaning of each is as follows:

OKGo on with computation
SKIPSkip this local computation, but go on in the larger context
STOPStop computation in larger computation, normal exit
ABORTStop computation in larger computation, abnormal exit

The most significant difference between Signal in KRL-1 and the one used in KRL-0 is that there is no longer a dynamically bound signal path which is searched for a signal response. Instead, each call to Signal requires that the user specify one table in which the expected response is to appear. If no response is found in that table, then the action taken depends on the the value of the flag OKForNoAction. If OKForNoAction = T then Signal immediately returns OK. If OKForNoAction = NIL then DefaultSignalTable is searched; if no response is found in the table bound to that variable, then KHELP is called.

The data structure used to represent a signalTable is an association list. Therefore to add a new response, or replace an old response, in a previously existing signalTable, one need simply use CONS. For example, the following fragment would cause SimpleMatchTable to have a new local binding with the response to the signal FollowCoreferences causing a special function call to TallyRefs to be made before execution:

(PROG((SimpleMatchTable
<<’FollowCoreferences TallyRefs OK> ! SimpleMatchTable>))
...)

In order to facilitate modification of already existing responses, there is a function:

(NewActionForSignal signalName action signalTable actionListFlag)

which returns a signal table which is signalTable with one new response on the front. This new response consists of the action action followed by any previous actions for that signal in signalTable. If actionListFlag = T then action is treated as a list of actions to prefix the previous action list. The new signal table shares as much structure as possible with the signalTable given.