Re: lpeg.Carg() weirdness

[Sean Conner <sean@...>]

It was thus said that the Great Parke once stated:
> On Sat, Jun 24, 2017 at 4:10 PM, Sean Conner <sean@conman.org> wrote:
> >
> >         x = pat:match('a')
> >         x = pat:match('a',1,nil)
> >
> >   So, what, exactly *is* the difference between the two calls?  I mean,
> > besides the explicit nil being given in the second call.
> 
> According to the docs, lpeg.Carg(n) produces "the value of the nth
> extra argument to lpeg.match (matches the empty string)"
> 
> http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#captures
> 
> Therefore:  Carg(n) requires that there be at least n extra arguments.
> The difference between the two calls is that the first call provides
> no extra arguments, whereas the second call provides the required one
> extra argument.

  Well ... yes.  I understand all that.  But the third parameter, the
starting position, is optional.  I was just hoping that Carg(n) would return
nil if extra argument didn't exist.

> > -spc (Bummed about this ... )
> 
> Why?  What are you trying to do?

  I have LPeg code to decode JSON data [1].  I received email from a person
about the handling of 'null'---that is, I return a Lua nil value, but this
person wanted a custom value.  I'm not completely swayed by the arguments
for a custom JSON null value, but I would like to provide the option for
such.  I thought a good way to handle a situation would be with Carg()---if
you want a custom null value, one could be provided, but it's optional.

  The intent was:

	doc = json:match(data)

would return a Lua nil for a JSON null, but if you wanted a custom value:

	doc = json:match(data,1,customjsonnullvalue)

  I'm just curious about the rational for the current behavior.  Heck, I
would even accept the following:

	x = lpeg.P"a" * lpeg.Carg(1)  -- if Carg(1) exists
	  + lpeg.P"a" * lpeg.Cc(blah) -- and if it doesn't

  -spc (Still pondering how to deal with this)

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/json.lua