Re: Coroutine support in 4.1 / IPC mechanisms

[Tore Lund <tl001@...>]

Luiz Henrique de Figueiredo wrote:
> 
> Here is a quick preview of what is probably coming out with 4.1 (no promises):
> 
> - suport for multithreads and coroutines
> - suport for wchar (preparing for unicode)
> - weak tables
> - more general syntax for function definition and expressions:
>   function a.b.c.d.e.f (...) end
>   (a)=3; (print or write)(9)
> - names for user created types
> - secure binary dostring/dofile
> - new functions (time/date, tmpfile, unwrap, require)
> - positon capture in string matching
> - better handling of userdata/tags
> - faster VM (!)

What about the size of all this?  One reason why I am looking into Lua
is that it fits comfortably into a 16-bit SMALL memory model (64 KB code
+ 64 KB data).  I hope (core) Lua will not outgrow this model.

Judging from the archives it appears that Lua developers have put a good
deal of work into making a hassle-free 16-bit Lua.  (And it works great,
thank you.)  Then why not make it official by using something like
#ifdef USE16BIT her and there?  I believe it is only needed in 2 places,
but there might be others.  Having an "official" macro like USE16BIT
would be a good way to sort out such issues.

The same goes for the integer variety of Lua.  According to LTN002,

  This note has focused on reducing the amount of code added to the 
  application by the Lua library. Applications that need this
  will probably also prefer to use integers instead of floating-point
  numbers for the numbers in Lua. (Does a microwave oven need 
  floating-point?) This should be simple to do, as described in 
  lua/config, but the details will probably be discussed in another LTN.

This amounts to a semi-official blessing of an integer version.  I would
like to see it completely official with #ifdef USEINTEGER directives
where needed.  As it is, type double is used in many places where
LUA_NUM_TYPE could have been used instead, and some details concerning
strtol/strtod need to be fixed by hand.

Instead of several private libraries for integer operations there could
be a single lintlib.c.  And it would be reasonable to let the lexer of
the integer version understand hexadecimal and maybe binary numbers (not
sure who really needs octal nowadays).  I think this would make Lua more
attractive to many programmers who are oriented toward embedded or
systems programming.

Also, having 32-bit integers instead of 64-bit doubles is a great help
toward shrinking memory requirements.

After all, this is just a matter of officially blessing what is already
a *de facto* integer version of Lua.  I am not talking about adding
integer as an extra type.
-- 
    Tore