Pallene: A statically typed companion language for Lua [pdf]
inf.puc-rio.br
inf.puc-rio.br
- Pallene is a friendly fork of Titan [1]. The reason for the fork is that the authors of Titan are iterating fast and adding many experimental features to it. The research group at PUC Rio needed a more stable code base and language definition. Improvements from Pallene will be merged back into Titan, which is probably what actual programmers should use in the long run (as of now neither is ready for production).
- There was a presentation of Pallene at Lua Workshop earlier this month. Slides and video should be available at [2] at some point.
Here is a quick link to Pallene's github repo as well, since it's a bit hidden in the paper: https://github.com/pallene-lang/pallene
Are you using something (e.g. LLVM) for code generation?
Can you generate binaries that are independent of the Lua runtime?
Terra is designed for high performance numerical computing. As you mentioned, it has no garbage collector, uses C-like datatypes and its executables are completely detached from the Lua runtime.
Pallene, on the other hand, is all about being able to seamlessly interoperate with Lua at run-time. It is possible to directly manipulate Lua tables and functions from a Pallene program. From the point of view of Lua, Pallene modules can be loaded as a C extension module would, except that Pallene is designed to integrate even better with Lua (sharing its garbage collector and having better C API performance).
As the other commenter pointed out, we are currently compiling down to C. However, it is possible that we could switch to LLVM IR in the future.
I like the idea of having a scripting language like Lua, but the clarity of a typed, compiled, non-GC language instead of C or the templates of C++. Terra ticks those boxes. The mix of Lua and Terra seems to be very flexible too from my early explorations. Is Pallene within an order of magnitude of the speed of Terra given no special tricks are needed to pull off a task. Are there any "bad" things Terra does that Pallene keeps within the better side of Lua. I guess I am asking if Pallene is a better fit for a dual-language system based on Lua than Terra other than maximum numerical computing performance. Thanks!
[1] ziglang.org
[2] https://extemporelang.github.io/Pallene uses garbage collection, and shares the Lua garbage collector. The idea is to make as easy as possible to call Pallene from Lua and Lua from Pallene. Meanwhile, Terra only uses Lua at compilation time for metaprogramming and template building. At runtime, if you want to call Lua from Terra (or vice versa) you need to use the C API, just like you would do with C.
I wouldn't really try to compare the performance of Pallene with Terra. They are two very different languages, doing different things.
If I were just interested in numeric computing (arrays as well), I am assuming without benchmarking Terra and Pallene that Terra would win by an order of magnitude, no? Thanks again!
The bigger issue is that as soon as you call from Terra back to Lua you've made a circular dependency, and so you can't then dump an object file and have it be entirely free of the Lua VM. This for me happens to be one of the big selling points of Terra, because I know that I can write as much code as I want and (usually) can still come out with clean object files to link into any old project on the other side.
I definitely get the appeal of a system which is intended to integrate with the same VM. If it weren't for some of the constraints of my current project, I'd definitely be thinking about it, so I'm glad that people are putting effort into exploring both approaches.
Roughly speaking, from the point of view of Lua, Pallene is a system language like C. It is good for performance and calling C system libraries, but isn't particularly suited for dynamic code loading and sandboxing via interpreter hooks.
If you want to produce a standalone executable, at the end of the day this executable will contain a copy of the Lua VM.
If you want to produce a library that can be "require"-ed from Lua, then you will produce a ".so" shared object file with just the Pallene functions in it.
Github Repo - https://github.com/pallene-lang/pallene
More about the language - https://github.com/pallene-lang/pallene/blob/master/doc/manu...
I suspect something else is happening here and possibly it has to do with autocompletion/intellisense.
For us, the main motivations for the Pallene approach are performance predictability and implementation complexity.
To get maximum performance with a JIT you need to write your code in a way that ensures that the control flow always stays inside the compiled parts of the code. If you are accidentally "too dynamic" then the JIT will fall back to the general bytecode interpreter, with an order of magnitude slowdown. The Pallene type system should ensure that if your code typechecks then it can be compiled to something reasonably efficient.
The type system also lets us use a simpler ahead-of-time compiler instead of a just-in-time one. JIT compilers are notoriously tricky to implement, which in turn means that it is more difficult to evolve them together with the language, or to port them to additional platforms.
In addition to that, people working on Titan say it could become an alternative to C for people who write applications in PUC Lua + C:
- It has an FFI so it can be used to implement bindings.
- It can also be used to extract performance-sensitive code from Lua into a compiled language.
- It should support newer Lua versions, being developed by people from PUC / close to PUC. Yay, 64 bit integers and bitwise operators!
If you don't mind, I'm curious about what applications you currently use Lua for.
Personally, I use Lua for a lot of other things including Web development.
If the language you need to compile is Lua - then it does matter whether you are trying to compile it just-in-time or ahead-of-time. Both would be hard to implement if you care about performance (and implementing an AOT compiler that produces fast code would probably be even harder than JIT).
Similarly if your language is like Pallene - which reminds me of Oberon-2 of all things, then you can implement both AOT and JIT with much less effort.
That does not however mean that AOT is trivial to write - as you increase the expressivity of the language and add more ways to write abstract code so does the complexity of optimizing away the cost of those abstractions (eliminating indirections and allocations, resolving polymorphic calls statically, etc)
Finally at some point, even a language like Pallene might benefit from a JIT - because of JITs' ability to see the execution and focus on actually taken execution paths, rather then looking at the program as whole and not knowing which paths would actually be taken.
How is compilation-time execution handled in Pallene? Does it have templating or maybe can it run its functions during compilation with a special token (so it doesn't need a metaprogramming language)?