<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello everyone, <br>
    <br>
    I would like to insert in an ETS table a tuple with the following
    type signature: <br>
    <br>
    <i><big><tt>{string(), [{string(), [string()]}]}</tt></big></i><br>
    <br>
    As an example: <br>
    <i><br>
    </i><i><big><tt>{"Peter", [{"children", ["Bob", "Paul"]}, {"father",
          ["Mike"]}]}</tt></big></i><i><br>
      <br>
    </i><br>
    My question is the following: is it possible to solve, using match
    specifications, nested queries like "Retrieve the name of Peter's
    children" ?<br>
    <br>
    That is, a query where I would need to <br>
    <br>
    a) Fetch all ("the", since its a set) tuples of size 3 where "Peter"
    is located in the first position (doable with MS)<br>
    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'). <br>
    <br>
    If I understood correctly, lists:keyfind can't be used inside a
    match specification because they only allow the BIFs described in
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://www.erlang.org/doc/apps/erts/match_spec.html">http://www.erlang.org/doc/apps/erts/match_spec.html</a>.
    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?<br>
    <br>
    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". <br>
    <br>
    Any help of insight will be greatly appreciated. Thank you very much
    in advance. <br>
    <br>
    Diego Llarrull<br>
    <br>
     <br>
    <br>
  </body>
</html>