On 14 June 2012 22:47, David Kastrup <d...@gnu.org> wrote: > Mark H Weaver <m...@netris.org> writes: > >> David Kastrup <d...@gnu.org> writes: >>> Scheme/Guile vectors are fixed size. [...] It is a bit of a nuisance >>> that one can grow a hashtable efficiently and on-demand, but not so an >>> array. >> >> 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?
Perhaps drop a basic resizable type in the guile-lib? Any implementation is going to be less-than-ideal in some situations. The guile core provides already a solid set of fundamental types which are very easy to compose to produce *exactly* the type required for any particular situation. > > 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. > I don't see how either hash table or multi-dimensional array type could benefit from a shared, resizable primitive – they are quite different algorithms, and both different again to the basic resizable vector already discussed. It is moot that hash table internally manages a vector and allocates a /new/ vector when needed. This is not a simple resizing operation. Are there any data types in the guile core which would benefit from sharing a resizable vector primitive?
