Changes between Initial Version and Version 1 of SemanticQuery/Variables

Timestamp:

Sep 17, 2014, 4:47:21 PM (11 years ago)

Author:

manualwiki

Comment:

--

SemanticQuery/Variables

@@ +1 @@
+[[PageOutline]]
+
+= 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
+}}}