Re: Pallene

[Gavin Wraith <gavin@...>]

In message <8e5d4f67e9b5103616396aa5a4a2286e10263a9a.camel@inf.puc-rio.br>
          Hugo Musso Gualandi <hgualandi@inf.puc-rio.br> 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 (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/