Re: Growable arrays?

[David Kastrup <dak@gnu.org>]

Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> On Mon 11 Jun 2012 11:55, David Kastrup <dak@gnu.org> writes:
>
>> Tables are a superset of what I need here.  I need the "growable vector"
>> aspect, not the "hash part" aspect.  Guile 1.8 only offers subsets:
>> "growable" does not come together with "vector".
>
> Why not just make your own growable vectors, then?  It will be just as
> efficient.

Sure, I will.  A native implementation would be able to benefit from
storage layout conditions that would, in some cases, allow extending the
array without allocating a new memory range, so it _can_ be done.

> Guile's hash tables are not designed to be addressed by index.

Sure they are: the hash _is_ being used as an index.  And one could
likely provide a "hash function" doing just that, but it would still be
storing a coalescing list in each bucket rather than a single element.

Most of the _mechanisms_ are there.  Just not user-accessible.

> I guess to summarize: if you want an abstraction like tables, you would
> build it out of vectors and hash tables.  But vectors and hash tables
> themselves are the lower-level building blocks.

Not low-level enough: they are already specialized in different
directions making them equally unsuitable for footing the bill.

>>> Lua (and JS) implementations typically have many different
>>> implementation strategies for their table-like objects.  For example,
>>> V8 has over two dozen.
>>
>> Uh what?  Lua has one implementation "strategy".  Array part, and hash
>> part.
>
> LuaJIT doesn't pack unboxed numerics in the array part?  I would be
> surprised.  I would also be surprised if it didn't do clever things in
> the "properties" part, as V8 also does.

LuaJIT is not Lua.  The point was that basic table usage in Lua (which
won't use preallocation) can't be mapped well to Guile's data
structures, and that is somewhat embarrassing.

In this particular case, Lua is just something used for namedropping
since it may be more relevant than my particular application.  In either
case, having to make the decision _either_ vector addressing _or_
growable is not really forthcoming, since hashtables _do_ use that
combination internally, so it is not really technical reasons preventing
it.

-- 
David Kastrup