3 ms·

Why would they have to fork the language instead of just being 5.1 compatible. There is nothing saying they have to be the most recent version compatible.

by sswezey 12y ago

eslaught 12y ago
Well, LuaJIT had already supported some of 5.2, just not all of it [1]. So I guess the issue is, how long can LuaJIT hold out on being 5.1 compatible while pulling in features from 5.2+ while not fragmenting the language? My (admittedly limited) understanding is that 5.2 was already not fully backwards compatible with 5.1, so if that trend continues, I just have a hard time seeing LuaJIT stay 5.1 compatible without effectively forking the language (even if they don't call it out as such). [1]: Here is one reference though it's not necessarily the best: http://lua-users.org/lists/lua-l/2012-01/msg00796.html http://lua-users.org/lists/lua-l/2012-01/msg00796.html
spc476 12y ago
The major difference between Lua 5.1 and Lua 5.2 is the environment a function operates in and this effects globals and modules in a rather big way. You can change the "global environment" a Lua function operates in quite easily in both Lua 5.1 and 5.2, but the underlying implementation is different between the two, and Mike Pall, the writer of LuaJIT, does not care for the new way globals are handled. There might also be issues with supporting Lua 5.3's integer type [1] in LuaJIT (now you use the C FFI to handle 64-bit integers). At this point, it seems there are two distinct versions of Lua, Lua and LuaJIT. I have some modules I wrote that support both Lua 5.1 and Lua 5.2, so I can still use them with LuaJIT if need be, but it's a pain (conditional code in both C and Lua) and it will only get worse if Lua 5.3 comes out [3]. [1] Up to Lua 5.2, Lua only supported one type of number (internally, a double [2]). Lua 5.3 now supports a distinct integer type, which has its implications (doubles don't wrap; you now get x.0 where before you would get x when printed, etc). The reason for 64-bit integer support is that doubles only support integer operations up to 2^53 or so. [3] [2] Unless you changed the internal representation of numbers in Lua, an easy change to make in the Lua sources. [3] I already had to work around 64-bit integers in some code dealing with process limits on a 64-bit system and Lua 5.1/5.2.

Why would they have to fork the language instead of just being 5.1 compatible. There is nothing saying they have to be the most recent version compatible.

by sswezey 12y ago

Why would they have to fork the language instead of just being 5.1 compatible. There is nothing saying they have to be the most recent version compatible.

eslaught 12y ago

Well, LuaJIT had already supported some of 5.2, just not all of it [1]. So I guess the issue is, how long can LuaJIT hold out on being 5.1 compatible while pulling in features from 5.2+ while not fragmenting the language? My (admittedly limited) understanding is that 5.2 was already not fully backwards compatible with 5.1, so if that trend continues, I just have a hard time seeing LuaJIT stay 5.1 compatible without effectively forking the language (even if they don't call it out as such). [1]: Here is one reference though it's not necessarily the best: http://lua-users.org/lists/lua-l/2012-01/msg00796.html http://lua-users.org/lists/lua-l/2012-01/msg00796.html

spc476 12y ago

The major difference between Lua 5.1 and Lua 5.2 is the environment a function operates in and this effects globals and modules in a rather big way. You can change the "global environment" a Lua function operates in quite easily in both Lua 5.1 and 5.2, but the underlying implementation is different between the two, and Mike Pall, the writer of LuaJIT, does not care for the new way globals are handled. There might also be issues with supporting Lua 5.3's integer type [1] in LuaJIT (now you use the C FFI to handle 64-bit integers). At this point, it seems there are two distinct versions of Lua, Lua and LuaJIT. I have some modules I wrote that support both Lua 5.1 and Lua 5.2, so I can still use them with LuaJIT if need be, but it's a pain (conditional code in both C and Lua) and it will only get worse if Lua 5.3 comes out [3]. [1] Up to Lua 5.2, Lua only supported one type of number (internally, a double [2]). Lua 5.3 now supports a distinct integer type, which has its implications (doubles don't wrap; you now get x.0 where before you would get x when printed, etc). The reason for 64-bit integer support is that doubles only support integer operations up to 2^53 or so. [3] [2] Unless you changed the internal representation of numbers in Lua, an easy change to make in the Lua sources. [3] I already had to work around 64-bit integers in some code dealing with process limits on a 64-bit system and Lua 5.1/5.2.