Reviewed all the issues; Added a few comments for review.

wscl-issues/proposed/adjust-array-displaced-to-constraints

@@ -0,0 +1,117 @@
+Issue:          ADJUST-ARRAY-DISPLACED-TO-CONSTRAINTS
+Forum:          Cleanup
+Category:       CLARIFICATION
+Status:         proposed
+Edit History:   11-Jul-21, Version 1 by Jan Moringen,
+References:     ADJUST-ARRAY
+Related Issues: ADJUST-ARRAY-DISPLACEMENT
+
+Problem Description:
+
+  In the draft ANSI Common Lisp specification, the description of
+  ADJUST-ARRAY states that :initial-element and :initial-contents must
+  not be supplied if :displaced-to is supplied and
+  displaced-index-offset may be supplied only if displaced-to is
+  supplied.
+
+  Douglas Katzman notes two problems with this:
+
+  1.  :DISPLACED-TO could be given as NIL which almost surely should
+      not allow :DISPLACED-INDEX-OFFSET to be supplied.
+
+  2.  Similarly there is a problem with "initial-elements and
+      initial-contents must not be supplied if displaced-to is
+      supplied." because that would forbid ":initial-element 'foo
+      :displaced-to nil" which we have always allowed.
+
+  Also:
+
+  3.  no default value is specified for :DISPLACED-TO.
+
+Proposal (ADJUST-ARRAY-DISPLACED-TO-CONSTRAINTS:ALLOW-NIL):
+
+  This proposal changes the description of ADJUST-ARRAY so that
+  :displaced-to nil results in the same constraints on
+  :initial-element, :initial-content and :displaced-index-offset as
+  :displaced-to not being supplied.  The individual proposed changes
+  to the description of ADJUST-ARRAY are:
+
+  0. Change the sentence
+        "displaced-to---an array or nil. initial-elements and initial-contents must not be supplied if displaced-to is an array."
+     to "displaced-to---an array or nil. initial-elements and initial-contents must not be supplied if displaced-to is an array. The default is nil."
+
+  1. Change the sentence "Initial-element must not be supplied if
+     either initial-contents or displaced-to is supplied." to
+     "Initial-element must not be supplied if either initial-contents
+     is supplied or a non-nil displaced-to is supplied.".
+
+  2. Change the sentence "initial-contents must not be supplied if
+     either initial-element or displaced-to is given." to
+     "initial-contents must not be supplied if either initial-element
+     is given or a non-nil displaced-to is given.".
+
+  3. Change the sentence "displaced-index-offset may be supplied only
+     if displaced-to is supplied." to "displaced-index-offset may be
+     supplied only if a non-nil displaced-to is supplied."
+
+  4. Add the following sentence at the end of the "Exceptional
+     Situations" section: "An error of type error is signaled if
+     displaced-index-offset is supplied but displaced-to is either not
+     supplied or nil."
+
+Test Cases:
+
+  (defun one ()
+    (adjust-array (make-array 3 :initial-element 1 :adjustable t) 4
+                  :displaced-to nil :initial-element 2))
+  (one) => #(1 1 1 2)
+
+  (defun two ()
+    (adjust-array (make-array 3 :initial-element 1 :adjustable t) 4
+                  :displaced-to nil :initial-contents '(2 2 2 2)))
+  (two) => #(2 2 2 2)
+
+  (defun three ()
+    (adjust-array (make-array 3 :initial-element 1 :adjustable t) 4
+                  :displaced-to nil :displaced-index-offset 1))
+  (three) => ERROR: :displaced-index-offset must not be supplied when
+                    :displaced-to nil is supplied.
+
+Rationale:
+
+  ADJUST-ARRAY-DISPLACEMENT states "Note: Omitting the :DISPLACED-TO
+  argument to ADJUST-ARRAY is equivalent to specifying :DISPLACED-TO
+  NIL; in either case, the array is not displaced after the call ..."
+  so the behavior described in ALLOW-NIL was intended but not
+  specified precisely enough.
+
+Current Practice:
+
+  SBCL 2.1.1
+    (one)   => #(1 1 1 2)
+    (two)   => #(2 2 2 2)
+    (three) => #(1 1 1 0) ; not conforming under ALLOW-NIL
+
+Cost to Implementors:
+
+  TODO
+
+Cost to Users:
+
+  TODO
+
+Cost of non-adoption:
+
+  TODO
+
+Benefits:
+
+  TODO
+
+Aesthetics:
+
+  TODO
+
+Discussion:
+
+  TODO

wscl-issues/proposed/aref-accessor-dimension-error

@@ -0,0 +1,88 @@
+Issue:          AREF-ACCESSOR-DIMENSION-ERROR
+Forum:          Cleanup
+Category:       CLARIFICATION
+Status:         proposed
+Edit History:   13-Jul-21, Version 1 by Robert Strandh.
+                17-Jul-21, Version 2 by Robert Strandh.
+References:     AREF
+
+Problem Description:
+
+  In the draft ANSI Common Lisp specification, the description of
+  the accessor AREF indicates no exceptional situations.
+
+  It is therefore unclear what the behavior should be if AREF were
+  given an invalid index for one of the dimensions of the array given
+  as an argument.
+
+Proposal (AREF-ACCESSOR-DIMENSION-ERROR:SIGNAL-ERROR-IN-SAFE-CODE):
+
+  This proposal changes the description of the AREF accessor, so that
+  the section "Exceptional Situations" contains the following text:
+
+  "The accessor AREF should signal an error of type TYPE-ERROR if one
+  of the indices given is invalid for the array passed as an
+  argument."
+
+Test Cases:
+
+  (defun one (object)
+    (declare (optimize (safety 3)))
+    (aref object 1))
+
+  (one (make-array 1 :initial-element nil)) =>
+     ERROR: Invalid index 1 for array #(nil).
+
+  (defun two (object)
+    (declare (optimize (safety 3)))
+    (setf (aref object 1) 345))
+
+  (two (make-array 1 :initial-element nil)) =>
+     ERROR: Invalid index 1 for array #(nil).
+
+Rationale:
+
+  We think it was a simple omission from the draft ANSI specification
+  to not specify the behavior in this situation.
+
+Current Practice:
+
+  The following implementations signal a type error:
+  SBCL, ABCL, ECL, CLISP, Clasp
+
+  The following implementations signal a simple error:
+  CCL, CMUCL
+
+  TODO: Check other implementations, in particular Allegro and
+  LispWorks.
+
+Cost to Implementors:
+
+  Very small.  We believe that most implementations are already
+  signaling an error in safe code.  Some implementations may signal a
+  simple error, and those implementation would need to signal a
+  type-error instead.
+
+Cost to Users:
+
+  None.
+
+Cost of non-adoption:
+
+  Application programmers may need to add numerous
+  explicit checks to be certain that their code
+  is conforming.
+
+Benefits:
+
+  Application programmers may rely on an error being
+  signaled in safe code, and thus avoid having to
+  add explicit checks in portable code.
+
+Aesthetics:
+
+  No influence.
+
+Discussion:
+
+  TODO

wscl-issues/proposed/aref-accessor-rank-error

@@ -0,0 +1,84 @@
+Issue:          AREF-ACCESSOR-RANK-ERROR
+Forum:          Cleanup
+Category:       CLARIFICATION
+Status:         proposed
+Edit History:   12-Jul-21, Version 1 by Robert Strandh.
+References:     AREF
+
+Problem Description:
+
+  In the draft ANSI Common Lisp specification, the description of
+  the accessor AREF indicates no exceptional situations.
+
+  It is therefore unclear what the behavior should be if AREF were
+  given a number of indices that is not that of the rank of the
+  array given as an argument.
+
+Proposal (AREF-ACCESSOR-RANK-ERROR:SIGNAL-ERROR-IN-SAFE-CODE):
+
+  This proposal changes the description of the AREF accessor, so that
+  the section "Exceptional Situations" contains the following text:
+
+  "The accessor AREF should signal an error of type TYPE-ERROR if the
+  number of indices given is different from the rank of the array
+  passed as an argument."
+
+Test Cases:
+
+  (defun one (object)
+    (declare (optimize (safety 3)))
+    (aref object 0 0))
+
+  (one (make-array 1 :initial-element nil)) =>
+     ERROR: The value #(nil) is not of type ARRAY * (* *)
+
+  (defun two (object)
+    (declare (optimize (safety 3)))
+    (setf (aref object 0 0) 345))
+
+  (two (make-array 1 :initial-element nil)) =>
+     ERROR: The value #(nil) is not of type ARRAY * (* *)
+
+Rationale:
+
+  We think it was a simple omission from the draft ANSI specification
+  to not specify the behavior in this situation.
+
+Current Practice:
+
+  SBCL 2.1.3
+    (one ...)   => ERROR: The value #(nil) is not of type ARRAY * (* *)
+    (two ...)   => ERROR: The value #(nil) is not of type ARRAY * (* *)
+
+  TODO: check other implementations.
+
+Cost to Implementors:
+
+  Very small.  We believe that most implementations are already
+  signaling an error in safe code.  Some implementations may signal a
+  simple error, and those implementation would need to signal a
+  type-error instead.
+
+Cost to Users:
+
+  None.
+
+Cost of non-adoption:
+
+  Application programmers may need to add numerous
+  explicit checks to be certain that their code
+  is conforming.
+
+Benefits:
+
+  Application programmers may rely on an error being
+  signaled in safe code, and thus avoid having to
+  add explicit checks in portable code.
+
+Aesthetics:
+
+  No influence.
+
+Discussion:
+
+  TODO