[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: any plan about luajit2 support 5.2!
- From: Mike Pall <mikelu-1011@...>
- Date: Wed, 17 Nov 2010 17:12:19 +0100
Alexander Gladysh wrote:
> If there would be luajit2-5.1 and luajit2-5.2 targets, there will be
> no breaking changes.
Well, Lua source code is almost unaffected by the 5.2 changes (*).
Having two different targets is mainly required to handle the
Lua/C ABI breakage between 5.1 and 5.2. But until there are tons
of C extension modules that only work with 5.2, there's little
need for that. I'm not seeing that anytime soon.
(*) I guess most users won't care or won't need to know about _ENV.
But those that do are unlikely to upgrade, as they'll have to
ditch their sandboxing frameworks and redesign them from scratch.
> 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)?
> 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.
--Mike