Re: Pattern matching proposal: %B to match balanced string with specified escape

[Jonathan Goble <jcgoble3@...>]

On Tue, Jan 12, 2016 at 7:54 PM, Hisham <h@hisham.hm> wrote:
> On 11 January 2016 at 19:42, Matthew Wild <mwild1@gmail.com> wrote:
>> On 11 January 2016 at 21:06, Jonathan Goble <jcgoble3@gmail.com> wrote:
>> I'm glad it is that way, or Lua would be Python. It doesn't mean your
>> patch isn't useful, or clever. Personally almost every time I use %b,
>> I wish it had a way to handle escaping.
>
> Further, I think I used things like [["[^"]*"]] many times in my code
> in situations where I should have used [[%B"\"]], had I had the
> option. This would make it easier to write more robust code.

Indeed.

>> But Lua simply isn't an all-features-included language.
>
> Given that the net increase of the code size is 5 lines, and the
> additional costs are two ints (memory) and one extra test in the loop
> (execution), I think this feature should be at least given
> consideration as something core-worthy. It is, after all, a clever,
> useful and tiny patch. On the other hand, I don't think I'd pull an
> extra dependency just to have %B (and I especially wouldn't if it
> monkey-patched string.match). But then, I wouldn't pull an extra
> dependency just to have string.rep() either, and that is in the core.

My current plan for the rock is for require"matchext" (or whatever I
end up calling the module) to return its own table of functions,
including an "install" function that users could call to monkey-patch
the string table (leaving the stock functions available in a
"string.original" subtable). Monkey-patching would not occur unless
install() is explicitly called, which could be done as the one-liner
"require('matchext').install()".

Perhaps down the road, I could also add some utility wrappers like a
"tfind"/"tmatch" that returns a single table of captures, instead of
multiple return values (and a "tgmatch" that does the same), somewhat
echoing the "match object" returned by Python's regular expression
match functions. In this way, the module could evolve to be more of a
general extension to the core pattern-matching facilities, rather than
one that provides only a single added feature. But such matters would
be for future consideration.

> Speaking of extra cost concerns, I'm afraid any benchmark on this
> would fall into the traps of microbenchmarks, but it would be nice to
> know if the difference is even measurable. Performance analysis is
> usually part of the process of proposing changes to Lua.

I'm not at all familiar with proper running of benchmarks, and
wouldn't even know what testcases to use to get meaningful results. As
I wish to concentrate on the rock, I welcome any benchmarking that
anyone else wishes to do on the code linked in the OP.