[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: DECLARE-TYPE-FREE (Version 2)

Issue:         DECLARE-TYPE-FREE

References:    CLtL p.158

Category:      ADDITION

Edit history:  Version 1, 18-Sep-88, Moon
               Version 2, 22-Sep-88, Moon
                (small edits to reflect mail discussion)

Problem description:

  Most people interpret CLtL's phrase "(TYPE type var1 var2 ...) affects
  only variable bindings" to mean that code such as the following is
  not valid Common Lisp, because a type declaration can only be attached
  to a binding, not used free.
    (if (and (typep x 'fixnum) (typep y 'fixnum))
	(locally (declare (fixnum x y))
	  ...algorithm using x and y...)
	...similar algorithm using x and y...)

  Avoid the phrase "affects only variable bindings".  Clarify that a type
  declaration means that it is an error for the value of the variable to
  be not a member of the declared type, within the scope of the
  declaration.  Clarify that this makes the above program a valid program
  and that this kind of declaration means the same thing as inserting
  THE in every reference to the variable and every setq of the variable.
  Clarify that if nested type declarations refer to the same variable,
  the value of the variable must be a member of the intersection of the
  declared types.


  There is no reason to forbid this usage, and people have often asked
  for it.

Current practice:

  Lucid implements DECLARE-TYPE-FREE:ALLOW already, with a warning that
  it is an extension to Common Lisp.

Cost to Implementors:

  None, it is valid to ignore type declarations.

Cost to Users:

  None, this is a compatible addition.

Cost of non-adoption:

  Common Lisp will be less self-consistent.


  The above example will not have to be written in the following silly way,
  which only works if x and y are used read-only:
    (if (and (typep x 'fixnum) (typep y 'fixnum))
	(let ((x x) (y y))
	  (declare (fixnum x y))
	  ...algorithm using x and y...)
	...similar algorithm using x and y...)


  This provides a clean and simple way for the programmer to express what
  she knows about the values a variable may take on within a certain
  region of the program.  Different compilers will use this information in
  different ways; it's most aesthetic for the portable language to be free
  of assumptions about how the compiler will use this information.