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

AREF-1D (Version 4)

Besides changing arity-> rank and various  whichs to thats, I think I
probably made some other minor edits, but didn't intentionally change
the meaning. However, I do remember trying to soften the feeling that
you had to know and want MacLisp's LISTARRAY and FILLARRAY for this to
be a good idea, and to take the blow-by-blow of who liked what in
previous versions out of the discussion. Note that the issue is still
called AREF-1D even those the proposal is ROW-MAJOR-AREF. 

Status: Ready for release?

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)
               6-Jun-87, Versions 3, 4 by Masinter (editorial work)

Problem Description:

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


Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.

ROW-MAJOR-AREF is valid for use with SETF.


Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.

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

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

Currently, the only really efficient way to write this would involve
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 SYS:%1D-AREF.

Adoption Cost:

This change is fairly localized. In implementations that 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 or
compiler work to make ROW-MAJOR-AREF work efficiently.


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

Conversion Cost:

This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.


This allows certain programs to be written in a more aesthetic way.


The cleanup committee supports this enhancement.