Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I don't have any record of this issue being discussed.  If I'm
coming in late, please ignore and forgive me.

    Date: Fri, 07 Oct 88 17:19:22 EDT
    From: 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

I don't think this has any actual interactions with the issue
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, since
DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES is about ARRAY type specifiers for
declaration, while ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS is about ARRAY type
specifiers for discrimination.

    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.  

That's reasonable.  However, this is not a CLARIFICATION but a CHANGE,
since CLtL p.46 seems to be quite clear that the current meaning of such
a TYPE declaration is that the array elements satisfy the implementation
element type (what JonL calls the upgraded type), not the exact declared
element type.  Since your proposed new definition is more restrictive,
some portable programs that used to be correct may now be in error, hence
this is an incompatible CHANGE.  I think I'd vote for it anyway unless
someone argues that there is a significant impact on users.

								      An
    implementation should signal an error if this is ever violated.  

That's not reasonable.  The status quo for type declarations is that
a violation "is an error".  Changing it to "signals an error" is likely to
meet enormous resistance especially from stock hardware implementations,
and I think even changing it to "signals an error at the highest SAFETY
setting" would meet significant resistance.

								     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.

That's a good way to define it (except you shouldn't assume that letting
everyone work out for themselves what the "appropriate THE form" is means
they will all come up with the same answer!).

    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.