SRFI-25 -- multi-dimensional array support.

[Rob Browning]

Guile already has similar functionality, and though I didn't have time
to fully review the SRFI, from what I saw, our existing array type may
be similar enough to be used as a base to implement the srfi.
Unfortunately some of our functions have the same name as functions in
SRFI-25, but have an incompatible signature.

Questions:

  1) Is anyone interested in working on srfi-25 right now?

  2) Is our array type close enough to be used as the underlying data
     type for srfi-25?

     Is it ok for our array? and srfi-25's array? perdicate to both
     return #t for the same object, even though their respective
     functions may manipulate that object in fairly different ways?
     (i.e. srfi-25 supports arbitrary index limits for each dimension,
     but Guile's built-in support doesn't.)

  3) How should we handle the API and type overlap

     -- build a completely different type for srfi-25?

     -- try to have (use-modules (srfi srfi-25) override the built-in
        functions where necessary?

     -- something else?

  4) In the *long* run do we try to merge our API with that of the
     srfi or keep both APIs/datatypes and keep them separate?

  5) Less importantly -- in the long run, should our built-in
     multi-dimensional array support remain built-in or should it
     become an add-on like the srfi, either a compile-time or run-time
     add-on?  We've found that Guile is quite useful on small
     platforms, and that tends to lead one to think about
     customizability (i.e. to consider arrangements that would allow
     small core + add-ons as needed).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD