ARRAY-DIMENSIONS on #() array literals

[kengruven]

For some reason, the ARRAY-DIMENSIONS function always returns NIL for array literals built using the #() syntax, even though it works fine for arrays built using MAKE-ARRAY:

CL-USER> (array-dimensions #(1 2 3 4 5))
NIL
CL-USER> (array-dimensions (make-array 5))
(5)

This function is implemented using an oget call on the array, but that slot appears to be set by make-array, and read-sharp calls make-array to build the array. I'm not sure exactly what's going on yet.

[davazp]

Literal arrays are not created with make-array. The compiler knows how to dump them. The function dump-array' is responsible for this. Of course, it is wrong because it uses simple literal JS arrays.

I suggest to interpret literal JS arrays like vectors. So, if no dimensions slot is present, it is assumed to be a vector and handled properly by array-dimensions to return the correct value.

We still would need to dump multi-dimensional arrays properly however, when we have such thing.

[kengruven]

Aaah, I see now.

I'm working on adding multi-dimensional support to arrays right now -- I ran into this when writing more array tests!

I don't think there's a problem with treating JS arrays as CL vectors from array-dimensions and similar functions, but it looks like I need to extend dump-array for dimensions, anyway. I'll see what I can do here.

[kengruven]

I'm thinking about something like this:

(defun dump-array (array)
  (let ((elements (vector-to-list array)))
    (concat "(function(){var a=[" (join (mapcar #'literal elements) ", ") "];"
        "a.dimensions=" (dump-cons (array-dimensions array)) ";"
        "return a;}())")))

Of course, until there's reader support for multi-dimensional arrays, it's somewhat pointless, especially since it calls vector-to-list here.