Re: Desired Lua Features

[Dibyendu Majumdar <mobile@...>]

On 29 January 2018 at 22:17, Paige DePol <lual@serfnet.org> wrote:
> Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>
>> On 29 January 2018 at 16:39, Paige DePol <lual@serfnet.org> wrote:
>>> Actually, adding an optional type system to Lua was considerably easier than
>>> I thought it would be. Just needed to add an extra field in the lua_TValue
>>> struct to hold the expected type, then check the current type against the
>>> expected type for any instructions that set R(A) and throw an error if they
>>> do not match. Of course, if there is no expected type then no check is done.
>>
>> Interesting. Lua can reuse the same stack slot for different variables
>> (of different types) and variables may be left unitlialized. How /
>> when  do you set the expected type? I could not see a way of doing
>> this - so I maintain the expected type in the function's Proto
>> structure.
>
> I created a new opcode, OP_TYPELOCK, which is used with a variety of
> parameters to cover a number of needs. I also added the ability to
> typelock new Index data types by adding a flag to OP_NEWINDEX.
>
> OP_TYPECAST was also created to allow for type casting at runtime,
> along with allowing for object isa checking at runtime when required.
>
> When stack slots are free'd I also unlock them. I realise that some of this
> extra code adds overhead, however, I am hoping that the use of my Index data
> type for my object model will negate those minor losses and give me much
> greater gains vs using tables. My initial tests looked quite promising, and
> soon I will be able to create much more significant benchmarks!
>
> I,initially contemplated storing types in the proto but found that to be too
> much of a limitation, especially once I added my object model which required
> additional information to be stored and checked.
>

Okay thank you for the explanation. In the case of Ravi, having
knowledge of types at compile time is useful for JIT code generation.
I assume above approach is more a runtime check? I assume also that
this approach works with up-values?

I found adding support for a statically checked structured type was
virtually impossible in Lua  because then you would need to have type
naming system - and handling recursive types add their own complexity.
Do you handle such types at run time or compile time? Based on an idea
by Roberto I decided to focus instead on making table access faster
(this is one of the tricks used in LuaJIT too I think - i.e. make
table access so fast that the cost is negligible).

Btw I would recommend putting your code up in github and doing
development in the open.

Regards
Dibyendu