Issue: TRACE-ERROR (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:        TRACE-ERROR
References:   TRACE (p440), UNTRACE (p440)
Category:     CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

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 (TRACE-ERROR: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 Case:

  (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.