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

[Tim Hill <drtimhill@...>]

> 
> 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.
> 

I think there are two distinct discussions in this thread (and it’s spawned threads)…

1. What functionality should the table library provide?
2. How should that be implemented?

In general, computational expensive code is better in C (anyone want to write a video codec in Lua?), while “business logic” decision making code is better in Lua. A small number of APIs fall in the middle, or are hybrids where some logic is better in Lua, but the “heavy lifting” part of the algorithm is best in C. I don’t think it’s an either/or argument in quite the way you portray .. after all, even if you DID write table.sort in Lua, you would still need rawget/set (written in C) to be available to your Lua sort code.

—Tim