Re: [ANN] Lua 5.3.0 (work3) now available

Subject: Re: [ANN] Lua 5.3.0 (work3) now available
From: Andrew Starks &lt;andrew.starks@ ... &gt;
Date: Tue, 8 Jul 2014 20:14:36 -0500

On Jul 8, 2014, at 7:31 AM, Andrew Starks <andrew.starks@trms.com> wrote:

So, what is the gain? If perhaps 500 bytes of memory could be saved, would that be worth it? Almost certainly, no.What about the testing burden, in a C library (Lua) that prides itself on being relatively consistent on a crazy number of platforms? Would 500 bytes matter, if you're running 1000 or 20,000 Lua states? Perhaps these people remove the functions that they don't want and load a trimmed down Lua?

It would not even be 500 bytes *per state*, since each state only has the overhead of the entries in its global environment (the code is shared).

I’m not sure I saw any good arguments for removal; the testing one is probably the closest but the very nature of these functions makes them very easy to test automatically, and presumably these tests were already in place. The only official argument I saw was that since C99 has lots of new functions, and they were not going to be supported, the hyperbolics should also be removed, which didn’t seem very logical to me.

We have a lot of numeric algorithms in our products, but none of them use hyperbolics and so in and of itself this change has little impact for us. However, I’m a little worried about the precedent set here. What will get axed in Lua 5.4?

I also don’t buy the “just load a math library” argument, which I find naive. It assumes the script author, script user, and Lua installation are all managed by the same person or team. If you really want to write a nice, self-contained, portable Lua script that can be re-used across platforms it’s problematic to rely on 3rd party libraries, particularly given the poor state of management of those libraries by Lua (which, imho, is the single weakest part of Lua atm).

—Tim