Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

Issue:         DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

References:    Array type specifiers, pp. 45-46

Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE

Category:      CLARIFICATION

Edit history:  Version 1,  7-Oct-88, Pierson

Problem description:

Array type specifiers appear to be useful both for declaring the
storage format of the array and for declaring the types of legal
operations on array elements.  Unfortunately, the current definition
of the meaning of array type specifiers does not require an
implementation to support the second use.

Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):

Within the scope of an array type declaration, all references to array
elements are assumed to satisfy the exact declared element type.  An
implementation should signal an error if this is ever violated.  A
compiler may treat the code within the scope of the array type
declaration as if each access of an array element was surrounded by an
appropriate THE form.

Examples:

(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))

(DEFUN FROB (AN-ARRAY)
  (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
  (SETF (AREF AN-ARRAY 1) 31)		; OK
  (SETF (AREF AN-ARRAY 2) 127)		; Should signal an error
  (SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
  (LET ((FOO 0))
    (DECLARE (TYPE (SIGNED-BYTE 5) FOO))
    (SETF FOO (AREF AN-ARRAY 0))))	; Declared to be safe

(FROB *ONE-ARRAY*)			; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*)			; Is probably an undetectable error

Note that the above definition of FROB is equivalent to:

(DEFUN FROB (AN-ARRAY)
  (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
  (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
	(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
  (LET ((FOO 0))
    (DECLARE (TYPE (SIGNED-BYTE 5) FOO))
    (SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))

Test Cases:

TBS

Rationale:

This mandates a useful and commonly expected behavior.  It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole.  The "should
signal an error" requirement permits compiler optimization while
requiring interpreters and low compiler optimization levels to perform
useful error checking.

Current practice:

???

Cost to Implementors:

Most implementations will have to extend the type checking in the
interpreter and low optimization levels of the compiler.

Cost to Users:

Some users might find that errors in existing code become visible for
the first time.

Cost of non-adoption:

Users will continue to expect declaration syntax to be more useful
than it really is.

It will be harder to debug code that uses arrays containing
specialized types.

Performance impact:

Highly optimized code should be unaffected.  Interpreted and
unoptimized code will run slower because of the additional error
checking. 

Benefits:

It will be easier to use the Common Lisp type system to catch
programming errors.

Aesthetics:

Improved because the meaning of type declarations will coincide more
clearly with their appearance.

Discussion:

Pierson supports this proposal.

JonL expressed support for the idea behind this proposal during the
discussion of ARRAY-TYPE-ELEMENT-TYPE-SEMANITICS but said that it was
a compiler committee problem.  This was submitted as a cleanup issue
anyway because it imposes requirements on the interpreter as well as
the compiler.