Re: Roadmap for Ravi - 2017

[Dibyendu Majumdar <mobile@...>]

Hi Sean,

On 14 January 2017 at 06:19, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Dibyendu Majumdar once stated:
>> 1. I would like to add support for inlining of Lua functions.
>
>   I assume this would be based upon function size?  Or an indication (ala C)
> that a function can (or should) be inlined?

Don't know yet. I originally thought that I would need to have a new
parser/code generator for this as I wanted to manipulate ASTs rather
than work at the level of bytecodes. But the recent post by Kawahara
Satoru indicates that it may be possible to do inlining at bytecode
level.

>
>> 2. A related goal is to allow a faster calling convention for C
>> functions that do not require the Lua state, e.g. std C functions.
>
>   The major issue I have with LuaJIT's ffi is that you can't feed it C
> header files.  I mean, if they're relatively clean (sans #defines and #if
> stuff) you could probably get away with it, but otherwise, you have to
> declare all structures and prototypes.  Ideally, you do something like:
>
>         ffi.define { MAXSEG_64K = 1 } -- we need this defined for this example
>         ffi.include("zlib.h")
>
> and now you can use zlib. But I do admit that such an interface is a *major*
> undertaking and I can understand why no one has done it yet.

I am not planning to add LuaJIT style FFI to Ravi. There is no safe
way to provide FFI - if you observe the LuaJIT mailing list then you
know that most problems reported by LuaJIT users stem from incorrect
use of FFI. Ravi is meant to be used by 'non professional programmers'
in a business application; I cannot afford to introduce unsafe
constructs that will destabilize the system.

I am thinking of a much simpler and limited approach that will only
work for simple C functions that take 1 or 2 primitive arguments, such
as C maths functions. The idea is that there will be an enhanced C API
for registering such functions so you can only register them in C
code, not declare them in Lua. Say the enhanced API allowed you to
register a C function and specify that this was a function that took 1
double argument and returned a double - then the VM can use this
information to directly call the function rather than going through
the expensive Lua function call mechanism. There will not be any user
visible change in Lua apart from better performance.

My primary aim is to allow fast access to mathematical functions such
as exp() or log().

>
>> 4. More type annotations - such as string, closure and more
>> interestingly - a userdata annotation where you can use the __name
>> attribute of the metatable to say what type is expected.
>
>   I would avoid trying to overload the __name attribute.  This is Ravi, not
> Lua, so perhaps come up with your own metamethod [1].
>

It is not overloading, more making use of this feature. For example,
say you have userdata with __name set to 'Foo'. Then the idea is you
could declare:

function bar ( a : Foo )
local b: Foo = a
end

The compiler can introduce type assertions. This has no performance
benefit but it can help make code more robust. The compiler could also
determine that any operations on these require metamethod calls.


>> 5. Backward compatibility with 5.1 and 5.2 as far as possible - this
>> is mainly so that Ravi can be used to run projects that have no plans
>> to upgrade to 5.3.
>
>   I think the hardest "feature" to support is setfenv()/getfenv() from Lua
> 5.1 to _ENV in 5.2 and above ...
>

True. I found some information going back to 2010, 2011 that discusses
how to implement this feature. Hopefully I can get it working. I think
that supporting everything in 5.1 may not be possible but I strongly
feel that there is a need to help projects to move to 5.3 easily, and
they can do so if there was a 5.3 implementation they could use
without having to rework all their code.

Thanks for the feedback.

Regards
Dibyendu