Re: what core things might be in Lua 5.2

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.

---

Nathan Youngman

Email: nj at nathany.com

Web: http://www.nathany.com