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
myself.

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 :-)
>
>