lpeg-list; lpeg-table?

[Graham Wakefield <wakefield@...>]

Reading Fabien's article about TreeQuery [1] got me thinking. The combination of predicates and actions immediately made me think of LPEG patterns and captures. I've looked at lpeg-list [2] before to perform some parse tree transforms, but AFAICT there's no built-in pattern for matching key-value pairs in a table, which rather restricts the expressiveness of the parse tree format. 

I wonder if there would be any interest in extending lpeg-list or creating some other lpeg-like library to support dictionary entry patterns (call it lpeg-dict, lpeg-table, lpeg-hash or whatever). Obviously these have no sense of ordering, but can be tested for existence within the current table. It would add some symmetry for the Ct(Cg(...)) idiom often used when generating parse trees. 

Maybe something like this:

E(k, p) 	
k indicates the field to inspect (a string, rather than a pattern, because the latter would add the cost of iterating over all keys). 
p indicates the pattern to run on the corresponding entry value.
If p is omitted, it simply matches for presence of the key k.
Otherwise, if the key k exists in the current context, it applies the pattern p to the table entry for k, and returns any captures. If the current context is not a table, it simply fails to match.
Does not consume any input.

Example: 

local lower = R("az")
local p = E("x", C(lower^1))
p:match { x = "foo" }	-> "foo"


Does this seem like a useful addition? 
Does anybody see any conceptual problems with it? 
Does anybody with working knowledge of the internals of lpeg-list think it could be doable, or would be willing to give me pointers?


[1] http://metalua.blogspot.fr/2011/10/treequery-dsl-for-syntax-tree.html
[2] https://github.com/mascarenhas/lpeg-list