[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Desired Lua Features
- From: Paige DePol <lual@...>
- Date: Mon, 29 Jan 2018 16:17:24 -0600
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.
~Paige