*RSET is a debugging switch. If *RSET is not NIL, the interpreter keeps extra information (see EVALFRAME) and makes extra checks to aid in debugging. If NIL, many error checks are skipped, allowing faster execution at the risk of allowing certain errors to go undetected.

Sets the *RSET flag to NIL if val is NIL, to T if val is not NIL, and returns the value it set it to. See description of the variable *RSET.

The value of *RSET-TRAP, if not NIL, is the handler function for the condition which is signalled when an error returns control to top level, just before the bindings are restored.

The value of the variable controls the creation of UUO links by the UUO handler. If not NIL, then links will not get snapped; if NIL, the links will be snapped, providing faster speed. See also PURE and *PURE. Note: having this value be T, and perhaps doing (SSTATUS UUOLINKS) will be needed in an environment where TRACE-type functions will be used.

Sets the variable NOUUO to val.

[PDP-10 Only] Returns a list of interesting state information about the stack. Very heuristic and not very fast to do because it involves a MAPATOMS and consing, but requires very little info on the stack in order to do its thing.

Since *RSET dynamically controls whether debugging info is saved on the stack, this may not work as well if *RSET has been bound to NIL during the creation of all or part of the current state.

This is primarily useful as an interactive debugging tools. More complete debugging info is available from the ERRFRAME and EVALFRAME functions.

Displays the stack of pending function calls. An optional argument of a pdlptr (a fixnum; see EVALFRAME) or NIL (meaning show whole stack) may be provided. A printed form of BAKLIST.

The argument to evalframe is a pdl ptr, as with ERRFRAME, or NIL to get the most recent stack frame. The pdl is searched for an evaluation of a function call, using the same rules about starting point and direction as ERRFRAME uses. EVALFRAME always skips over any calls to itself that it finds in the pdl.

It returns a list (sym pdlptr form envptr), where sym is one of EVAL or APPLY; pdlptr is a pdl pointer to the evaluation in the stack, suitable for use as an argument to EVALFRAME or ERRFRAME or BAKTRACE; form is the form being evaluated (if sym was EVAL) or the name of the function (if sym was APPLY) being applied; and envptr is a fixnum pointer to the stack environment (sometimes loosely called an `a-list pointer' in memory of the days when variable bindings lived on an actual a-list) which can be used with EVAL or APPLY to evaluate something in the binding context which corresponds to the stack frame represented by this return list.

EVALFRAME returns NIL if no evaluation can be found. One way this can happen is if *RSET is bound to NIL and not enough debugging information has been kept, but it may happen in other ways as well.

[PDP-10 Only] FRETRY “unwinds” the stack to the point indicated by the first argument, which should be a pdl pointer such as would be in the list returned by EVALFRAME, and it then evaluates the form extracted from its second argument, which should be a list such as would be returned by EVALFRAME. It was intended primarily to be used to “re-try” something that appears to be losing, but which has been corrected (say, in an error break loop).

Returns control to the evaluation context designated by its first argument, which must be a fixnum pdl pointer and forces it to return val. This “non-local-return” function can be used to do fancy recovery from errors. (See also TRACE)

Whenever the function eval is entered, whether from within the system or by explicit invocation by the user, then if the value of the variable EVALHOOK is not NIL, and *RSET is not NIL, and (SSTATUS EVALHOOK T) has been done, then eval does not evaluate its argument. Instead it assumes that the value of the variable EVALHOOK is a function of one argument. It fetches this function, lambda-binds evalhook to NIL, and calls the function with the argument to eval. This function then has the responsibility for evaluating the form and returning a result. This result becomes the result of the original call to EVAL. It is evident that such a function can do other things besides evaluate the form; e.g. it can print trace information. The reason that EVALHOOK is bound back to NIL before calling the hook function is because the hook function may be interpreted, and we want to avoid infinite recursion. there is a problem, though: how can the hook function evaluate its argument once it has printed stuff out? If it just calls eval back again, then the variable EVALHOOK will be NIL, and the hook function will not get called for the recursive calls on EVAL. If it SETQ's EVALHOOK to the hook function and then calls EVAL, the hook function will get called back with the same thing. For this reason there is an EVALHOOK function.

Calls EVAL with its first argument, after binding the variable EVALHOOK to its second argument and bypassing the hook function check in EVAL. The third argument, env, is optional and allows the user to specify a pointer to an environment that the evaluation should occur in (see EVALFRAME).

On Multics, this function takes only the two required arguments; the optional env argument is not permitted.

The release notes for this operation say: “... (STATUS EVALHOOK) exists but does not return anything meaningful at all.” See (SSTATUS EVALHOOK ..) which is more useful.

Used to enable EVALHOOK operation. The variable *RSET must not be NIL and the variable EVALHOOK must contain a function which will handle the EVALHOOK'ing for this to have much effect (see the EVALHOOK function).

Returns NIL if (SSTATUS MAR ...) has not been done, else returns a list which is the state of the mar. The car of that list is the bits that have been set for the mar and the cadr is the location it is trapping on. Note that the bits will have 4 OR'd into them. This is because user mode trapping is forced. Hence, if (SSTATUS MAR 2 ...) was done, then (6 ..) is returned by this status option.

Using the MAR from DDT will not confuse Lisp, and Lisp tries not to confuse DDT. If Lisp is not using the MAR, then it doesn't even take the MAR interrupt from ITS, and so DDT can trap it.

Note: MAR interrupts may not work always correctly. Sometimes you can get infinite recursions because the MAR handler runs too soon and when it is done, the interrupt happens again without getting past the point that tripped it. Beware.

The variable MAR-BREAK, if not NIL, is a handler function which is called when the MAR break interrupt is received. The function gets one argument which presently is always NIL.

The MAR facility is a PDP-10 hardware feature which allows Lisp to detect when a given memory location is referenced and gives an interrupt.

Sets up a MAR breakpoint on a location, loc, with modes given by i, a fixnum, according to the following table:

On the KL-10, these additional values are reputed to work:

The 4 bit (Exec vs. User mode) is ignored (User is forced). The loc is any s-expression; that cell is the one monitored.

When the MAR-BREAK interrupt is signalled, an implicit (SSTATUS MAR 0 NIL) has been performed. It is up to the MAR-BREAK function to re-enable the mar if desired. This is similar to the operation of the alarmclock function. The intention is to help prevent infinite loops.

See also documentation on the MAR-BREAK variable which holds the handler for the MAR interrupt.

[PDP-10 Only] Returns the lisp symbol the address of whose subr/lsubr/fsubr property is such that the machine-address given as an arg is probably part of that definition, or "?" if it is not sure.

The TRACE facility is one of Lisp's oldest debugging tools. Args are not evaluated.

There are many options to TRACE, the simplest of which is (TRACE f), where f is a symbol naming a function to trace. This redefines f so that it types out when it is entered and exited.

If an argument field contains a list rather than a symbol, the car of the list specifies the function, f to be traced, and the remaining elements of the list specify how that tracing should be done. The following options are relevant:

Note that an arbitrary number of forms may follow ARG, VALUE, BOTH, or NIL. The results of evaluating these forms will always be printed out by the traced function upon entry and exit, regardless of whether args or return values are being traced.

The Lisp Machine function BREAK-IN can be simulated by

Tracing can be undone using UNTRACE.

Undoes a TRACE for the given symbols, which are not evaluated. If no symbols are given, all traces are undone.

This function is intended primarily for interactive use and does not become defined in Lisp until after a TRACE has been done.

Returns information about the number of available slots for linking between compiled functions. If no links, NIL is returned. Otherwise, the result is a list whose car is some information about purification and whose cadr is a count of free cells (probably only useful if you are out of address space).

Causes all links between compiled functions to be "unsnapped." This should be done whenever (NOUUO T) is done to insure that the interpreter always gets a chance to save debugging information on every function call.

If no data is supplied, returns information about the number of arguments expected by f. If f wants n arguments, ARGS returns (NIL . n). If f can take from m to n arguments, ARGS returns (m . n). If f is an FSUBR or a LEXPR, EXPR, or FEXPR, the results are meaningless; usually they will be NIL but that's not guaranteed. In the (m . n) case, an n of #o776 should be taken to mean infinity.

If data is supplied, ARGS sets the args information for f instead of reading it and returns f. Setting args info only works for compiled functions and should not be done for predefined system functions.

Examples: