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

On Tue, Jul 8, 2014 at 8:37 AM, David Demelier <demelier.david@gmail.com> wrote:

Le 08/07/2014 01:57, Leo Razoumov a écrit :

On 6/20/14, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

I'm sorry to see some of the math functions go.

A preview of my mathx library for 5.3 is availabe at
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lmathx

Luiz,
lmathx is not part of the standard distribution and cannot be expected
to be present in all Lua installations.
I am still flabbergasted by the Lua's developers decision to remove
some of the C89 math functions
like cosh, sinh, tanh, etc. Is it in order to shrink the size of a
statically linked Lua executable?

--Leo--

Yes, I don't understand neither. Sometimes I'm thinking about switching to a different scripting language but actually I didn't find something that could replace Lua.

Regards,
David.

I don't wish to argue that anyone is wrong, but I will attempt to make the case that these decisions are reasonable (not that they really need defending):

Whenever something is added to the language, it creates a "horizon problem." This is where you are elevated to a new position; one in which you can see new issues that arise from the introduction of the feature. For example, you add a simple random function and now it's not good enough for many people and they want/need something better. If none was offered, they would go find the one they need and be done with it and the absence would only be a minor inconvenience. Its presence means that someone might *replace* the existing one and cause a problem for a loaded module, or live with the provided one and be dissatisfied.

It also comes up with things that are serviceable, but have limited boundaries: utf8 looks like this. It does most of what you need, but not everything. Its presence highlights its limitations and reasonable people will have opinions about the right boundaries, etc.

Then there are *language* features that create opportunities between modules and can also create issues. If ipairs doesn't work with hidden tables and you have a sequence-like-object that a user of yours may want to use in a for loop, you don't have good options. You can export it, but that's ugly. You can provide a `len` field, ugly again. You can patch ipairs, but that won't make you any friends with people... and so Lua 5.2 adds __ipairs.

I am committing the sin of repetition and I'm doing it from a position of relative ignorance (to many on this list): Math is a convenience library, aka application specific library. Loading the tools that you need at start up seems like a price to pay, and you can make an argument that it's reasonable, but only if there is a gain to doing so.

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?

Couldn't someone load a math library if they needed it?

These look like design decisions to me. They seem reasonable and overcome-able, even though each may slice it differently.

-Andrew