Re: table library changes (was Re: table.new in 5.3?)

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

On Thursday, November 28, 2013, John Hind  wrote:
> > Date: Thu, 28 Nov 2013 06:10:17 -0500
> > From: Sean Conner <sean@conman.org>
> > Subject: Re: table library changes (was Re: table.new in 5.3?)
>
> > So you're saying that the string library should be written in plain Lua
> > then, right?  Or are you trying to say that the C API lacks access to the
> > string manipulation you get from Lua?  I'm not sure I'm following your
> > argument here.
>
> It's a conditional argument: IF a substantial feature such as sort or regex justifies a C implementation THEN that implementation should be available through the API. IF it does not justify implementation in C, THEN do it in Lua. And BTW "do it in Lua" does not necessarily mean "leave it out of the standard libraries" - there is no reason why parts of the standard libraries should not be implemented in, and shipped as, Lua.
>
> For the math library, I definitely would not suggest re-implementing algorithms that are available in ANSI C. 'lua_arith' and 'lua_compare' are good templates here - have an API that does the operations on Lua numbers on the stack, then have a math library written in Lua that uses this API to implement the operations as individual Lua functions.
>
> - John
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com

The math library is the one that I end up wrapping/patching/extending the most. Much of that would not happen at all, if it were written in Lua, because Lua will use metamethods and the efficiency that you are gaining from the C implementation comes mostly from this loss in flexibility. 

It's a tradeoff and I imagine that it was taken into consideration when they decided to make it in C.