[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LPeg 0.11
- From: Miles Bader <miles@...>
- Date: Wed, 03 Apr 2013 08:32:52 +0900
Roberto Ierusalimschy <email@example.com> writes:
>> Right, which is why I'm suggesting an explicit LPeg directive that
>> says "this is OK, I know what I'm doing." The onus is then on the
>> user to make sure that they deal with the effects of this.
> LPeg already has a construction for that: it is called run-time
> captures. This is exactly what a run-time capture does.
> A run-time capture is too expensive if you use it a lot (e.g., one
> call for each char). But if you can manage to insert it only in
> "upper" loops of your grammar, the cost could be quite
> reasonable. For instance, try the following pattern in your little
Hmm, so, a real world use might be more like:
SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES = ...
FILE = (lpeg.P"begin"
[where of course backtracking etc is necessary in
Are you saying I can just do:
function () return true end)^0
Will the use of Cmt here affect the speed of
[So basically I could just define my suggested "lpeg.flush" like:
function lpeg_flush (pattern)
return lpeg.Cmt (pattern, function () return true end)
永日の 澄んだ紺から 永遠へ