Re: Lua 5.1 (beta) now available

[Gavin Wraith <gavin@...>]

<20051111170408.GA9599@mike.de>
In-Reply-To: <20051111170408.GA9599@mike.de>
X-Organization: Home
User-Agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.10) POPstar/2.05
Reply-To: lua@bazar2.conectiva.com.br
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In message <20051111170408.GA9599@mike.de> you wrote:


> Luiz Henrique de Figueiredo wrote:
> > This is a pre-release. Unless major problems appear, it will
> > be frozen in a week or so (and the tarball renamed). Please take
> > a look and send us your comments or post them here.

> - Autodetecting system capabilities is a can of worms ...

Keep in mind weird minority systems like mine (RISC OS) for
which autoconfiguration cannot work anyway. With each release
I copy by hand all the #ifdef RISCOS statements that pepper my
previous sources.
 
>   Right now this is mixed up between the top-level Makefile
>   (one needs to select the proper target) and luaconf.h
>   (guesses some things, but not others). IMHO more consistency
>   would help here.
> 
>   Since it's impossible to cater for all system variants out
>   there in the field, I suggest to limit ourselves to the
>   following common cases:
> 
>   - Linux: 'make linux' defines LUA_USE_POSIX and LUA_DL_DLOPEN
>    ...................... [snip ] ...............
>   - Strict ANSI compliance: 'make ansi' defines LUA_ANSI.
>   - Generic: 'make generic' defines nothing.
>    ...................... [snip ] ...............
>   I can see the rationale for not allowing them to throw errors
>   due to the introduction of constant-expression evaluation
>   at compile time. Well, constfolding() in lcode.c already takes
>   care not to evaluate x/0 at compile time. But x%0 is still
>   evaluated before throwing the NaN out?

Because of deficiencies in the exception handling of our floating
point math libraries I used to insert as much trapping by hand
as I could. 
 
>   IMHO for replacing these macros with integer arithmetic
>   equivalents there needs to be a strict guideline. Either
>   they throw errors for the corner cases and constfolding()
>   carefully avoids these. Or they must return some integer
>   pseudo-NaN (probably the largest negative integer). I tend
>   to the latter.
>   [pseudo-NaN because it's not propagated like a proper NaN.]
> 
> - Quite a few people have attempted to change the type of lua_Number
>   and got it wrong. IMHO there is no point in everyone reinventing
>   the wheel.

I #define LUA_NUMBER as int, which is the same as long here, do
not use lmathlib, and introduce new opcodes for bitwise operations
& (and), | (or), ^^ (xor), ~ (not), << (lsh), >> (rsh). I also
put an integer rand() in the base library. Our ARM CPUs do not even have
coprocessors for floating point (all fp stuff emulated in software),
so using doubles as the default makes no sense for us.

I represent such a tiny minority system that it would be quite out of
order to ask for any sort of representation in the standard
distribution, but I do hope that Lua sticks to its guns on the
ambition to be portable to as many systems as possible.
Not everybody uses Unix based systems with all their software
development tools, not everybody has 86 series CPUs.

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/