On Tue, Mar 4, 2014 at 11:58 PM, Pierre-Yves Gérardy <pygy79@gmail.com> wrote:
On Tue, Mar 4, 2014 at 6:33 PM, Francisco Olarte <folarte@peoplecall.com> wrote:
Aside from that, what really has left me shocked is the fact that
s:find(p,5) gives 5,7.
It is useful to parse a string piecewise. You can do it with an
unanchored pattern, by checking that the start of the match is equal
to the index passed to `.find`. It is wasteful, though, because `find`
may walk the whole subject if it doesn't match. It is even more
wasteful if you want to use `match`, since you must first use `find`
to be sure that the match occured at the desired place.
Yes, it maybe useful, and I'll assume the behaviour has been done this
way due to its usefulness. As the other thing is useful once you start
thinking on functions which get their regexp as parameter and do not
want to preparse it ( like my example, write a funcion which counts
how many non overlapping times a pattern matches in a line, single
line to avoid issues with wether internal newlines count). I do not
know how to make this work with patterns without preparsing the
pattern, but making the opposite is trivial, just match on sub from
the last match.
Likewise, LPeg patterns are anchored to the index passed to `lpeg.match(...)`.
Nice to now.
PCRE has a flag (PCRE_ANCHORED) to trigger that behavior in patterns
without the caret.
Yes, but my point was I've never imagined 'the subject string' would
mean 'the range between init and end' without an explicit
definition.To me a call s.find('^',n) should always fail with n>1, I
mean, I've always read s:find('^',2) as 'find the start of the string
between the second char and the end. Ok, not found. Like if you tell
me 'find a start of day in tomorrow between 12:00 and 14:00', OK, not
found.
