RE: any plan about luajit2 support 5.2!

[<lua@...>]

I'd like to share my experience with Lua 5.2 (alpha) speed performance test.

I do not see any difference on speed between Lua 5.2 and LJ2. On other hand
I have significant difference between Lua 5.1 and Lua 5.2.

Yes, there are many scenarios when LJ2 gets better benchmarks, fortunately
due to nature of my application I'm more then happy to stick with Lua 5.2
and be more platform independent with same speed.

Cheers,
Anton


So, for me the checklist to be able to switch to 5.2 is as follows:

1. LJ2 supports 5.2. I will not even move before that.

2. All third party code modules I use support 5.2. This is less
critical. I'm willing to contribute and fix a few of them (if
condition #1 holds of course).

3. I upgraded all my Lua code (few hundreds KLOC) to support 5.2. This
looks scary, but doable.

It is hard to say, why should I upgrade to 5.2 though (given the
volume of the code). But, as Stroustrup often says, kill legacy code,
or your children will have to support it.

>> I'm really worried about LuaJIT 2 "5.1" straying further and further
>> away from the "language standard". I really don't want to see LuaJIT 2
>> as a Lua dialect. This will go bad for sure.

> You're mixing up two things. I have no intention to diverge from
> the 'Lua language' itself. But LuaJIT has always had extensions
> and extra features. E.g. the JIT compiler. ;-)

> And more extensions will come. I'm getting to the point where I
> can check in the first part of the FFI in the next days. This will
> pave the way for a slew of other features, e.g. 64 bit integers
> and native complex numbers. And when the FFI is complete, you can
> finally stop writing tedious C bindings (yay!).

> I hope you're not suggesting I shouldn't include this feature,
> just because standard Lua doesn't have it (and never will)?

(I do not want to discourage you from anything, I'm just thinking aloud.)

Once anybody will be able to say "this program requires LuaJIT to
run", we've got a dialect.

With __pairs, __gc and, especially, FFI we're getting very close to this.

Unless LJ2 FFI can be implemented for plain Lua (and it can not, as I
understand).

Furthermore, I'm (that is, me, personally, and my team) forced to live
in the LJ2 dialect ecosystem. We depend too much on the speed. :-)

This is not a bad thing -- it is good to live there. But somebody
(including Lua team) will live in the old, plain Lua ecosystem. (I
will have to live there too, for some projects -- take iPhone
programs, for example.)

So, I'm concerned that LJ2 "extensions" will split the community
effort (which is not so strong even without this). And I do depend
heavily on the community effort.

I do not know, perhaps I should go watch some TV and my concerns will
go away (c)...

All I ask from you is to think about the Lua future. LJ2 has serious
impact on it due to its awesomeness.

On to the other hand, we should not stop innovation. FFI looks really
cool. __pairs and __gc for tables are (probably) useful as well (but I
manage to live happily without them).

>> Please, keep 5.1 and 5.2 features separate.

> Incompatible features will certainly get a compile-time switch.
> But I'd first need to see a demonstrable need to litter the code
> with #ifdef's for simple upwards-compatible features.

I think that there should be another ways to do this besides #ifdefs.

About demonstrable need... See my concerns above.

I'm not saying that my opinion should have any weight here though. I'm
not a language evolution expert :-)

* * *

In a perfect world, I'd have three executables (and corresponding
options in the API):

luajit2-native (luajit dialect)
luajit2-5.1 (strict 5.1 compatibility [not including things like table
traverse order etc. of course])
luajit2-5.2 (strict 5.2 compatibility)

Alexander.