Re: lpeg.Carg() weirdness

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> 2017-06-25 7:51 GMT+02:00 Sean Conner <sean@conman.org>:
> > It was thus said that the Great Parke once stated:
> >> On Sat, Jun 24, 2017 at 9:22 PM, Sean Conner <sean@conman.org> wrote:
> >> >> 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.
> >>
> >> Why not use lpeg.Cc(values)?
> >
> >   Given how I've implemented the module, I return an LPeg userdata, not a
> > table (following the other parsing modules [1]).  I'd like to keep that
> > format if at all possible (and it's seeming like I can't).  If require()
> > passed along any additional paramters to the module, then that could be used
> > to pass along a custom JSON null value, but alas, require() doesn't work
> > that way.
> >
> >   So the only way to pass along an alternative null is through additional
> > arguments to lpeg.match(), which doesn't work the way I would like.
> 
> One very easy method is to use the value of the global variable 'null'.
> By default, it is nil, which will give the current behaviour. A user that
> needs one can define it himself before invoking the LPeg pattern.
> 
> I've made that tiny change to your json.lua, and can report that it works.

  Oh.

  -spc (Why didn't I think of that?)