SRFI-25 -- multi-dimensional array support.

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI-25 -- multi-dimensional array support.

[Jeff Read]

On Sat, Sep 14, 2002 at 02:48:33PM -0500, Rob Browning wrote:
>   2) Is our array type close enough to be used as the underlying data
>      type for srfi-25?

I'm not sure... but it seems like this SRFI might be useful in deriving an array datatype that's abstract enough to handle dense or sparse arrays.

> 
>   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?

It is my hope that the more adaptable of the two implementations (SRFI, Guile) will subsume the other to the greatest extent possible. Having different datatypes floating around that do essentially the same thing in most cases is inconsistent with Scheme's general linguistic cleanliness.

In the meantime, I think the best thing to do would be to have the SRFI implementation be optionally loadable, and its API override Guile's, or vice-versa.

>   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).

Personally I like this idea. I use Guile as kind of a go-anywhere (well, anywhere there's POSIX) utility language, primarily. The ability to optionally remove extended functionality to get Guile into those hard-to-reach spots would be a welcome feature.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI-25 -- multi-dimensional array support.

[Christopher Cramer]

On Sat, Sep 14, 2002 at 02:48:33PM -0500, Rob Browning wrote:
>   2) Is our array type close enough to be used as the underlying data
>      type for srfi-25?
>   3) How should we handle the API and type overlap
>   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?

I remember someone saying before (Marius, I think) that we should
scrap our current uniform array code in favor of srfi-4, because the
array code we have is a huge pain to deal with. I think this applies
to multidimensional arrays as well, but I'm not so sure I'd want to
use srfi-25.

In any case, the array code in Guile is a huge mess and I'd be in favor
of deprecating it, especially since there seem to be good alternatives.

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"Gore would have finished ahead by the barest of margins had he pursued
and gained a complete statewide recount." -- Associated Press, 9/6/2002


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI-25 -- multi-dimensional array support.

[Gary Houston]

> From: Christopher Cramer <crayc@pyro.net>
> Date: Sun, 15 Sep 2002 16:20:31 -0500
> 
> On Sat, Sep 14, 2002 at 02:48:33PM -0500, Rob Browning wrote:
> >   2) Is our array type close enough to be used as the underlying data
> >      type for srfi-25?
> >   3) How should we handle the API and type overlap
> >   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?
> 
> I remember someone saying before (Marius, I think) that we should
> scrap our current uniform array code in favor of srfi-4, because the
> array code we have is a huge pain to deal with. I think this applies
> to multidimensional arrays as well, but I'm not so sure I'd want to
> use srfi-25.
> 
> In any case, the array code in Guile is a huge mess and I'd be in favor
> of deprecating it, especially since there seem to be good alternatives.

I think we should turn it into a module.  It has been around for a while
and probably shouldn't be deprecated too rapidly.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel