lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Dibyendu Majumdar <> wrote:

> Hi,
> I consider an implementation of Lua a 'fork' if it doesn't pass the
> Lua test suite. Otherwise it is another implementation of Lua, derived
> or independent.
> By this standard both Ravi and LuaJIT are forks.
> Generally speaking successful forks are bad for the eco-system, as
> they break it up. However, Lua's model of development being
> centralised doesn't support any other approach.
> Regards
> Dibyendu

Yes, there are a number of articles online about forking of open source
projects and why forks are bad. However, as you stated, in the case of Lua
there really isn't another choice as upstream does not accept patches into
the system directly, only ideas they may write their own code for.

I created my fork of Lua to learn, and eventually I would like to create a
variant of Lua that is more optimised for a game engine, with a goal towards
faster execution of code, a well-defined object model, better interaction
between C and Lua, etc... none of which I can fully do with vanilla Lua.

One significant patch I am working on extends the Lua instruction size from
32-bit to 64-bit (I posted about this a year or so ago), and adds a new
Index data type to hold class and/or instance variables for an object
instead of using Tables. This dramatically increases the speed at which
these variables can be accessed. I also have a full preprocessor along with
Constants, Enumerations, Macros and even Inline functions.

This patch is a mega patch as it also includes my Token Storage system along
with Type Locking and a few other things. Eventually I need to extract the 5
or so integrated patches into separate ones to post individually, which
means I will have patches that require other patches to be applied first at
that point. I will also be using the Index data type to revamp the entire
environment system, which will also facilitate namespaces, and remove the
ugly "local print=print" idiom.

I will make all of my patches available for vanilla Lua as is possible so
that we can all learn from each other in our hacking endeavours. At the end
of the day, even if I am the only one using my Lua variant, I will be happy
enough from the learning experience. However, there are other variants out
there that seem to have reached some level of success, so hopefully some day
my language will be one of them! :)

At some future point I would also like to create a JIT for my language
variant, so I am keeping a close eye on the progress you are making with
Ravi! I hope to use some of the lessons you've learned on your journey so
I don't have to make the same mistakes later on!

In some of my online reading I have noticed a few people also using the
terms "soft fork" and "hard fork" to mean what I proposed in an earlier
message. I think I will use these terms when describing Lua variants on my
website as I think it really will help disambiguate the two types of forks
that are produced by hacking Lua. I think adding the soft/hard qualifiers to
"form" to differentiate compatible/incompatible forks will be quite helpful
when discussing the various Lua derivatives that exist or are being created.

I don't think passing the test suite is necessarily a good litmus test
though because currently all my patches for Lua pass the test suite. Yet
most of my patches most assuredly create a hard fork of Lua in that they
change the semantics of the language itself (like my jump tables patch).