Andy Wingo <wi...@pobox.com> writes: > Hi, > > On Mon 11 Jun 2012 11:55, David Kastrup <d...@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
