Re: [ANN] Ravi 1.0 Beta5 release

[Dibyendu Majumdar <mobile@...>]

On Tue, 5 Jan 2021 at 00:51, Italo Maia <italo.maia@gmail.com> wrote:
>

> I see it introduces some types. Most notably, to me, would be integer and number. Why not integer and float?

I guess that 'number' is more consistent with existing Lua terminology.

> Another question: if integer and number are initialized with 0, why not initialize arrays too? Or even dictionaries?

In Ravi you can create initialized number / integer arrays of a given
size using a library function.

> Ravi arrays seem to add a bit of complexity to the language, making it a bit harder to parse a lua program to ravi with all the optional optimizations. How much of a performance boost arrays add to an overall program compared to regular (ravi optimized) tables?

Lua tables simply cannot perform like native arrays. Ravi arrays are
like native arrays. Moreover these arrays do not need the garbage
collector to scan them.
Originally I added these arrays because I was looking at using Ravi in
a financial analytics app.

> Ravi seems to remove nil from the spotlight a bit, it seems, with exception to string, closure and user-defined types. This could also be a concern when migrating projects to ravi. Not sure if a big concern but for sure something to keep in mind. Would there be plans to go further, like changing the regular table's behavior regarding setting a key to nil and adding a new method to tables? Or even back down? What do you think is the purpose of nil in a fully ravi optimized program?

Nil values are actually not great for a JIT compiler as it introduces
the need for Nil checks everywhere.Lua team have decided to subclass
Nil so that is probably the way it will evolve. I have to assess the
impact of that before I can implement it in Ravi.

Here is the definition in Lua 5.4

/* Standard nil */
#define LUA_VNIL        makevariant(LUA_TNIL, 0)

/* Empty slot (which might be different from a slot containing nil) */
#define LUA_VEMPTY      makevariant(LUA_TNIL, 1)

/* Value returned for a key not found in a table (absent key) */
#define LUA_VABSTKEY    makevariant(LUA_TNIL, 2)


> Any chance fixed size array declaration would be in the queue for us humble folks? (aka: local array: integer[4] = {2, 3, 4, 5})

You can kind of do that via a library function except that the array
is initialized to a single default value.
In Ravi arrays can be fixed size. But not Lua tables, although I think
it is fairly easy to add a flag in the table to ensure it is a fixed
size array. It is just work that needs doing.
I think an easier way to do above in Ravi would be to create the array
and then call a library function to make it fixed size.

> Given arrays are a thing for ravi, how does immutability sound in your book? Quite an interesting feature with arrays. We can already do it using standard lua kung fu, but just checking how it sounds to the ears.

Arrays and tables can be easily made immutable to be honest - and I
thought about that as a way of optimizing a table. For instance after
populating a table, you could invoke a library function that makes the
table immutable and optimizes it for performance - avoiding hash
collisions for example. Again this is just work.

> How "local by default" variables sound to you?

Perhaps there could be a command line flag to enable that behaviour.
But it would probably create incompatibilities with existing code.

Thanks for the feedback!

Regards