lua-users home
lua-l archive

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

Sounds good, esp #4 would be cleaner. A little concerned that #2 & #3 could make sharing code a bit more complex.

Some sort of optional threading library for multi-core support would be quite nice I'd say. One of my crazy ideas is to work with SQLite (public domain) and Lua, and SQLite already has quite a bit of OS-specific stuff, like threading and file lock handling. If those routines could be common between the two, it would be quite interesting in keeping a nice light embeddable platform. Not to say SQLite would require Lua or Lua would require SQLite. Since I don't actually know much about the internals, any thoughts? Perhaps to grande of an idea to actually become part of the core of two different tools...

What about binary serialization and/or saving a table as Lua code as other optional libraries?

- nathan.

On 7-Nov-07, at 7:00 AM, Duck wrote:

Re: Switch/Case statements revisited

Which re-re-re-re-revists the "what core things might be in Lua 5.2" 

I can't resist it:

1. Tables with a special __mode which says to allow nils inside.

2. Tables with a special __mode which says that the array part, if any 
(contiguous N integer indices), is based at zero not one.

3. Run-time setting to instantiate variables at the innermost lexical 
scope ("local") by default, not at global scope.

4. Syntactially clean replacement for pcall()/error(), e.g. try-except or 

Oh, and add:

5. Extend "core and auxiliary" libraries to "core, auxiliary and 
optional." Core and aux to be ANSI-C _only_ (move shared library loading 
to optional). Include a range of popular (if not 100% portable) but 
PUC-endorsed libs in "optional." Start with luasocket and consider 


Nathan Youngman 

Email: nj at