lua-users home
lua-l archive

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

I like what I have heard so far, in particular the implementation of a 
library like 'struct' (pack and unpack arbitrary binary data) in the core. 
(Don't forget to fix the buffer overflow I reported a few days ago :-)

I would like to reiterate my suggestion of introducing _three_ sorts of 
official Lua library, let's call them core, auxiliary and optional.

Core and auxiliary would be restricted to ANSI-C only, which isn't _quite_ 
the case at the moment. 

Optional libraries would contain officially-supported additional library 
code which might not be supported or portable to all platforms, and which 
IMO should start off with at least the following:

1. Dynamic library loading. (This is the current anomaly to the 'ANSI-C 
only' rule. With the introduction of 'optional' libraries, it gets a more 
logical home in the code tree.)

2. The C part of LuaSocket. (Leave out the Lua parts, so it's smaller, and 
can easily be compiled in if desired. UDP and TCP socket support is almost 
_sine qua non_ for a scripting language these days.)

3. An I/O library compatible with 'io' but using the OS's own low-level 
routines, not FILE *. (Inability to work with files > 2GB is a great 
annoyance when using Lua on Linux or Windows. Point it at such a file and 
it's lost -- seems a rather depressing singularity to me.)

4. A library like lfs. (But written to be properly and portably 
OS-agnostic, not as a Unix library of which large parts work on Windows, 
but some parts just return a 0 or nil placeholder answer.)

A few months ago I would have added...

5. Some sort of support for pre-emptive multiprogramming, probably a 
simple, message-passing solution such as LuaTask

...but I accept that's something which might not belong in an 
officially-supported library set.