CLHS: Issue TYPE-SPECIFIER-ABBREVIATION Writeup

#

## Issue TYPE-SPECIFIER-ABBREVIATION Writeup

    Date: Mon, 25 Feb 91 12:18:07 MST
    From: sandra%jensen@cs.utah.edu (Sandra Loosemore)

    This is a new version of an issue that was amended and approved at the
    June 1990 meeting.  Because there was a lot of confusion about the
    amendment and I am not sure that this revision accurately reflects
    its intent, I think we ought to vote again on proposal
    X3J13-JUN90-GUESS.

    Issue:            TYPE-SPECIFIER-ABBREVIATION
    References:       CLtL chapter 4
    Related issues:
    Category:         CLARIFICATION, CHANGE
    Edit history:     V1, 10 May 90, Sandra Loosemore
                      V2, 13 Feb 91, Sandra Loosemore (modified proposal)

    Problem description:

    Does it make sense for the type specifiers AND, MEMBER, MOD, NOT,
    OR, SATISFIES, and VALUES (which are documented as list form type
    specifiers in CLtL but omitted from table 4-1) to be abbreviated
    to their atomic form?  What about the EQL type specifier?

    Proposal (TYPE-SPECIFIER-ABBREVIATION:X3J13-JUN90-GUESS):

      Clarify that:

      (1) (AND) is equivalent to type T, but the AND type specifier list
          may not be abbreviated to a type specifier symbol.
          * is not permitted as an argument to the AND type specifier.

      (2) The EQL type specifier list requires an argument and may not be
          abbreviated to a type specifier symbol.
          * may appear as the argument to an EQL type specifier, but it
          indicates the literal symbol *, and does not represent an
          unspecified value.

      (3) (MEMBER) is equivalent to type NIL, but the MEMBER type specifier list
          may not be abbreviated to a type specifier symbol.
          * may appear as an argument to a MEMBER type specifier, but it
          indicates the literal symbol *, and does not represent an
          unspecified value.

      (4) The MOD type specifier list requires an argument and may not be
          abbreviated to a type specifier symbol.
          * is not permitted as an argument to the MOD type specifier.

      (5) The NOT type specifier list requires an argument and may not be
          abbreviated to a type specifier symbol.
          * is not permitted as an argument to the NOT type specifier.

      (6) (OR) is equivalent to type NIL, but the OR type specifier list
          may not be abbreviated to a type specifier symbol.
          * is not permitted as an argument to the OR type specifier.

      (7) The SATISFIES type specifier list requires an argument and may not
          be abbreviated to a type specifier symbol.
          * may appear as the argument to a SATISFIES type specifier, but it
          indicates the literal symbol *, and does not represent an
          unspecified value.

      (8) (VALUES) indicates that no values are returned, but the VALUES
          type specifier list may not be abbreviated to a type specifier
          symbol.
          * is not permitted as an argument to the VALUES type specifier.

       Rationale for proposal X3J13-JUN90-GUESS:

         ???

    Proposal (TYPE-SPECIFIER-ABBREVIATION:NONE):

      Clarify that the arguments to the AND, EQL, MEMBER, MOD, NOT, OR,
      SATISFIES, and VALUES type specifier lists may not be omitted
      or be given as *.  Clarify that these symbols are not standard
      type specifier symbols.

       Rationale for proposal NONE:

         It's not clear what the abbreviated forms of AND, EQL,
         MEMBER, NOT, OR, SATISFIES, and VALUES would mean.

         While MOD could be assigned a reasonable meaning, adding it
         to the list of standard type specifier symbols is a
         pointless change to the language.

    Current Practice:

      Unknown.

    Cost to Implementors:

      Trivial.

    Cost to Users:

      None.

    Cost of non-adoption:

      Part of the language specification will be vague and
      confusing.

    Performance impact:

      None.

    Benefits:

      Part of the language specification will be made more precise.

    Esthetics:

      Seems to be a matter of personal taste.

    Discussion:

      Proposal NONE was accepted at the June 1990 meeting with the following
      amendment, replacing the first paragraph of the proposal:

         Clarify certain type specifiers as follows:
          (AND)    is equivalent to T.
          (MEMBER) is equivalent to NIL
          (OR)     is equivalent to NIL.
         AND, EQL, MEMBER, MOD, NOT, OR, SATISFIES, and VALUES type
         specifiers may not be abbreviated to type specifiers that
         are symbols.
         AND, NOT, OR and VALUES type specifiers may not take * as
         an argument (i.e., as an unspecified type)

      Taken literally, this amendment leaves some questions unanswered,
      such as whether (EQL) is meaningful or what (EQL *) might mean.
      Proposal X3J13-JUN90-GUESS is my attempt at guessing what the amendment
      was really trying to say.

      Loosemore thinks that we ought to make MOD == (MOD) == (MOD *) ==
      (integer 0 (*)) == UNSIGNED-BYTE, but everybody else seems to hate
      the idea.

Copyright 1996-2001, Xanalys Inc. All rights reserved.