lua-users home
lua-l archive

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

On Tue, Jan 12, 2016 at 11:40 AM, Jonathan Goble <> wrote:
> On Tue, Jan 12, 2016 at 3:25 AM, Nagaev Boris <> wrote:
>> On Tue, Jan 12, 2016 at 11:13 AM, Jonathan Goble <> wrote:
>>> The catch here is that in order to create a module containing my new
>>> functions (find, gmatch, and gsub in addition to match), I (assume)
>>> would have to copy-and-paste all of the pattern matching code, roughly
>>> 500 lines of code, into my new module, just to change about 10 to 15
>>> lines. That does not seem like a reasonable plan of attack.
>>> The only reasonable way to do this, unless I'm missing something, is
>>> for the change to be made in stock Lua, which is not asking that much
>>> (given the simplicity of implementation and the lack of any backwards
>>> compatibility issues).
>>> The only alternative I can see is for me to maintain a lightly
>>> modified fork of Lua on GitHub that makes my changes available,
>>> possibly by defining a symbol like LUA_CUSTOM_BALANCE. I'm considering
>>> doing this anyway, but at this stage, I'd really rather not be
>>> maintaining a fork.
>> Maintaining a rock is simpler than maintaining a fork. And it worth to
>> make a rock even if it was added to stock Lua, because a rock can be
>> installed in Lua 5.1.
> Not quite, because again, I'd have to copy the entire pattern-matching
> system. While I can see the benefit of making a rock, said rock would
> contain large amounts of duplicated code that would need to be updated
> for almost every release of Lua, same as a fork.
> I'll consider it, though.

For a fork, you'll have to copy the entire Lua :)

In case of a rock, you can maintain a patch and a script. A script
extracts pattern-matching code from Lua and applies a patch.


Best regards,
Boris Nagaev