Re: A bug in string.gmatch and string.gsub?

[Dirk Laurie <dirk.laurie@...>]

2013/4/29 TNHarris <telliamed@whoopdedo.org>:
> On Monday, April 29, 2013 03:10:53 PM Dirk Laurie wrote:
>> Besides `sed`, there's also Python:
>> >>> import re
>> >>> re.subn(re.compile("a*"),"ITEM",";a;")
>>
>> ('ITEM;ITEM;ITEM', 3)
>>
>> Many Lua users come from a background in which they know sed and Python.
>> That tends to influence what things they find intuitive.
>
> However, Perl and PHP do the same thing as Lua.

I know no PHP, but I'll grant you Perl. It's the best-documented
language I've ever come across. The exact point is discussed in its
reference manual, and it says:

   The higher-level loops preserve an additional state between iterations:
   whether the last match was zero-length.  To break the loop, the following
   match after a zero-length match is prohibited to have a length of zero.

I.e. in Perl, the way it is implemented in Lua is actually documented to be
the way it is. One can't argue with that.

But in Lua it is not so documented; it is no more part of Lua than the
pre-5.2.2 treatment of out-of-range index values to table.reduce and
table.insert was part of Lua. In Lua it is merely the way that strlib.c
happens to implement it. One can argue with that.

> And LPEG...
>> re = require"re"
>> print(re.gsub(";a;","'a'*","ITEM"))
> /home/tnharris/share/lua/5.2/re.lua:230: loop body may accept empty string

I don't think I can grant you LPEG. LPEG simply says a pattern inside
a loop is not allowed to match the empty string. That's already so at
the pure LPEG level: `(lpeg.P"a"^0)^2` is illegal. There is no gotcha
here.  Again, one can't argue with that.