[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua is too big
- From: "Thiago L." <fakedme@...>
- Date: Wed, 11 Jun 2014 13:30:04 -0300
On 11/06/2014 13:27, Coda Highland wrote:
The breaking changes are mostly a joke, (to show what you can do without
+ and/or *) the compatible changes on the other hand...
On Wed, Jun 11, 2014 at 8:59 AM, Thiago L. <firstname.lastname@example.org> wrote:
The Lua VM is too big. I have an idea of how to make it smaller, with 2
breaking changes and 2 backwards-compatible changes:
1. Remove OP_ADD (use `-(-x-y)` instead) [breaks/removes `__add` metamethod]
2. Remove OP_MUL (use `x/(1/y)` instead) [breaks/removes `__mul` metamethod]
1. Turn for loops into syntax sugar, remove OP_FORPRER and OP_FORLOOP (which
can be used to break out of sandboxes), OP_TFORLOOP (the opcode for `for ...
in ...`) 
2. Remove OP_SELF (this might make it a bit slower but `table:whatever()`
can be done without OP_SELF by using OP_MOVE)
 Would also make it possible to use numeric for loops (aka `for x=a,b,c`)
with non-numbers (as long as they override __add, __eq, etc)
I... legitimately can't tell if this is satire or not.
On the assumption that it's serious:
Your breaking changes break more than existing code. They break
numerical stability. x/(1/y) in particular is egregious, as it's very
likely to introduce floating-point error. They're also not exactly
great for performance; division is slower than multiplication and
you're replacing one with two, and replacing one addition with three
subtractions/negations isn't thrilling either.
However, I have to wonder why you think the VM is too big. Lua's VM is
one of the smallest useful VMs out there. (I'm not going to count e.g.
the bazillion BF interpreters that can be golfed into
near-nothingness.) Do you have a use case where Lua is actually too
big, but something else is both sufficient and small enough?
Finally, this is the kind of idea that is best served by creating a
fork -- make a micro-Lua variant that drops features and emphasizes
size over performance if this is something that's actually important
to you. Pitching this stuff as if you're suggesting changes to the
core VM is just going to invite a flame war. (I'm moderately certain
you're NOT proposing that, but nothing in your e-mail indicates such.)