Pallene

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Pallene

Gavin Wraith
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.

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 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.
--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Pallene

Hugo Musso Gualandi
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


Reply | Threaded
Open this post in threaded view
|

Re: Pallene

Gavin Wraith
In message <[hidden email]>
          Hugo Musso Gualandi <[hidden email]> wrote:

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

Pleasing though the concrete is, I expect that the Pallene development
would in any case be looking at the abstract syntax. Of course
"events", as the Lua manual describes them, may be detectable at
compile time, but to what exent they are handled at compile-time or
run-time is another matter altogether.

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

Alas, I fear it would. The latest GCC we have is version 4.7.4-rel3-1,
thanks to the efforts mostly of a single person. However, since the arrival
of the Raspberry Pi, and other ARM platforms, there has been a possibility
of RISC OS being ported natively to Linux, which would circumvent many of the
difficulties. I believe that this project is approaching fruition.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Pallene: C vs. LLVM backend

Oliver Schmidt-3
In reply to this post by Hugo Musso Gualandi
Hi,

I'm very happy to see ongoing work on static compiled & static typed languages (Pallene/Tian) that can be combined easily and elegant with Lua :-)

On 16.09.18 16:49, hgualandi at inf.puc-rio.br (Hugo Musso Gualandi) wrote:
> 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)?

I very much would appreciate if the C backend could be kept as first citizen backend. One of the great advantages of Lua is that you always know that it can run on nearly anything that has a C compiler. This is a very reliable and sound base that is worth to invest in, because there is nearly always a way to get Lua working (e.g. I use Lua daily on z/OS ;-). A dream would become reality if Lua could be accompanied by a static compiled and static typed language that has the same fundamental principles than Lua and one fundamental principle is that Lua just requires an environment with a C compiler. In fact these days there are only very few high level languages that directly translate to C, LLVM and JVM are the common targets. Also the LLVM C backend seems to be abandoned :-( So please keep on the good work on using the C backend and some day it could also be possible to use Pallene/Titan on z/OS ;-) (BTW: how are Pallene & Titan related, are these different approaches or different aims?)

Best regards,
Oliver
Reply | Threaded
Open this post in threaded view
|

Re: Pallene: C vs. LLVM backend

Hugo Musso Gualandi
> I very much would appreciate if the C backend could be kept as first
> citizen backend.

One of the downsides of C is that some language features like
coroutines and garbage collection don't map easily to it. That said,
we certainly want to stay as portable as possible and C is great for
that.

> BTW: how are Pallene & Titan related, are these different approaches
> or different aims?

Pallene originated as a fork of Titan. Currently, work on Pallene is
more focused on performance, while work on Titan is more focused on
expanding the set of supported language features. Both languages are
under development and it is too early to say much about their long term
future, but we are actively collaborating and sharing ideas between
them.

-- Hugo Musso Gualandi


Reply | Threaded
Open this post in threaded view
|

Re: Pallene

Rob Kendrick-2
In reply to this post by Hugo Musso Gualandi
On Sun, Sep 16, 2018 at 12:49:10PM -0300, Hugo Musso Gualandi wrote:
> 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)?

John Tytgat tried several years ago to port LLVM to RISC OS (he was part
of the team that maintains the GCC port), but I think this effort has
been abandoned.  One of the issues is RISC OS's rather unusual memory
management, leading to the use of "chunked stacks" that few compilers
seem to have good support for, and most of the delta for the GCC port is
to support just this.

(Stacks are implemented as a linked list of memory blocks, the function
pre- and post-ambles allocate and free the function's stack on the heap and
insert it into the list.)

B.