Motivated by recent discussions about standard libraries and codes, I have the following considerations:
The main problem to be addressed is not a set of 'blessed' libraries by Lua Team, but instead one repository of codes that the COMMUNITY TRUST, USE, IMPROVE and HELP to increase. It means, when someone on this list asks about a library, everybody must agree on a first default answer. Public libraries are blessed by the community, not a specific restricted set of people.
Reasoning. Lua community, at least on this list, is obviously well versed in programming/IT/CS which naturally leads to "I can write my 'best' library myself that do what I want in my way", and that's exactly the main problem. We can do it, but public libraries are useful exactly for ones that can't or don't want to write their own 'best' whatever. The ego of 'I can do it better' must be superimposed by 'it is enough for most of them'. "THEM", not "me".
Then, I propose the following project:
LuaDEAL - Lua DEad Alive Libraries
Lua Modules
They're not aimed to be "the best," most powerful codes, but something useful enough for someone doesn't need to reimplement the wheel again. They must have a well defined and stable "Lua-ish" API. Documentation is mandatory.
A) Composed mainly of categories:
Tomb1 - Lua-only libraries and codes
Tomb2 - Wrapper from well-established C libraries.
Tomb3 - Lua-only C libraries
B) The design must follow the philosophy of minimalist, modular software:
0) Open, community-based, development. MIT license whenever possible.
1) Lua's "mechanisms instead of policies," whenever possible.
2) They must do only one thing and do it well. The aim is to do a trivial job.
3) They must be as independent as possible but work very well together.
If you are wondering about examples, think about Lua itself and its standard library as well as lhf libraries.
C) Code Standards
1) Follow semantic versioning.
2) No use of globals, never, anywhere.
3) Standard headers for different modules.
3.1) Name of the module
3.2) Date of module creation
3.3) Author of the module
3.4) Modification history
3.5) Synopsis of the module about what the module does
3.6) Different functions supported in the module along with their input-output parameters
4) Exported API must follow the existing Lua names and design conventions.
5) Must work flawlessly on recent versions of Linux/Mac/Windows if the underlying necessary libraries are present.
If only a subset of the readers of the list really commits to public libraries, it means, codes for other ones use, I'm sure that a set of standard modules could be available for the community still this year. It obviously will require the rework os many wheels, fortunately to they R.I.P. on the repository for a long time. Public libraries are an exercise of detachment.
