Cleanup Issue TRACE-ERROR

Status
For Internal Discussion
Category
CHANGE
References
TRACE (p440), UNTRACE (p440)

Problem Description

TRACE does not signal an error when given invalid options in some implementations. For example, more than one implementation might an extended syntax such as: (TRACE (FOO {key value}*)) but they might still vary as to what options they provided. In some such implementations, GET might be used to detect the options the implementation is interested in, rather than iterating down the list trying to determine which options really apply. As such, if (TRACE (FOO :WHEREIN BAR)) is done by someone used to an implementation that allowed a :WHEREIN keyword, an implementation might simply ignore the :WHEREIN keyword. It may not be until a computation is well underway that the ignored (possibly mis-named or mis-spelled) keyword is detected. Backing up to retry the trace once the problem is detected may be expensive and frustrating.

Proposal (REQUIRE-SIGNAL)

Permit the use of non-standard syntax, but require that TRACE and UNTRACE do careful syntax checking and signal an error if any unknown options or syntax are used.

Test Cases

(TRACE (FOO :WHEREIN BAR)) might mean any of a variety of things, but would not be permitted to just trace FOO and silently ignore the :WHEREIN option as if it had not been specified.

Rationale

TRACE is an environmental interface which varies greatly between implementations. Implementors moving frequently between implementations can get confused about which implementation they are dealing with and make mistakes that were trivially avoidable by simple error checking at the proper time.

Some errors of this kind are not eliminated by this proposal. For example, two implementations may use the same syntax and/or option in different ways. However, in many cases where implementations offer extensions, the namings are not done in a vacuum and they frequently try to agree on naming -- so this problem is more rare than random chance might suggest. In any case, this proposal clearly reduces risk of error even if it does not eliminate it.

Current Practice

Implementations are currently permitted to ignore spurious TRACE options/syntax because of TRACE's weak contract, and many do.

Cost to Implementors

Trivial error checking would have to be added to TRACE and UNTRACE.

Cost to Users

This change is upward compatible.

Cost of Non-Adoption

Some interactive problems would continue to be likely to occur periodically.

Benefits

A possible source of interactive debugging error is removed.

Aesthetics

Users will feel a little safer.

Discussion

Pitman wrote and supports TRACE-ERROR:REQUIRE-SIGNAL.

This issue came up while debugging Macsyma on a system which quietly ignored what Pitman felt were TRACE options that should either be used or complained about.

Edit History