[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: TAGBODY-CONTENTS (Version 4)

I felt pretty good about this compromise solution.  I hope others
will, too. It permits duplicated tags if they are unused, and it
permits (GO NIL). Hopefully that will make everything that runs
now continue to run with no serious loss of aesthetic appeal.

I changed the proposal and extended the rationale.

References:	TAGBODY (pp 130-131 of CLtL)
Edit History:	13-Sep-88, version 1 by Walter van Roggen
		02-Oct-88, version 2 by Pitman
		 (beef up rationale, clarify tag NIL is ok)
		04-Oct-88, version 3 by Pitman (fix wording bug)
	        05-Oct-88, version 4 by Pitman
		 (modify proposal based on comments from Peck@Sun
	 	  -- allow both (GO NIL) and unused duplicated tags)

Problem Description:

  CLtL specifies that symbols and integers are valid tags
  in a TAGBODY and that lists are valid forms in a TAGBODY
  but is silent about other data types.

  Also, NIL is both a symbol and a list. Some implementations
  might permit (GO NIL) because they treat NIL as a tag,
  while others might not permit because they treat NIL as a form.


  TAGBODY treats symbols (including NIL) and integers as tags,
  and treats conses as forms.

  It is an error if an expression in a TAGBODY is not a symbol,
  an integer, or a cons. Implementations are forbidden from
  extending this syntax.

  It is an error to do a GO to a tag name for which the same
  (i.e., EQL) tag appears more than once in the body of the
  innermost TAGBODY containing that tag.

  The same restrictions apply to all forms which implicitly use
  TAGBODY, such as PROG and DO.


  The proposed set of tags is expressionally adequate.

  Other obvious candidate types have lurking problems that could
  lead to subtle program bugs if permitted as tags. For example,

   - Characters make bad tags because, for example,
     (TAGBODY ... #\Return ... #\Newline ...)
     will be an error in some implementations due to
     (EQL #\Return #\Newline).

   - Floats make bad tags because round-off error will vary
     between implementations.

   - Rationals have problems with reduction to lowest terms.
     eg, (EQL 1/2 2/4). This doesn't vary between implementations
     but may still cause surprises.

  Duplicated tags are permitted in situations where no GO is done
  to them primarily for two reasons:

   - To permit NIL to occur more than once in common situations
     such as:

     (defmacro foo1 (&rest args)
       `(do () ((test-fn))
	  ,(when (member :bar args) '(do-bar-thing))
	  ,(when (member :baz args) '(do-baz-things))

   - To permit the use of symbols as `dividers' between major
     sections of code. eg,

     (do (...)

  It is not our intent particularly to encourage either of these
  practices. Both are easy to work around. But current practice is
  to permit such uses in many implementations, and there was no driving
  reason to force such code to break.

Current Practice:

  Symbolics Genera documents that only symbols or integers are permitted.
  The restriction is enforced by the compiler, but not the interpreter.

  The TI Explorer permits using NIL as a GO tag, but as a special case,
  does not warn about multiple appearances of NIL.

Cost to Implementors:

  A few simple checks are probably all that's needed. Probably most
  implementations (both interpreters and compilers) already perform them.

Cost to Users:

  Unlikely to affect any portable code.

  If there are implementations which support other objects as tags
  (floats, for example), there may be simple editing necessary.


  One less place for portability problems to occur.


  Makes the language description more precise.


  This first appeared in ">GLS>clarifications.text" of 12/06/85.

  Historical Note (JonL, Steele):

    The reason pdp10 MacLisp allowed numbers, including flonums,
    as tags was that Ira Goldstein's LLOGO (a LOGO system
    written entirely in Lisp) just used READ for the statement
    numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.

  Pitman supports this proposal.