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


Issue TYPE-DECLARATION-ABBREVIATION Writeup

TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL was passed 11-0 at the June 1990 meeting.

TYPE-DECLARATION-ABBREVIATION:FORBID-ALL failed 5-8 at the June 1990 meeting.

Issue: TYPE-DECLARATION-ABBREVIATION

References: CLtL p.158, and CLtL Table 4-1 (p.43)

ANSI CL draft spec p.6-56 (rev 7.31 of 8/29/89)

ANSI CL draft spec Fig 2-10, 2-11 (p.2-28, 2-29)

Related Issues: COMPILE-ENVIRONMENT-CONSISTENCY

LISP-SYMBOL-REDEFINITION

PACKAGE-CLUTTER

Category: CHANGE

Edit history: 1-May-90, Version 1 by Moon

4-May-90, Version 2 by Moon (update discussion)

6-Jun-90, Version 3 by Moon (update discussion)

8-Jun-90, Version 4 by Moon (reflect the X3J13 meeting)

Problem description:

TYPE declaration abbreviation, the ability to write

(DECLARE (<type-specifier> <var> <var>...))

in place of

(DECLARE (TYPE <type-specifier> <var> <var>...))

is allowed only for some <type-specifier>s, not for all of them.

CLtL allows the abbreviation only when <type-specifier> is a symbol

and not a user-defined or implementation-defined type.

The draft ANSI CL specification is unclear since it refers to the wrong

table. If it really meant to refer to Figure 2-11 rather than 2-10, then

it says the same thing as CLtL, assuming the mistakes in Figure 2-11 get

corrected (e.g. standard-generic-function is missing).

This makes a distinction between type specifiers specified by the

language standard and type specifiers defined by the user or by the

implementation. Do programmers have to know whether types they use come

from the kernel language or from a library in order to know whether they

are allowed to use abbreviated type declarations? Do they have to refer

to this table that currently contains 91 entries and is still growing?

This also makes an unnecessary distinction between type specifiers that

are symbols and those that are lists or classes.

This issue contains two proposals.

This is Symbolics issue #31 and is related to Loosemore's issue #8

of 27 Feb 90.

Proposal (TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL):

Allow the word TYPE to be omitted from all TYPE declarations.

A symbol cannot be both the name of a type and the name of a

declaration. Defining a symbol as a class, structure, condition,

or type name, when the symbol has been defined or proclaimed

as a declaration name, or vice versa, signals an error.

Examples:

(DEFUN SUBSTRING (STRING &OPTIONAL (START 0) END)

(DECLARE (STRING STRING)

((INTEGER 0 *) START)

((OR NULL (INTEGER 0 *)) END))

(SUBSEQ STRING START END))

(DEFSTRUCT SHIP HEADING TONNAGE PASSENGER-LIST)

(DEFUN EMBARK (P S)

(DECLARE (SHIP S))

(PUSHNEW P (SHIP-PASSENGER-LIST S)))

(DEFCLASS ASTRONAUT () (HELMET-SIZE FAVORITE-BEVERAGE))

(DEFUN CHECKOUT (A)

(DECLARE (#.(FIND-CLASS 'ASTRONAUT) A))

(UNLESS (EQ (SLOT-VALUE A 'FAVORITE-BEVERAGE) 'TANG)

(ERROR "~A is not a proper astronaut" A)))

Rationale:

Arbitrary syntactic differences between built-in facilities and

user-defined extensions are not in the spirit of Lisp.

Making type names and declaration names be a single namespace

eliminates any issue of ambiguity in interpreting a decl-spec.

Proposal (TYPE-DECLARATION-ABBREVIATION:FORBID-ALL):

Do not allow the word TYPE to be omitted from any TYPE declarations.

This would be an incompatible change.

Current practice:

I don't know of any implementation that implements either proposal.

Cost to Implementors of ALLOW-ALL:

Small. It should be easy to change the declaration parser to check

whether the car of a decl-spec is a valid type-specifier, and if so

either insert the word TYPE or signal an error, depending on whether it's

also a proclaimed declaration.

Cost to Users of ALLOW-ALL:

None to most users. Some users might have programs that use the same

symbol as both a declaration name and a type name, and they would have

to rename either the declaration or the type.

Cost of non-adoption:

An aesthetic wart on the language will remain.

Implementors will continue to have to maintain a large and seemingly

ever-changing table of type names that are acceptable as declarations.

Performance impact:

There might be a trivial increase in compilation speed as a result of

adopting either proposal. There should be no run-time performance impact.

Benefits:

Improved language consistency and aesthetics.

Esthetics:

Arbitrary syntactic differences between built-in facilities and

user-defined extensions are not in the spirit of Lisp.

Discussion:

Rob MacLachlan was concerned in February about non-obvious side-effects

of allowing user types here, but never mentioned a specific problem.

From re-reading his mail, he was most likely concerned only about things

that are not in this proposal.

Another possible approach would be to eliminate type declaration

abbreviation, however no one liked that idea when it was mentioned a few

months ago.

David Gray is opposed to allowing abbreviation for all types on the

grounds that infrequently-used types might not be recognized as types by

someone reading a program. Asked for suggestions, he said:

Well, if I had to be limited to twelve, I would choose:

ARRAY CHARACTER CONS FIXNUM FLOAT INTEGER LIST NUMBER

STREAM STRING SYMBOL VECTOR

but I suspect that this small a list would be too much of an incompatibility

to be acceptable since other people are sure to have a different favorite

twelve. It might be possible to agree on a list of around twenty, such as:

ARRAY BIT BIT-VECTOR CHARACTER COMPLEX CONS FIXNUM FLOAT

INTEGER KEYWORD LIST NUMBER PACKAGE PATHNAME REAL SEQUENCE

STREAM STRING SYMBOL VECTOR

David Moon prefers not to single out some types as special cases.

Glenn Burke is not entirely comfortable with the proposal, but doesn't like

restricting programmers' use of data-abstraction by singling out some types

as special cases.

Kim Barrett is concerned that signalling an error when there is a collision

between a type name and a declaration name doesn't really solve the problem.


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