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 ;-)
Currently,
std.listdescribes 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.vectorproviding 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 tostd.table, and promoting that file from a module (of functions) to a class (of Container).In that case, what to do with the
std.listnamespace? 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 ;-)