Re: Next Version of Lua?

[steve donovan <steve.j.donovan@...>]

On Wed, Jun 10, 2009 at 12:02 PM, Olivier Hamel<evilpineapple@cox.net> wrote:
> Basically Lua 5.1 is very
> close to what I would consider the penultimate scripting language (please no
> Swiss Army Chainsaws!)

Amen! The world already has enough of those!

> * Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0,

It does this already, last time I checked (-3 secs ago) Are you
thinking of hex string literals?

> * VM + Lexer (+ metatables?): Support for most/all bitwise ops

As operators? I think most of us would live with a set of 'blessed'
functions to do this.

> Syntax:
> * Lexer Only: A continue statement is in dire need, I've found myself often
> wrapping large segments (read: rest of loop code) in a big if-then-end block
> because I couldn't do if-then-continue-end

Yeah, that's a good one. This crops up fairly frequently.

> * (VM?) + Lexer: Have an explicitly defined handling of cases like {[3] = 3,
> 1, 2, 3} and do not adjust the return codes to one unless an operation is
> directly performed on it. Example:

The thing, we're used to the rule that multiple args only get expanded
at the end of a table ctor. Maybe an explicit 'explode' function, but
keeping the default behaviour? Changes like this can break lots of
code.

> Metamethods:
> * VM: Add support for __ne, __gt, and __ge (not equal, greater than, greater
> than or equal to); Would this impact performance in any significant way?

That's the big question, seeing as it is such a basic operation. Time
for experiments, anyone?

> * VM: Add support for __overrideindex (as the meta-method's name suggest,
> override a key in the table which already contains a non-nil value with a
> new value, nil or otherwise)

OK, so like __setindex if the key is nil, but works even otherwise.
You can then override '=' for keys basically.  But there are tricks
you can use already to get this effect, e.g. the key is actually
called '_a' but use __setindex so that 'A.a = 2' updates _a, etc.

> * VM: Add support for __finalize (do-able? or would it drive the collector
> insane?)

I like RAII so this would really be good.

> * C Std Lib: More powerful support for format/additional functions like
> string split/explode (Only if there is enough interest? Is anyone interested
> in that anyways?)

They're very useful, but pure Lua implementations are usually fast enough.

> Additionally people should be choosing good module names and NOT polluting
> the global env unnecessarily anyways, so saying that a collision might occur
> is stretching it a bit (read: a lot) far  IMHO.

This is a wisdom problem, not a Lua problem ;)

steve d.