Re: [ANN] LPeg 0.11

[Miles Bader <miles@...>]

Roberto Ierusalimschy <roberto@inf.puc-rio.br> 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
> experiment:

Hmm, so, a real world use might be more like:

   SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES = ...

   FILE = (lpeg.P"begin"
           * SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES^0
           * lpeg.P"end")

[where of course backtracking etc is necessary in
SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES]

Are you saying I can just do:

FILE =
   (lpeg.P"begin"
    * lpeg.Cmt(SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES,
               function () return true end)^0
    * lpeg.P"end")

?

Will the use of Cmt here affect the speed of
SUPER_COMPLEX_GRAMMAR_WITH_LOTS_OF_CAPTURES?

[So basically I could just define my suggested "lpeg.flush" like:

 function lpeg_flush (pattern)
   return lpeg.Cmt (pattern, function () return true end)
 end

 ?]

Thanks,

-miles

-- 
永日の　澄んだ紺から　永遠へ