Re: Lua vs Python C bindings

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

> Cool.
> Pallene does look a similar initiative, but creates a different
> statically typed language from Lua, right?

Pallene is still Lua, in the sense that it is a typed subset of it.
If you remove all the type annotations from a Pallene program it
should be executable as a Lua program.

We chose to give it a different name because, while it is easy to
convert Pallene code to Lua, the converse is not true. You should not
expect to be able to easily translate any idiomatic Lua program to
Pallene just by adding type annotations, as the Pallene type system is
too rigid for that. This was a conscious design decision because we
wanted programmers to be able to feel that if they write their code in
Pallene they should be able to expect that the compiler will generate
clean and efficient code for it. This is not possible if the type
system is designed for idiomatic Lua.

> I liked that Cython is a superset of Python.

It boils down to the level of granularity for mixing the static and
dynamic sublanguages. Ravi and Cython choose to have an expression-
level granularity, while in Pallene it is module-level.

While we don't have any plans to allow mixing Lua and Pallene fragments
inside a single source file, I don't think this is a fundamental design
decision that tells the two approaches apart. It is the sort of thing
that could conceivably change in the future.

> Another cool feature is
> that it can wrap C++ code as well.

The Lua-C API has to be the way it is because the PUC-Lua interpreter
uses only portable standards-compliant C-code. It can only call C
functions if they all have the same type signature: receiving a
lua_State pointer as a parameter, and returning an int.

This is not a problem if you have a compiled language, or are willing
to use a slow and non-portable implementation for calling C functions
inside the interpreter.

The LuaJIT FFI interface is an example of this. Inside JIT compiled
traces it simply inserts a call to the C function inside the generated
machine instructions. It is as fast as such a call can get. However,
outside compiled traces the interpreter must implement FFI calls with
clever non-portable assembly code that knows how to call an arbitrary C
function with potentially any number and type of parameters. This is
slower than when the C calls are compiled to machine code, which is the
case of the traditional Lua-C API and of LuaJIT's FFI inside compiled
traces. This means that if you are using the LuaJIT FFI you really want
to be sure that the code surrounding your FFI calls is free of "not yet
implemented" language features.

A fully-compiled language like Cython, Pallene, or Titan doesn't have
to worry about interpreting the C calls, which interpreters like
PUC-Lua, LuaJIT or Ravi have to. Titan already has some experimental
support for external C calls through a LuaJIT-like interface. Pallene
doesn't have this yet but it is on our long term plans.

-- Hugo