[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DECLARE-TYPE-FREE (Version 5)
- To: email@example.com
- Subject: Issue: DECLARE-TYPE-FREE (Version 5)
- From: masinter.pa@Xerox.COM
- Date: 30 Sep 88 21:33 PDT
I added my reaction JonL's comment about nested types to the discussion
section. I also mentioned in the "Cost to Implementors" the possibility
that it might be necessary to remove error checks.
I think this is ready for release. Complain soon if you don't.
References: CLtL p.158
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
A style note might add that since nested type declarations intersect,
it would be bad style to have inner declarations be subtypes of the outer
ones. For example
(locally (declare (type x fixnum))
(locally (declare (type x (or bit package)))
(setq x 1)))
would be confusing. Such code might be generated by macros, however.