Re: Next Version of Lua?

[Olivier Hamel <evilpineapple@...>]

Jim Whitehead II wrote:
> On Wed, Jun 10, 2009 at 9:15 AM, Olivier Hamel<evilpineapple@cox.net> 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: http://lua-users.org/wiki/LuaFiveTwo
>
>   
> > 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

Coroutines:
* VM: Coco patch integration?

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
* (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?)?

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?
* 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?)

Strings:
* 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...