Using variables in semantic queries

While writing semantic queries sometimes we need to refer back to a property of an entity at some earlier point. To make it clear suppose we want to write such query. A query always has the starting point mods. Moving on we select functions with funs. Here we need to filter all the functions based on its module. Here come the variables in.

The problem can easily solved by the following query:

mods[name=A].funs[name==A]

Here for each module the variable A binds the module's name, that is, the value of A changes.

In the following sections we show how to make variable bindings and present some examples of using variables in semantic queries.

Binding

Variables can only be created using properties in filters. It is valid to write

mods[name=A]

or

mods.funs[A=arity]

but it is semantic error to write

mods[A=not_a_property]

or

mods[A=2].funs[arity==A]

As you may noticed, the binding operator = is commutative. Also, one may interchangeably use = and == to bind and compare. The first = or == binds, the others compare.

The general form of binding is the following:

[property=Variable]

or

[Variable=property]

Variables may bind to values of any type. They can hold atoms, integers, strings etc.

Occurences

Filters

Variables can only occur in filters. In its simplest form a semantic query is sequence of selectors and filters. When a variable binding takes place the variable can be used in any following filter. In other words, the scope of a variable is right from its binding.

mods.funs[name=A].calls[name==A]

yields all function that called by a function with the same name. Example output would be:

module_a:f/0
  module_b:f/1
module_b:g/2
  module_c:g/1

means in the program code f/0 calls f/1.

In comparisons it is allowed to use every operator that standard semantic query language allows. This means ==, /=, >, >=, <, <= and ~ . A variable can be compared to property, variable and literal.

mods.funs[arity=A, A>2]
mods.funs[exported=A, dirty/=A, A==true]
mods[name=A].funs[name=B, A==B]

Conversion

It is important to note that any form of conversion between types is not supported. When you use a value of a variable in a comparison, you have to make sure that both operands have the same type.

mods.funs[name=A].vars[name==A]

yields type error, because vars.name has type of string.

Iterations

Writing such query as

mods.funs.{calls[name=A]}2.name

is exactly the same as writing

mods.funs.calls[name=A].calls[name=A].name

It sheds light on that binding always happens in the first iteration.

One may use previously bound variable or use variable bound inside the iteration later:

mods.funs[name=A].{calls[name==A]}3
mods.funs.{calls[name=A]}2.mod[name==A]

Closures

Similarly to iterations, variables can be used in transitive closures. Here are some examples:

mods.funs.(calls[name=A)+
mods.funs[name=A].(calls[name=A])2.name

The first means all possible call chains that consist of functions with the same name from the second chain link onwards. Example output would be:

module_a:f/0 module_a:g/0 module_a:g/1
module_a:g/0 module_a:g/1