Can match specifications be used for non-tracing, non-ETS purposes?

Is there any way (is there any reason to…?) use match specifications (ets:fun2ms, dbg:fun2ms) arbitrarily? Are they specifically for tracing and ETS, or are they a more general facility?

I’ve got a half-formed thought in my head (which I might come back and add more detail to once the caffeine starts working…) that involves using match-specs so that I can pass a pattern match to a function…

You could use ets:test_ms/2?

In principle, they’re just a way to describe selecting data from a collection of Erlang tuples, and are themselves just lists of tuples with some shared understanding of how to interpret them, so you could potentially consume them however you wanted to. Have you looked at qlc?

Is there any way (is there any reason to…?) use match specifications (ets:fun2ms, dbg:fun2ms) arbitrarily? Are they specifically for tracing and ETS, or are they a more general facility?

They are general, see ets:match_spec_run/2. I’ve found use for that on more than one occasion.

2 Likes

They are used in Meck to both match clauses when executing expectations and matching calls in the history.

1 Like

We use match specifications in complex queries over our disk_log internal format logs.

When used as the backing store for a REST Collection of events we convert HTTP queries to match_spec and filter items with ets:test_ms/2. Coupled with a binary tree search of the wrap log files, and a disk_log:chunk_step/2 skip to find the start of the chronologically ordered items, this pattern has proven to be performant and entirely flexible.

4 Likes