Re: LPEG design patterns

[William Ahern <william@...>]

On Wed, May 01, 2019 at 10:37:35PM +0400, joy mondal wrote:
>  Hi,
> 
> In LPEG , you can pass a variable to your parser using Carg.
> 
> BUT if you build your grammar dynamically for EACH string / file you could
> pre-create state for each of your Cmt functions.
> 
> - One design is stateless ( which has some dubious clarity )
> 
> - One design creates a separate grammar for each string , which is likely
> slower ?

I also assume it would be slower. But if you're facing a dilemma it seems
like it'd be an easy thing to verify experimentally.
 
> Question 1 :: is option 2 a anti-pattern ? do we stick to option 1 ?
> 
> Another issue I feel you have with using Carg is that all your rules have
> Carg  all over the place.
> 
> local patt1 = P(Carg(1)* .................)
> 
> local patt2 = P(Carg(1)* .................)
> 
> I understand that its possible to pass multiple arguments with multiple
> states :
> 
> local patt1 = P(Carg(1)* .................)
> 
> local patt2 = P(Carg(2)* .................)
> 
> local patt2 = P(Carg(3)* .................)
> 
> But it doesn't make things any clearer, and now you need to remember which
> number corresponds to which variable.

You could also just pass a table with named fields. Positional arguments is
merely an obvious choice from an implementation perspective--function
parameters in Lua are positional and lpeg.match is a function. Positional
argument captures isn't a prescription for grammar composition, just an
artifact of the language.