[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Two suggestions on array adjustability.
- To: common-lisp@su-ai
- Subject: Two suggestions on array adjustability.
- From: walton%ll-xn.arpa@ll-xn.ARPA (Robert Walton)
- Date: Wed, 12 Jun 85 07:17:35 edt
We (Machine Intelligence and Tactical Sensors Project of MIT Lincoln Laboratory)
have an `image understanding operating system' called SKETCH written
in FRANZ and C and running on a VAX which has a large array package
that effectively replaces the FRANZ array package for our purposes.
Based on our experience with this, I do not think we could (optimally)
use COMMON LISP arrays for an image understanding system, and here are
two suggestions, triggered by the recent discussion of displaced arrays,
that might begin to fix this.
(1) Non-adjustability should be a dynamic declarable attribute.
If an array is declared non-adjustable in a block, it should be an error
to adjust the array when the block is active. The compiler
should make use of the declaration to optimize code.
However, when an array is in no such block, it should be adjustable.
Non-adjustability of a displaced array implies non-adjustability of
the array it is displaced to.
We often adjust displaced arrays and then pass them off to C code that
treats them as non-adjustable (given a good enough COMMON LISP compiler
we might, sometime in the future, replace the C code with COMMON LISP code).
[I would guess that non-adjustability could never be the same as simplicity,
since the later may imply a different array header structure, and untagged
hardware should know about this difference at compile time if possible.]
(2) Displaced arrays should be allowed to have non-standard subscript
multipliers. Negative multipliers and 0 should be allowed.
We use this most frequently to transpose arrays and reverse left and right
or up and down. It is obviously applicable to decimating arrays,
though we have little actual experience with this.
I offer these suggestions from the user's point of view only, though they
certainly seem implementable to me (after being refined to make them
more precise).