lua-users home
lua-l archive

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

Thank you Mr. Duck, for articulating my opinion better than I could

David Burgess

Duck wrote:
> Are these features? Not really -- just implementation and build-time
> tweaks to bring Lua into the 21st century..
> 1. A compile-time directive to select support for 64-bit (or at least
> 52-bit/53-bit) file offsets in the IO library.
> 2. Compile-time (or even run-time!) support for choosing 8-bit, 16-bit or
> 32-bit "chars" as the basis of strings.
> 3. Standardised compile-time selection of a floating point "number" type
> with more than 64 bits of integer precision.
> And as David B said, I think that Lua needs standardised, albeit optional,
> libs for sockets (the core C component of LuaSocket would be an ideal
> candidate here) and for some sort of pre-emptive multithreading
> (LuaThreads would be an ideal candidate here).
> Whichever libs are chosen for the above, they should be capable of being
> built as shared libraries, or built in, without source modification.
> The reason for focusing on sockets and threads are that these are fairly
> well-known and commonly-used mechanisms for IPC and for parallel
> multiprogramming, both of which are impossible with standard Lua
> components right now.
> This is not quite the same as having this sort of library available
> somewhere on the Wiki or the Forge. We're talking about official
> "auxiliary auxiliary" libraries, part of the standard Lua source distro
> for those who wish to use them.
> The stuff about nils in tables (fixable with Lua code), changes in
> repeat-until, and other such stuff, is small beer in comparison, though I
> do endorse:
> 4. Compile-time directive to require globals to be defined as globals
> (don't care whether there's a global keyword or not) before use, and not
> allowing them to burst into life due to a typo :-)