Issue: TAGBODY-CONTENTS (Version 2)

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

Changes...

 - I thought it would be good to merge the discussion as Rationale.

 - Several sections seemed to think that this proposal was making this
   a "signal an error" situation. Since it was only "is an error",
   implementations were still permitted to diverge. I corrected this
   to make the change forbid implementations to extend the syntax.
   I changed the proposal name from RESTRICT to FORBID-EXTENSION for
   ease in referring to both proposals in case a problem comes up.)

 - I also noticed a funny(?) ambiguity about NIL in a tagbody -- it's
   both a symbol and a list. Can you GO to it? I decided to address this.

Hope the result is still non-controversial.

-----
Issue:		TAGBODY-CONTENTS
References:	TAGBODY (pp 130-131 of CLtL)
Category:	CLARIFICATION
Edit History:	13-Sep-88, version 1 by Walter van Roggen
		02-Oct-88, version 2 by Pitman

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.

Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):

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

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

  It is an error for the same (EQL) tag to appear more than once
  in the body of a TAGBODY.  (However, a TAGBODY may have the
  same tag as another TAGBODY in which it nests, in which case
  the tag in the outer TAGBODY is shadowed, as already specified.)

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

Rationale:

  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.

Current Practice:

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

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.

Benefits:

  One less place for portability problems to occur.

Aesthetics:

  Makes the language description more precise.

Discussion:

  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.