Repository navigation
Shouldn't std.list be a linked list of 2-tuples? #83
Description
Currently, std.list describes itself as "Tables as lists".
But we also have vectors for that -- excepting that they work best when the elements are homogenous, and preferably primitive. It seems to me that, analogously to std.vector providing methods for "Queuey" vectors or "Stacky" vectors, the best way to use "Tables as lists" is to have "Listy" tables facilitated by moving appropriate methods to std.table, and promoting that file from a module (of functions) to a class (of Container).
In that case, what to do with the std.list namespace? I think it would be infinitely more useful to keep a very similar api, but change the implementation to being a linked list of cons cells -- if nothing else, it would provide a nice generalization for ZLisp ;-)
Activity
[-]Shouldn't std.list be a linked list of cons cells?[/-][+]Shouldn't std.list be a linked list of 2-tuples?[/+]gvvaughan commentedon Jun 11, 2015
Some updates:
I now think that Vectors were misguided, although the "Stacky" and "Queuey" methods were nice, so I'd like to find a place for them in stdlib at some point. Also, the main driver of the Vector objects was as a reusable implementation of the core Zile editor buffers - but actually, luaposix's curses binding already has a much more performant and richer structure for strings of attributed characters.
However, we don't want to bloat stdlib with separate queue and stack ADTs, nor should we obfuscate the idea of a Lua table with the current stdlib "Listy" tables. Tuples are already useful as a better way to store non-mutable data for functional style programming, and I stand behind the idea that a 2-tuple based linked list is a better use of the List namespace than just as somewhere to collect "Listy" apis for Lua tables. In fact, we long ago migrated the "tabley" apis out of
std.listtostd.table.So the idea of this issue is still a good one I think, we just needed to reframe it terms of the current state of stdlib.