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

AREF-1D (Version 2)

I changed the name of the function from AREF-1D to ROW-MAJOR-AREF,
re-filled some of the text to fit better in 80-columns, and marked
KMP, GLS, Moon, JonL, Benson, and Pavel as supporting this amended
version in the Discussion field. Other than that, no changes.

-----Proposal Follows-----
Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman,
	      02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
Status:	      For Internal Discussion

Problem Description:

  It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
  efficiently in Common Lisp because they take arguments of varying
  arity. Currently, you have to make a displaced array to work with
  temporarily and then throw away the displaced array when you're done.
  In the case of FILLARRAY, I find this bothersome because there is no
  a priori reason why FILLARRAY should have to cons at all.


  Introduce a new function ROW-MAJOR-AREF which allows 1D access to the
  storage backing up a given array assuming the normal row-major storage

  This accessor should be valid for use with SETF.


  We already document the row-major storage layout and have a number of
  operators which allow users to exploit that order. This would be a 
  useful addition.

  LISTARRAY and FILLARRAY, for example, could be trivially defined by
  loops which had the following form:

      ... (ROW-MAJOR-AREF ARRAY I) ...)

  Currently, the only really efficient way to write this involves
  something like:

      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

  Many implementations have this primitive under some other name
  for use internally. In Symbolics systems, for example, it is 

Adoption Cost:

  This change is fairly localized. In implementations which already
  use this primitive internally, it's little more than a matter of
  changing the name of or otherwise releasing the existing primitive.
  In some implementations, it might involve writing a small amount of
  code (and associated compiler optimizers).


  This gives users efficient access to something which they already have
  inefficient access to.

Conversion Cost:

  This is an upward-compatible change.


  I think this allows certain programs to be written in a more aesthetic way.


  KMP and GLS support this proposal.

  Moon, JonL, Benson, and Pavel expressed conditional support of version 1,
  asking that the name be changed from AREF-1D to ROW-MAJOR-AREF. KMP and
  GLS did not oppose this change, so it was made for version 2.