lua-users home
lua-l archive

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

Jim Whitehead II wrote:
On Wed, Jun 10, 2009 at 9:15 AM, Olivier Hamel<> wrote:
Probably way pre-mature but I can resist asking, does anyone but Roberto
know anything of what will be the next version of Lua? I'm interested
because from what I've seen Lua has a (good?) peculiar tendency to radically
change it's 'feel'/design radically at each iteration.

The wiki page that someone started last year is probably the closest
we have right now:

Just interested in knowing what might be in the next version, partially
because I can't think of anything to add other than a few minor features
(different numerics support, built-in/standardized bitwise ops, integeral
divisions, most of these are available via patches but it'd be nice IMHO if
they were standard).

Apologies ahead of time if I'm ahead of things here...

Ah, I thank you for point this page out to me. I'll take this opportunity to dump my suggestions/wishes/hopes for Lua 5.2. Basically Lua 5.1 is very close to what I would consider the penultimate scripting language (please no Swiss Army Chainsaws!), so I propose we basically keep it as it is except for the following changes (more than willing to hear counter-points/arguments on this though):

Numerics Related:
* Lexer Only: Hex format definition (you know, 0x00000000, 0x0F001CE0, etc...)
* VM + Lexer (+ metatables?): Support for most/all bitwise ops
* VM + Lexer (+ metatables?): Integeral division

* VM: Coco patch integration?

* 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 * (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: local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9} local tbl = {ReturnSixIncrementalValuesFromZeroToSix() + 10, 7, 8, 9} -- this would equate to doing {11, 7, 8, 9} The alternate suggestion of using ';' to elaborate when to use multiple returns might be better (feedback on this please?)?

* 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? * 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) * VM: Add support for __finalize (do-able? or would it drive the collector insane?)

* C Std Lib: UTF-8 string support, (would require update of just the string library + math.char?) * 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?)

Virtual Machine:
* VM: Optional time-delayed bailout (setmaxexectime(<non negative number representing seconds for a state to return to c completely, otherwise it's killed/forced bailout>? Doesn't seem too critical, perhaps leave it to people to implement as power-patch?)

'Module' Function:
* Global Std Function: Change behaviour so it detects if the return value of require is not assigned to a variable and, and only then, create a global table with the module name. For people who say "if module Foo requires module Bar and people code expecting Bar after they require Foo, and then Foo is changed and no longer requires Bar then it'll causes errors." should consider the fact that they should be requiring both Foo and Bar explicitly if they are using both. Pardon me but this is just common sense and good practice. 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.

And that's all I can think of at the moment... I'll be sure to chip in anything else I can think of...