lua-users home
lua-l archive

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


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