{"action":"created","issue":{"url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/83","labels_url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/83/labels{/name}","comments_url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/83/comments","events_url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/83/events","html_url":"https://github.com/lua-stdlib/lua-stdlib/issues/83","id":40358071,"number":83,"title":"Shouldn't std.list be a linked list of 2-tuples?","user":{"login":"gvvaughan","id":50665,"avatar_url":"https://avatars.githubusercontent.com/u/50665?v=3","gravatar_id":"","url":"https://api.github.com/users/gvvaughan","html_url":"https://github.com/gvvaughan","followers_url":"https://api.github.com/users/gvvaughan/followers","following_url":"https://api.github.com/users/gvvaughan/following{/other_user}","gists_url":"https://api.github.com/users/gvvaughan/gists{/gist_id}","starred_url":"https://api.github.com/users/gvvaughan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gvvaughan/subscriptions","organizations_url":"https://api.github.com/users/gvvaughan/orgs","repos_url":"https://api.github.com/users/gvvaughan/repos","events_url":"https://api.github.com/users/gvvaughan/events{/privacy}","received_events_url":"https://api.github.com/users/gvvaughan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/labels/idea","name":"idea","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2014-08-15T15:40:25Z","updated_at":"2015-06-11T09:54:26Z","closed_at":null,"body":"Currently, `std.list` describes itself as \"Tables as lists\".\n\nBut 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).\n\nIn 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 ;-)"},"comment":{"url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/comments/111071609","html_url":"https://github.com/lua-stdlib/lua-stdlib/issues/83#issuecomment-111071609","issue_url":"https://api.github.com/repos/lua-stdlib/lua-stdlib/issues/83","id":111071609,"user":{"login":"gvvaughan","id":50665,"avatar_url":"https://avatars.githubusercontent.com/u/50665?v=3","gravatar_id":"","url":"https://api.github.com/users/gvvaughan","html_url":"https://github.com/gvvaughan","followers_url":"https://api.github.com/users/gvvaughan/followers","following_url":"https://api.github.com/users/gvvaughan/following{/other_user}","gists_url":"https://api.github.com/users/gvvaughan/gists{/gist_id}","starred_url":"https://api.github.com/users/gvvaughan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gvvaughan/subscriptions","organizations_url":"https://api.github.com/users/gvvaughan/orgs","repos_url":"https://api.github.com/users/gvvaughan/repos","events_url":"https://api.github.com/users/gvvaughan/events{/privacy}","received_events_url":"https://api.github.com/users/gvvaughan/received_events","type":"User","site_admin":false},"created_at":"2015-06-11T09:54:26Z","updated_at":"2015-06-11T09:54:26Z","body":"Some updates:\r\n\r\nI 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.\r\n\r\nHowever, 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.list` to `std.table`.\r\n\r\nSo 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."}}