Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)

[Jay Carlson <nop@...>]

On Feb 13, 2012, at 9:21 AM, KHMan wrote:

> On 2/13/2012 9:07 PM, Alex Queiroz wrote:
>> On Mon, Feb 13, 2012 at 2:00 PM, Jon Akhtar wrote:
>>> Perhaps if we could get an endorsement on the result from upstream,
>>> and either inclusion in the release (as an external source based
>>> library), or at least a link off of the main page. Otherwise - it is
>>> sort of pointless to bless one library vs another.
>> 
>> I should start counting how many times this common library discussions
>> come full circle and end up nowhere. Maybe this is the 500th one. I'll
>> just put a counter on "bless" and "blessed".
>> 
>> I really have no idea what's with people and blessing.
> 
> Yeah, but I suppose we should trundle out some old arguments for the benefit of the new folks... :-) :-) :-)
> 
> What a Lua+everything thingy needs is stable leadership, management and manpower.

We're far better off than in the past. luarocks can handle the "everything" part and let people pick and choose; nobody has to decide if lposix is in or out. Going to the store[0], gonna buy some batteries. What's left that's cross-cutting?

I want to cut features ruthlessly until we mostly agree we all use something from time to time, and it looks and acts mostly the same--or there's an obvious winner for correctness/efficiency/simplicity. NO. NEW. FEATURES. If it's not present in luarocks at least three times in mostly compatible form it's not mature enough. If I look through the WoW base libraries I should see it over and over again. Pave the cowpaths.

I'm looking at you, object systems. Lua already has a basic object system and it's not in liblualib, it's in *core*: setting __index to a table. That solves, what, ~70% of problems?

It's nice to have a deep pretty printer (or serializer) around, but I will settle for function table.print(t) for k,v in pairs(t) do print(k,v) end. I think it would be cool to have table.copy(t) actually be the merge [[ function table.copymerge(t,override) local nt = {} for k,v in ipairs(t) do nt[k] = (override and override[k]) or t[k] end return nt end ]] but I'll drop it like a hot rock if nobody else writes that.[1]

The object system code I most want is a "proxy everything" empty table, where all __index and __newindex get handed off to another hidden table. I don't know how much more complicated I want to get, because no new features means NO. NEW. DESIGNS. too. On the positive side, memoize and its weak-table friend probably go here.[2]

It's lots of fun to build new scaffolding in Lua, and people should keep doing that. You can't stop me anyway. Penlight (for example) should continue to be the place where Steve puts all his common code (and other people grab it), and maybe eventually more of it becomes something people commonly use so often it would save time to just put it one place.

It's possible I'm overestimating the amount of commonality we have...well, at least it makes the maintenance easier. Or tells us something interesting about the language.

If luarocks really wants to help, add an implicit dependency on a base package to everything; every rock then can count on that basic library being around. Jam it into LUA_INIT. I dunno. Ideally I want something to be no-require, just like the rest of _G. That's a significant threshold for likelihood of use, and constrains what goes in (must not change existing code behavior, for starters). If there's some question about whether it should be in a full-fledged module, maybe it should go there instead.

Jay

[0]: normal guy normal walk. http://www.youtube.com/watch?v=iRZ2Sh5-XuM

[1] yes yes, hoist the override == nil check out of the loop body if we're going to do it once the right way. and because of how multiple-returns work and how table.copy is often used for safety, copy = copymerge would be bad for the typical case of copy(f(...)) anyway.

[2]: We are hopefully past the worst of this, but there used to be complex dances needed to use some features like weak tables correctly, and that'd be my biggest concession to exceptions to "must be in ubiquitous": when YOU'RE DOING IT WRONG. os.execute on an array of args maybe.