On Dec 31, 2010, at 9:59 AM, Henning Diedrich wrote:
On 12/31/10 6:21 PM, Mark Hamburg wrote:
> On Dec 31, 2010, at 8:06 AM, Gaspard Bucher wrote:
>> I don't really grok why standard libraries are needed.
[..]
> [..] So, maybe the next question on standard libraries is
whether there are other issues that come up routinely that could
be solved with some targeted code in a standard library or whether
the length operator v holes is unique in this regard.
>
> Mark
There will sure be a standard library sooner or later. That Lua is
such a pleasure to re-build the wheel with may hold it up a bit.
The length operator is but a special discussion on list
efficiency, so I'd expect specialized lists like sets, ordered
sets, bags, duplicate bags, singly-linked lists, simple queues,
tail queues, and circular queues.
That's all lower level than the Lua table. But the row over # is
one over prices to pay. Core Lua decides this specific instance to
go against it's usual motto and be fast rather than clean. But
ultimately, for bigger stuff you need to be able to fall back to
the fastest and most stable solution for, e.g., your list problem.
Which you'd then hopefully find in the standard library.
For inspiration ...
http://www.erlang.org/doc/man/ets.html
http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/sys/queue.h.html
And lists would be only one aspect of such lib, if a most
important one. See the stuff in Penlight:
https://github.com/stevedonovan/Penlight
"a set of generally useful pure Lua modules,
focussing on input data handling (such as reading configuration
files),
functional programming (such as map, reduce, placeholder
expressions,etc),
and OS path management."
Which Steve writes is inspired by the Python standard libs:
http://docs.python.org/py3k/library/
Quoting from its TOC to get an idea. NOT to say this has to or
should be part of a Lua std lib or even Lua core. (And some
already is.)
I think this rapidly gets to be much larger than I would expect in a standard library for Lua. Certainly in any sort of initial distribution. While it would be good to have a larger set of community accepted batteries, I really think it would be better to focus first on whether there are recurring "issues" that could be mitigated with some targeted code.
Mark
|
