[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.