[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: More thoughts on Lua 5.2
- From: Duck <duck@...>
- Date: Fri, 22 Feb 2008 07:44:11 +1100 (EST)
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.