lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thursday, November 28, 2013, John Hind wrote:
> Date: Thu, 28 Nov 2013 06:10:17 -0500
> From: Sean Conner <>
> Subject: Re: table library changes (was Re: 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.

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.