[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lpeg.Carg() weirdness
- From: Parke <parke.nexus@...>
- Date: Sat, 24 Jun 2017 21:41:10 -0700
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)?
Or possibly one of:
patt / number
patt / string
patt / function
http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#captures
You would have to rebuild the pattern to change the value that would
represent null.
> I'm just curious about the rational for the current behavior.
I find the current behavior to be consistent with other parts of Lua
that raise an error when the arguments provided to a function are
obviously wrong.
> -spc (Still pondering how to deal with this)
Use lpeg.Cc(values). Or, if you don't want to rebuild the pattern,
use patt/function with a closure and with a monkey-patch a wrapper
around the match function to update the value in the closure.
-Parke