Re: Pallene

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

On Sun, 2018-09-16 at 15:28 +0100, Gavin Wraith wrote:
> May I congratulate the inspired genius(es?) who hit
> upon the name of Pallene (I have just been browsing
> http://www.lua.org/wshop18.html), which is well chosen
> from more than one perspective.

Haha, thanks for the kind words.

Titan got its name because it was the best moon name that wasn't
already taken. Pallene came after that. We went through the "Moons of
Saturn" article on Wikipedia and picked a second name that sounded
nice. :)

> One aspect of Lua, which may be unique to it, is that
> use of the __index metamethod permits one to dualize
> explicitly the space/time trade-off afforded by memoization;
> that is, table look-up can be performed by a fall-back function.
> I hope that Pallene will retain some of these aspects,
> even if the full generality of metatables has to be
> sacrificed to the type system.

I don't think having an ubiquitous falback mechanism that applies to
every table or array access is likely, even if the fallback is
restricted, as you suggested.

Although the fallback code might never be executed at run-time, its
mere presence can impede ahead-of-time compiler optimizations. For
example, the compiler might want to move an array bounds check from
inside a loop to before the loop starts, but it can only do so if it
can know for sure that the code inside the loop will never call any
functions that might resize the array.

In a language that is compiled ahead-of-time, the most idiomatic way to
do memoization is to have some kind of "get(xs, i)" function. In Lua
you might be reticent about this approach due to the extra function
calls but in a compiled language this is less of an issue. The compiler
may be able to inline the "get" function call, which would have the
effect of turning it into a table read plus a fallback call to
"compute", which is what you were originally looking. And even if the
compiler doesn't inline "get", this function call should be cheaper
than a Lua call anyway.

If keeping the nice "[]" syntax is important, adding an operator
overloading mechanism to the language would be the way to go but that
is a thorny discussion for another day...

> I hope also that Pallene will offer the same portability
> as Lua. My rather feeble efforts to port LuaJIT to RISC
> OS failed because RISC OS does not have the tools needed
> for its more complicated compilation.

The simplicity of the compiler has been one of the main motivations for
Pallene and Titan, and portability tends to come along for the ride in
when the compiler codebase is smaller.

At the moment we are compiling down to C and using GCC as a backend so
we should be portable to most things that can already run PUC-Lua. That
said, I could see us switching to an LLVM-based backend sometime in the
future. Do you know if that would be an problem for RISC OS (or other
similar achitectures)?

Best Regards,
Hugo Musso Gualandi