Feature parity

[natecraddock]

How much should we cover up the differences between Lua versions?

lua_len isn't available in Lua 5.1. Should Lua.len() support this by calling rawLen or objlen?

Should LUA_COMPAT_MODULE be defined?

[robbielyman]

ah, I stepped in this too with lua_equal in #118. I think there's a valid case to be made either way... I think maybe it's correct to push the complexity introduced by inconsistencies between versions onto users—if they want to support compiling against different Lua versions, they should be aware that they're opening themselves up to real differences in behavior?

[bobcao3]

See issue luau-lang/luau#247 .

Luau's lua_ref takes an index as input, and creates a reference to the object at the index (and does not pop)

Other Lua implementations in this case calls into luaL_ref, which takes the registry / a table as input, and pops the top of stack & creating a reference to it. In our code we used this branch to ensure consistent behavior.

When implementation differs in pretty fundamental ways (e.g. Luau's ref() does not pop while luaL_ref() does), the documentation should at least express this. Currently the docs directly says the ref() function pops stack which is misleading.

( I do not think issue #170 should be closed, because it's not a bug with Luau, nor is it a exact duplicate to this issue. I could have made a PR directly to make them consistent but you should be the judge )

[robbielyman]

Thanks for adding a comment here! Sorry for the quick close, the framing of the issue as a bug didn't make sense to me without a resolution to this larger discussion. I'll definitely let @natecraddock chime in too, but for my part, i guess i'm not totally sure that ziglua is the right layer at which to homogenize differences between Lua versions?

Like, from my perspective, there are sort of two things that ziglua could be doing. one is to provide comfy Zig bindings to the Lua C API. at this layer of abstraction, ziglua is @cImport with the right amount of elbow-grease applied afterwards. And then the other is to go a step or two above and start being opinionated—harmonize differences or even provide Zig-only APIs for, e.g. minimizing the amount of C API calls you write by hand. I guess #170 is actually somewhere in between: it's "opinionated" in that it takes a genuine step away from the C API, but it is a pretty small step as compared with, e.g. ziggy pydust

Certainly I'm interested in a more opinionated approach too! Is that something we want to include in this repo?

[bobcao3]

I think it's fine (or preferred) to not homogenize here, those Lua versions diverged because they can't resolve the differences.. ( or no need to ).

I think one pretty clean approach to luaL_ref would be to only expose the ref function for non-luau backends, and disable this function on Luau and map it to a luau_ref so that people don't accidentally get tripped into a Lua stack bug?

[natecraddock]

See

• lua_53 is missing registerFns that's present in lua_51 and luau #42
• registerFns doesn't build when lang=lua54 #107

Right now I am leaning away from doing feature parity, but maybe it makes sense for some functions.