how about we get rid of "fast arrays"



Agreed.  We should have clean first-class array objects (whether hashed or
not), with consistent behavior.  First-class in the sense that they can be
passed as arguments, returned as values, assigned to variables, read, and
printed.  Consistent in the sense that the behavior should be identical
except in the specific cases where it is supposed to be different (that is
a little harder).

Currently, we don't have any consistent, Maxima-like way of notating an
array literal, either on input or on output.  We do have a notation for
one-dimensional lists [1,2,3] and two-dimensional matrices
matrix([1,2],[3,4]), but arrays appear as horrible internal Lisp objects:
make_array: {Lisp Array: #(NIL NIL NIL)}; or as non-readable lists:
listarray [#####, 3]; listarray/use_fast_arrays [false, 3].
Multidimensional arrays print as the underlying 1-dimensional array.

Dumping fast_arrays is a good first step, but there is more cleanup to be
done.

I would suggest a notation something like the following for the input and
output of array literals (hashed or not):

   [3, 4]  -- contiguous elements starting at index 1 -- should act
identically to a list
   [1 => x, 3 => y] -- array with undefined elements (hashed or not)
   [x^2 => 3, log(x) => 5]  -- general hash array
   [[1,2],[3,4]] -- possible notation for 2-d
   [3 => [1,2], 5 => [3,4]] -- possible notation for sparse 2-d
   [1, [2,3], [[4,5]]] -- well-defined as nested lists; do we want to allow
array-like access to it, e.g. x[2,2] => 3?

We also need a consistent way of handling undefined elements.  It is a bad
idea to use nil/false, 0 or und for undefined elements because those are
all perfectly good values (notably 'und' is a reasonable 'mathematical'
value for a limit).

        -s

On Fri, Jul 13, 2012 at 12:37 AM, Robert Dodier <robert.dodier at gmail.com>wrote:

> Considering that "fast arrays" (native Lisp hash tables) are, for most
> implementations, so far as I know, not much faster than Maxima hash
> tables, and furthermore that the two kinds cannot be equivalent, because
> Lisp hash tables cannot have Maxima's equality test, I wonder if we
> shouldn't just git rid of fast arrays.
>
> The only interesting thing about fast arrays is that they are in the
> value slot of a symbol. To get equivalent functionality with Maxima's
> hash tables, we would have to figure out a scheme for putting a Maxima
> hash table in the value slot....