Re: Growable arrays

[Daniel Llorens]

> Message: 2
> Date: Thu, 14 Jun 2012 10:33:36 -0400
> From: Mark H Weaver <address@hidden>
> 
> Although Scheme vectors should remain fixed-size for reasons I have
> given elsewhere in this thread, Guile also includes a more complex
> 'array' type that includes features such as arbitrary rank (i.e. number
> of dimensions), arbitrary lower bounds (not just 0), and shared views on
> the same underlying array with arbitrary affine mappings of indices.
> 
> Guile 'arrays' cannot currently be resized, but I see no good reason for
> this limitation.  They are already quite complex, and already require a
> second level of pointer indirection.
> 
> What do other people think?

I do not think this is a good idea. Guile arrays are just views of a vector. 
Are you proposing to have a separate array implementation? The resize operation 
clashes with the notion of shared views, and it only makes sense for arrays of 
rank 1. It can defined on the ravel (the old C++ library, Blitz++, has it) but 
I don't quite see how it would work in Scheme.

It's true that arrays are complex. They should be simpler. For example, I'd 
remove the arbitrary lower bound feature. Do people use it? I've never used it, 
and I use arrays all the time.

> From: David Kastrup <address@hidden>

> Another complex type, this time with quite more serious memory and
> performance impact, that can't be implemented on top of a simple
> resizable common primitive and has an almost, but not quite, overlapping
> underlying feature set?
> 
> It's almost as if you _like_ not being able to reuse code.

…

> Hash tables.  Apparently vlists.  I am not convinced that this does not
> make sense for normal and uniform vectors as an option as well.

Currently Guile vectors can be viewed as arrays of rank 1. If vectors become 
resizable, I think that there has to be a way to protect shared arrays from the 
resize operation.