Re: What would you remove from Lua - a case of regression?

[Coda Highland <chighland@...>]

On Mon, Nov 26, 2018 at 4:41 PM Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
>
> On Mon, 26 Nov 2018 at 22:22, Coda Highland <chighland@gmail.com> wrote:
> >
> > On Mon, Nov 26, 2018 at 1:33 PM Dibyendu Majumdar
> > <mobile@majumdar.org.uk> wrote:
> > > I think it would be nice to have two VMs built-in - a full featured
> > > one and a cut-down one, with user being able to choose the one they
> > > want to use. But it is harder to switch between dual number type to a
> > > single number type.
> >
> > Have you considered doing the work at a different level? One common
> > bytecode format, one common VM, two parsers? Or possibly even a
> > source-to-source transpiler that compiles full-Lua down to mini-Lua?
> >
>
> Hi, that would not solve the problem as the problem I am trying to
> solve is to have simpler code to execute with less unpredictable
> branches. A common VM would have to handle the worst case. However
> what I could do is fall back to the full featured VM when a type check
> fails. This would cause a small performance hit for Lua code that
> relies upon the bigger feature set, but in theory this cost can be
> minimized by black listing the function so that next time it goes
> immediately to the fallback VM.

That's consistent with the polymorphic variation I was describing.

LuaJIT tries to be a little bit more forgiving about it. If it fails
the type check, it goes ahead and JITs it again with the new types. If
it fails AGAIN (I don't know exactly how many possible variations it
allows), it gives up and assumes it's a megamorphic function and just
always sends it through the slow-and-steady route.

Assuming your two VMs are still able to operate on the same in-memory
data structures so execution can freely switch between them, this
isn't an unreasonable idea at all.

/s/ Adam