Re: Proposal for new LPeg function: lpeg.Ctab()
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Proposal for new LPeg function: lpeg.Ctab()
- From: Sean Conner <sean@...>
- Date: 2016年9月14日 21:37:07 -0400
It was thus said that the Great Daurnimator once stated:
> On 14 September 2016 at 04:59, Sean Conner <sean@conman.org> wrote:
> >
> > Nothing at all what I want. The next solution is to use a folding capture:
> >
> > foo = Cg(C"foo" * EQ * C(value)) * EOL
> > bar = Cg(C"bar" * EQ * C(value)) * EOL
> > other = Cg(C(name) * EQ * C(value)) * EOL
> >
> > list = Cf( -- FOLDING CAPTURE
> > Ct(Cc()) -- SEE [1]
> > * Cg(Cc "foo" * Cc "en")
> > * Cg(Cc "bar" * Cc "false")
> > * (foo + bar + other)^0,
> > function(t,n,v)
> > t[n] = v
> > return t
> > end
> > )
> >
> > It's closer to what I want, and certainly usable:
> >
> > {
> > bravo = "Conner",
> > bar = "true",
> > alpha = "Sean",
> > foo = "de"
> > }
> >
> > and yes, I can complicate the folding function to stuff the non-standard
> > headers into a sub table, but honestly, I'd rather not do that.
>
> Hold on. This is the solution I use and I'm pretty happy with it.
> Instead of you little helper function, you can use `rawset`, which is
> a lua builtin and does exactly what you wrote (except with raw
> accesses). This is mentioned in the lpeg manual.
It's close to what I want, but not quite there. When parsing email [1], I
placed the defined headers at the top level of a table, and other,
non-standard headers in a sub-table named "generic" (okay, maybe not the
best name, but hey ... ). So, a message like:
From: <spc@conman.org>
To: <lua-l@lists.lua.org>
Subject: An example
X-Non-Standard-Header: boo!
would end up being:
{
from = { { address = "spc@conman.org" } }, -- a sequence because there can be multiple froms
to = { { address = "lua-l@lists.lua.org" } },
subject = "An example",
generic =
{
['X-NON-standard-Header'] = "boo!"
}
}
That way, I can interate over the non-standard headers without having to
filter out the standard headers, if that makes sense.
> Furthermore, your 'foo' and 'bar' cases are redundant.
> For clarity, I'd usually just mention them in a comment.
For this example yes. I did add a comment about pretending there was
additional processing since the point was there were a few fields that were
"standard."
I don't use rawset simply because I don't really use rawset all that much
in my code. Had I remembered it, I might have used it in the example. But
a reason not to use rawset---either a field can only appear once and a
custom function can signal an error, or a field can repeat and I want to
keep all possible values.
-spc
[1] https://github.com/spc476/LPeg-Parsers/blob/master/email.lua