[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Embedded Lua
- From: Lisa Parratt <lisa@...>
- Date: Fri, 31 Mar 2006 09:43:50 +0100
David Jones wrote:
On Mar 31, 2006, at 07:15, Lisa Parratt wrote:
On 30 Mar 2006, at 23:46, Luiz Henrique de Figueiredo wrote:
Also, the Lua core depends lightly on the ANSI C runtime library.
Besides some simple functions from string.h and ctype.h, it needs
sprintf and strtod to convert doubles to and from text, and setjmp,
longjmp and exit. Lua 5.1 also needs pow, floor, and localeconv.
The Lua libraries depend more heavily on the C standard library.
I don't see this as an advantage. The first thing I have to do with a
new Lua release is patch in an abstraction layer so that these may be
easily replaced. Personally I'd like to see every "standard" function
call given a prefix and a default header file of #defines that maps
them to their nonprefixed equivalents.
Why can't you just provide replacements for the C standard library
facilities that have the same names as the functions from the C standard
Because the functions are provided by the C library, they're just
buggy/incomplete/inadequate for purposes/incompatible with
configuration. In the real world, projects are written by multiple
people. I can't wholesale replace standard functions, despite their
flaws - other people may and probably will have written code that
depends on those flaws. Yes I could raise I bug on them, but when the
product's late already it makes it look like my problem, and therefore
as far as the company's concerned - *Lua*s problem.
"pow" is in fact an example of where Lua does it *right* - it doesn't
call "pow", it calls "luai_numpow". The platforms I regularly work on
have no floating point, and emulate it if you try and use math
functions. Lua is configured to use integers. I obviously don't want to
be calling "pow", so a quick modification to the configuration, and it
now calls "intPow". This uses integer partial products to perform the
exponentiation, and gives me far better performance.
I'm not saying Lua should be rendered difficult to integrate. It's just
it should be made fully independent, but provided with default bindings
that are useful in the most common case, exactly as is the case with