Re: Idea: Reference Libraries

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

On Tuesday, April 22, 2014, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-22 9:55 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
> >
> > Are you guys just messing with me now? :) This must be your subtle way of
> > saying, "knock off the proposals..."
> >
>
> My unsubtle reaction is: if some really dedicated guy maintains a small
> selected set (MUCH smaller than Penlight, LuaDist and stdlib) of Lua
> "batteries", to the extent that a version comes out for each new work,
> alpha and beta release (even it if just says that the previous one still
> works) so that can seamlessly continue to use them — then there is
> a chance that the public will find it so convenient that they will use it
> instead of rolling their own.
>
> But who is that really dedicated guy? Hands up everybody, not all
> at once please — DID YOU HEAR ME? — hands up ….

I think Steve is closest to what I'm attempting to communicate and I do understand that the "failure to communicate" is mine. 

The most inportant part: it's just the current and future standard Lua libraries. Nothing beyond that. The fight couldn't be about "what is standard." 

If there would be any fighting, it would be about what must remain as core Lua and what could be pulled out into a separate library bundle, (although this too might already be defined).

This separation would include what is now woven into the Lua Reference Guide. The separate "Reference Libraries" would have their own reference guide.[1]

As Steve points out, this is mostly optics. Lua's make file is very clearly laid out, although it's been a while since I've poked at it. But, optics are very important and can have a big impact, without making radical changes to what is already working quite nicely.

I do admit that there is a possibility that the impact could be negative, and it might be worth considering the risks. 

I guess the main reason that I mention it is that I feel it separates two things that might ought be separate:

1: Lua the language that includes core library functions that must be there, because they support the completely generic things done to Lua structures and value types, and therefore are likely to access Lua internals (ipairs/pairs, table.*, string.*(?), coroutine.*, etc).

From...

2: Lua the libraries that are critical, but not especially Lua related (os, math, io, ??). (Not sure where debug belongs. I think in the first grouping, along with Lua). 

Hopefully this didn't sound overly argumentative. It sounded to me as though I wasn't getting the right idea across and that I was bring heard to suggest another "Lua with batteries" variant. I don't think that this is that and I promise not to beat this topic to death.... more. :)

-Andrew

[1]: A non-essential feature would be to add guidelines for acceptable extension. For example, math.random does this now. It pretty much spells out that the flavor of random is not defined, so the library could be extended with a more robust random method and still be considered "Reference Compatible." 

Would it be possible to extend math.max/min to not fail on nil or to accept any value that supported the comparative metamethods? Currently, no. But, this is the sort of thing that could be discussed as a documentation change, without requiring the Reference Libraries to be altered. Maybe the answer would still be no. :)