Re: Idea: Reference Libraries

[Andrew Starks <andrew.starks@...>]

On Mon, Apr 21, 2014 at 11:11 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-22 4:05 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
>
>> Also, the idea of "blessed" libraries had come up in the past.
> ...
>> (by motivated individuals).

The parenthetic was to contrast the implication that I was suggesting
that  PUC/Rio would want to include back ports of future libraries. If
someone wanted, for example, utf8 libraries in 5.1, they could adapt
them from a "reference library."

Nothing stops this from happening now. It's just more neatly done if
the make files / project were set up to compile the libraries
independently[1]

>
> Ay, there's the rub.  So far the tendency has been for the list to
> nominate with great enthusiasm the maintainers of stdlib, LuaDist
> etc, and for these to say thanks, but no thanks, for being asked to
> do what they are already doing, but now under Ruby-like community
> supervision.
>
> We're slowly moving into the direction where LuaRocks can provide
> much of the blessedness. It already provides convenient installation,
> detection of one's preferred Lua version and a large selection.
> All that it lacks is a blessing mechanism such as stackoverflow
> has. Surely that software must be open-source?

Typically when "blessed" comes up, it is in terms of "standard socket
library" and "class implementation." I'm suggesting that perhaps all
libraries that are not language features[2] would fall into this
category.


Specifically:
1: Organize libraries so that the make file could statically link
them, dynamically link them or not include them at all.
2: Document them as independent works, related to Lua and typically
release in tandem with Lua's releases, but independent.
3:They are Lua-esque, which is to say basic libraries to provide basic
facilities, written in C 89+.

With the addition of utf8, pressure to add LPeg (especially with utf8
present), and other pressures, there might be something to be said for
making this part of Lua more explicitly com posable.

-Andrew

[1]: I'm being overly vague by not specifying whether independent
compilation would be supported, an option or the default. It's not
critical to the concept, in any case.

[2]: Dealing with Lua converting base types, manipulating structures,
providing language features, such as coroutines, etc.