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"
issue.
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
try-catch.
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
luathread.