[erlang-questions] Nested match specifications?

[Patrik Nyblom]

Hi!
On 03/04/2013 08:58 PM, Diego Llarrull wrote:
> Hello everyone,
>
> I would like to insert in an ETS table a tuple with the following type 
> signature:
>
> /{string(), [{string(), [string()]}]}/
>
> As an example:
> /
> //{"Peter", [{"children", ["Bob", "Paul"]}, {"father", ["Mike"]}]}//
>
> /
> My question is the following: is it possible to solve, using match 
> specifications, nested queries like "Retrieve the name of Peter's 
> children" ?
>
> That is, a query where I would need to
>
> a) Fetch all ("the", since its a set) tuples of size 3 where "Peter" 
> is located in the first position (doable with MS)
> b) Let '$2' be the value in the second position of the tuple fetched 
> in a). Then, fetch the value corresponding to the key "children" in 
> '$2', if interpreted as a key-value list (i.e. lists:keyfind() should 
> work on '$2').
>
> If I understood correctly, lists:keyfind can't be used inside a match 
> specification because they only allow the BIFs described in 
> http://www.erlang.org/doc/apps/erts/match_spec.html. My question is: 
> is there any low-level mechanism to operate on lists inside match 
> specifications, or am I trying to push the boundaries of match 
> specifications?
>
Yes, you're trying to push the boundaries of match specifications :)

You'll have to do a lists:keysearch/keyfind on the results of the 
ets:select (when you're back in proper Erlang code), only constant time 
BIF's can be added to the ms language, so it's unfortunately not even an 
option to add this particular function... Without a huge rewrite that is...

So...
   [lists:keyfind("children",1,P) || P <- 
ets:select(xxx,ets:fun2ms(fun({"Peter",Data}) -> Data end))].
would be the solution. Except of course if the list has a particular 
order, or you instead use some record'ish data structure, so that you 
can match directly:
   ets:select(xxx,ets:fun2ms(fun({"Peter",[{"children",Data}|_]}) -> 
Data end)).
But looping over the list inside the ms is not possible.
> In case anyone wonders "Why not use Query Lists Comprehensions?" the 
> answer is: "Because of performance issues: in our platform, we need to 
> dynamically build QLCs based on the number of arguments that arrive, 
> which forces us to build them as strings and then use 
> qlc:string_to_handle() which is SLOW".
>
> Any help of insight will be greatly appreciated. Thank you very much 
> in advance.
>
> Diego Llarrull
>
>
Cheers,
/Patrik
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130305/2c2e8936/attachment.htm>