Re: Lua vs Python C bindings

[Hugo Musso Gualandi <hgualandi@...>]

> I think that the issue is not whether it is compiled or not. Lua
> functions are values, so you don't know that they are actually
> functions or not, what arguments they take, and what the return type
> is. Thus, you don't know that the function being called is a C
> function, until you see the value. You cannot assume that the next
> time you see the value it will be the same function.

These things make it harder to optimize the code around the C function
call but do not affect how hard it is for the interpreter to actually
invoke the C function.

> In a language
> where a function has a static identity it would be possible to create
> specialized bytecodes that efficiently invoke the C function.

The problem is that it is impossible to implement these bytecodes if
your interpreter is written in standards-compliant C. The C language
doesn't have a way to apply an arbitrary function (which can be of any
type) to a dynamically constructed list of arguments (which can be of
any length). You would need to create an infinite set of bytecodes, one
for each possible C function type.

This is why projects like libffi[1] exist, and why LuaJIT must use non-
portable assembly to implement this part of the FFI in its interpreter.

[1] https://sourceware.org/libffi/

 -- Hugo