A few samples from our code - hope it helps.

:ets.select( ets_name( customer ), [ { { { customer, :_ }, { true, :“$1”, :_, :“$2” } },
[ { :andalso,
{ :“==”, {:map_get, :a, {:map_get, :job, :“$2”}}, a},
{ :“==”, {:map_get, :b, {:map_get, :job, :“$2”}}, b}
} ],
[ [:“$1”, :“$2”] ] } ] )

:ets.select_delete( ets_name( customer ), ( for task_id ← task_ids,
do: { { { customer, :_ }, :“$1” }, [ { :“==”, {:map_get, :id, :“$1”}, task_id } ], [:true] } ) )

:ets.select( ets_name( customer ),
[ { { { customer, :_ }, { :, :“$1”, :, :“$2” } },
[ { :andalso,
{ :“>=”, :“$1”, Util.to_dets( date ) },
{ :“<”, :“$1”, Util.to_dets( Util.tomorrow ) }
} ],
[ :“$2” ] } ] )

:ets.select( ets_name( customer ),
[ { { { customer, :_ }, :“$1”, :“$2”, :, : },
[ { :or,
{ :“==”, {:map_get, :reattempt, :“$1”}, @auto },
{ :“==”, {:map_get, :reattempt, :“$1”}, @manual }
} ],
[ :“$1” ] },
{ { { customer, :_ }, :“$1”, @paused, :, : },
,
[ :“$1” ] },
{ { { customer, :_ }, :“$1”, @deleted, :, : },
,
[ :“$1” ] },
( if for_seeding,
do: { false, , [ true ] },
else: { { { customer, :_ }, :“$1”, :, :, true },
,
[ :“$1” ] } )
] )

I feel as if this is 50/50, personally.

• Match specs are already an informal, loosely-documented sort-of-erlang-AST. They are difficult to debug and error prone.
  • The approach I am taking resolves this, as all specs are validated against erlang’s builtin ms test functions at compile time.
• Traversing an even wider conceptual gap from sort-of-erlang-AST to Elixir just adds to the cognitive load in writing, debugging, and maintaining them.
  • The approach I’m taking passes all code through the Elixir compiler first, to throw all the familiar errors and warnings, before converting Elixir code into specs.

This is my real goal: not to solve these kinds of problems, but to make match specs more accessible, and therefore increase their adoption in general, so that more advanced tooling can be easily built on top of them without needing to understand the underlying syntax. What I’m working on was originally a proposal to the language itself, though I feel like it belongs outside it now.

Of course, targeting Elixir AST as the high-level format should help with this a lot: library authors can just leverage Elixir’s powerful macro system to translate things (ex: mnesia schemas, ecto schemas, ets queries) from Elixir code, to Elixir code. Then my library can handle all the fussy details of whether or not it’s a viable match spec without requiring further knowledge.

Not quite sure I understand here—are you saying that you have a known set of ids on hand you want to retrieve verbatim, and doing a single :ets.select/2 call with a match spec is not as efficient as a series of :ets.lookup/2 calls or a single :ets.match/2 call with a match pattern?

I support your effort and I hope I wasn’t giving a different impression. match specs are not intuitive, too different from elixir syntax and little discussed on the web. The pre-compilation validation is a welcome addition. The detailed match specs we currently have look unnecessarily intimidating. There is value in this effort.

My comment on full scan: we tend to duplicate values in :ets storage with keys designed to match the queries we run frequently, so as to use lookup or match instead of more complicated and slower select match specs. In other words, while we do use match specs they tend to be a temporary stop gap but eventually get simpler or are removed entirely, primarily for performance reasons.