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.