
Pallene: A statically typed companion language for Lua [pdf] - eggy
http://www.inf.puc-rio.br/~roberto/docs/pallene-sblp.pdf
======
catwell
A few details:

\- 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.

[1] [http://titan-lang.org](http://titan-lang.org)

[2]
[https://www.lua.org/wshop18.html#Ligneul](https://www.lua.org/wshop18.html#Ligneul)

~~~
etiene
The talk was great! I'm incredibly impressed with the benchmarks.

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](https://github.com/pallene-lang/pallene)

------
eslaught
For those of us who are only half paying attention, how does this compare to
Terra[1]?

Are you using something (e.g. LLVM) for code generation?

Can you generate binaries that are independent of the Lua runtime?

[1]: [http://terralang.org/](http://terralang.org/)

~~~
eggy
I had submitted this to HN because I was trying to evaluate using Terra
instead of Zig [1] as my C replacement language. I had already become familiar
with a particular dual-language environment called Extempore, [2] for
livecoding that has a scheme language, and a c-like, s-expression-based
language called xtlang that is compiled. You can mix the two in the same
programming session, and it really works for me. And then I came upon Pallene.

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/

~~~
hugomg
I talk a bit about this in a sibling comment. Maybe that helps answer your
question?

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.

~~~
eggy
Thank you for explaining it more to me.

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!

~~~
hugomg
If you were writing naive code, it probably wouldn't be _that_ much. Maybe a
2to 3 times difference. But the thing with Terra is that you can be even
faster than naively-written C if you know what you are doing.

~~~
eggy
I am trying to explore Terra more for this reason, but Pallene has piqued my
interest. My guess from the responses and what the authors of Pallene have
stated is that Terra is probably better to stick with for numerical work.

------
hugomg
I'm first author of the linked paper and am working on Pallene for my PhD.
Feel free to ask any questions here!

~~~
corysama
Would it be a mischaracterization to say that the generated C is basically the
source of the Lua interpreter + the statically compilable functions from the
Pallene program?

~~~
hugomg
From the point of view of Lua, Pallene works the same as C

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.

------
oscargrouch
If someone is curious as i was, here's a little bit more context:

Github Repo - [https://github.com/pallene-
lang/pallene](https://github.com/pallene-lang/pallene)

More about the language - [https://github.com/pallene-
lang/pallene/blob/master/doc/manu...](https://github.com/pallene-
lang/pallene/blob/master/doc/manual.md)

------
fithisux
I do not understand why Pallene is necessary if performance is the problem.
Just use LuaJIT.

I suspect something else is happening here and possibly it has to do with
autocompletion/intellisense.

~~~
hugomg
Pallene is indeed approaching this problem more for performance than for
autocompletion. (For just autocompletion it would be more appropriate to use a
typesystem that is closer to full Lua, like Typed Lua)

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.

~~~
mraleph
When you say "JIT compilers are notoriously tricky to implement" what, I
think, you actually mean is "optimizations for dynamically typed languages are
notoriously tricky to implement".

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.

~~~
hugomg
You hit the nail on the head. With a more "Oberon-like" language we can use
textbook optimization algorithms and take advantage of existing compiler
backends, like GCC and LLVM. For dynamic languages these techniques aren't
enough so more sophisticated JIT compilation seems to be the only option.

------
muthdra
Hey, bro. Lua was my first programming language. I started making PSP
homebrews before I learned it was actually made here in Brazil.

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)?

~~~
hugomg
Currently there is no special support for metaprogramming, but maybe we could
borrow some ideas from Terra in a future version...

~~~
muthdra
Please don't use an interpreter for metaprogramming evaluation.

------
eggy
I was so focused on the technical that in pronouncing Pallene as "Pauline" to
myself, I finally paused and made the connection LuaJit <\- Mike Pall, so
Pall...ene. Watch it's probably right in the PDF, and I just read over the
connection!

~~~
hugomg
Wow, I hadn't thought of that. Its a complete coincidence, actually!

~~~
eggy
Where does 'Pallene' come from then, Pallene XXXIII (33), a moon of Saturn?

~~~
hugomg
Yes.

------
Jyaif
I have only one question: is it 0-based?

