On Sat, Jun 9, 2012 at 2:32 PM, David Kastrup <dak@gnu.org> wrote:

Hi,

the main data structure of Lua is a "table", an associative array, and a
table t has a continguous numerically addressed part from 1..#t, with
all other indices going through a hashing mechanism.  One principal
distinguishing feature, like with a Scheme hashtable, is the ability to
grow on-demand.

Scheme/Guile vectors are fixed size.  Now I have a situation where I
have a basic type lattice with records stored in vectors, and this type
lattice may be extended dynamically (which typically happens at the
start of a whole file, for potentially multi-file runs).  Scheme does
not offer a suitable data structure for that.  It is a bit of a nuisance
that one can grow a hashtable efficiently and on-demand, but not so an
array.

Now it would be possible when the type lattice gets extended to store
the new entries in a hashtable and go from there.  Or put them into a
list, and reallocate on first access beyond the existing element.  That
seems rather contorted.  And since there is, if I remember, a project to
run Lua on top of Guile, having a fundamental and reasonably efficient
data structure corresponding to a Lua table, or at least the contiguous
part of a Lua table, would seem like a reasonably useful idea.  After
all, there already _is_ such a mechanism underlying hash tables so it
seems somewhat peculiar not to have it available for vectors as well.

Suggestions?

--
David Kastrup



I don't know how much you know about data structures, and I must confess I'm not very educated on Guile or Luas implementations. Based on what you are writing I would assume that the scheme hashtables aren't growable in the same way as a vector has to be growable. The number of elements in a hashtable isn't limited by it's "size". They are often implemented as each position (where the hashtables size is the number of positions) being a linked list giving the hashtable (in theory) limitless actual size. Growing a vector/array involves having to allocate new continuous memory and copying all the elements there, so for example in C++ (i think) the std:vector is increased by half it's current size each time meaning that the more expensive the copying gets the more elements you can insert into the vector before it has to resize.

I would assume it wouldn't be that difficult to implement a pretty efficient growable vector for scheme.

// Krister Svanlund