Re: Lua library bank?

[Dirk Laurie <dirk.laurie@...>]

2013/3/9 David Heiko Kolf <kolf@gmx.de>:

>
> In my opinion even the libraries in LuaRocks are not all high quality.
> And to me that is one of the problems in the Lua universe.  The Lua
> interpreter is really high quality, but I am often not satisfied by many
> of the libraries.
>
> So I would prefer a standard library where all the code follows some
> coding style document, that gives general advice on how to write a good
> C module or a good Lua module.
>
…
>
> - Even more subjective and hard to define, but a module should show some
> "Lua-style".  Sometimes I see a module and it looks to me like raw C
> bindings and I keep thinking that the API might be a lot simpler in Lua.
>
…

David, this is the most useful post in this thread so far. It gives
criteria to which software in the library bank should conform.

Let's turn it into a constructive proposal.

1.  Once the debate on your guidelines (there is bound to be some
    disagreement — this is lua-l!) has settled down, we start a page
    LibraryBank (or whatever) linked to LuaAddons on LuaWiki saying:
    these are the guidelines, and here is a list of modules claimed to
    conform to them, each complete with a short description and a link
    that takes you to the repository where it can be found.

2.  The normal dynamics of a Wiki maintains that page: anyone may add a
    new item: the developer, an enthusastic user, anyone. Since LuaWiki
    does not have Talk pages, negative experiences should just be added
    by the dissatisfied user (keep it short: "last updated February
    2009", "fails to build on Solaris" etc.).

3.  Software developers can consult that page before releasing their
    software to decide whether to aim for those standards. We must not
    be too strict: we should not exclude software which, for a good and
    unavoidable reason, fails to follow some particular guideline. For
    example: we may decide that all modules written in C should conform
    to the same standard of general portability as the Lua source code,
    but someone may write software for which C99 is essential. Such a
    transgression should not be grounds for exclusion, as long as it
    is clearly stated and well motivated.

4.  We could design our own .css style for documentation, different
    enough from PUC-Rio's style to make confusion unlikely, but used for
    all software that makes the LibraryBank grade. Authors could provide
    documentation in Markdown to make the HTML conversion automatic.