Changes between Version 19 and Version 20 of SemanticQuery


Ignore:
Timestamp:
Sep 28, 2012, 12:21:43 PM (12 years ago)
Author:
manualwiki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SemanticQuery

    v19 v20  
    1 {{{#!comment 
    21[[PageOutline]] 
    32 
     
    162161The result shown after this semantic query is the list of all possible call  
    163162chains starting from a given function. 
    164  
    165 }}} 
    166  
    167 [[PageOutline]] 
    168  
    169 = Related pages = 
    170  
    171 This page describes how semantic queries are constructed. 
    172 You may be looking for the following related pages. 
    173  
    174 * [SemanticQuery/Components Available components]: lists the names of currently available initial selectors, selectors and properties and their possible abbreviations and synonyms. 
    175 * [SemanticQuery/Examples Examples]: basic and advanced query examples, and queries for checking coding conventions. 
    176  
    177  
    178 = Querying syntactic and semantic information = 
    179  
    180 A semantic query language was designed to query syntactic and semantic information about Erlang programs. The language concepts are defined according to the semantic units and relationships of the Erlang language, e.g. functions and function calls, records and their usage, etc.  
    181  
    182 The main elements of the language are the '''entities''': module, function, variable, etc. Each entity has a set of selectors and properties. A '''selector''' selects a set of entities that meet the given requirements. A '''property''' describes some properties of an entity type. It is also possible to filter entities based on the properties. A '''filter''' is a boolean expression to select a subset of entities. We can build filters by using properties with boolean values, valid Erlang comparisons, logical operators or embedded queries. For usage examples, see SemanticQuery/Examples. 
    183  
    184 == Formal syntax of the language == 
    185  
    186 {{{ 
    187 semantic_query    ::= initial_selection ['.' query_sequence] 
    188 query_sequence    ::= query ['.' query_sequence] 
    189 query             ::= selection | iteration | closure | property_query 
    190 initial_selection ::= initial_selector ['[' filter ']'] 
    191 selection         ::= selector ['[' filter ']'] 
    192 iteration         ::= '{' query_sequence '}' int ['[' filter ']'] 
    193 closure           ::= '(' query_sequence ')' int ['[' filter ']'] | 
    194                       '(' query_sequence ')+' ['[' filter ']'] 
    195 property_query    ::= property ['[' filter ']'] 
    196 }}} 
    197  
    198 A semantic query is a sequence of queries starting with an initial selector and an optional filter. Queries are 
    199 separated with dots.  
    200 A query is a 
    201 * selection (calculates the relationship with other entities based on selectors) 
    202 * iteration (iterates a query n times) 
    203 * closure (calculates the transitive closure of a query sequence) 
    204 * property query (selects a property of an entity) 
    205  
    206 == Language elements == 
    207  
    208 === Entities === 
    209 Entities correspond to the semantic units of Erlang. The result of a query written in the language is a set of entities. Each element of a set belongs to the same type. We have the following entity types: file, function, variable, macro, record, record 
    210 field expression. Each entity type has a set of selectors and properties defined for them. For details, see SemanticQuery/Components. 
    211  
    212 === Selectors === 
    213 Selectors are binary relations between entities. The entities belong to one of the seven entity types. A selector selects a set of entities that meet given requirements for each entity. 
    214  
    215 ''Example:'' You can select the functions defined in a given module. In that case the selection is a relation between modules and functions. 
    216 {{{ 
    217 @mod.functions 
    218 }}} 
    219  
    220 ==== Initial selectors ==== 
    221 Initial selectors get the current file and position as their parameters and return a set of entities as result. The entities of 
    222 the result belong to the same type, but the type can not always be determined in advance, it depends on the parameters. Almost all of them begin with the character {{{@}}} to indicate that they depend on a position. 
    223  
    224 For example, the initial selector {{{@variable}}} will look for a variable at the given position. If no variable can be found the result will be empty. Besides the position based initial selectors there is another initial selector: {{{mods}}}. This selector returns all of the modules that are loaded into the semantic program graph. 
    225  
    226 === Properties === 
    227 Properties are functions that give the value of the property for an entity. The main purpose of properties is to filter sets of entities using them, but their values can be queried too. To query the value of a property you have to use the name of the property at the end of a semantic query. 
    228  
    229 ''Example:'' To query the value of the property {{{exported}}} for the functions of the given module: 
    230 {{{ 
    231 @module.functions.exported 
    232 }}} 
    233  
    234 ==== Statistics ==== 
    235  
    236 For properties with numeric values statistics are also available. Using these for the results of metric queries can give more 
    237 information than a simple list of values. 
    238  
    239 ''Example:'' To query the average length of the functions of the given module: 
    240 {{{ 
    241 @file.functions.line_of_code:average 
    242 }}} 
    243  
    244 === Filters === 
    245 A filter is a boolean expression to select subsets of entities.  After applying a filter, the result contains the elements of the original set where this boolean expression is true. Building filters is possible using atoms, strings, integers, properties and embedded queries. The use of strings and integers is unambiguous, but the names of properties are atoms, so it is checked for each atom if they are properties or not. 
    246  
    247 Atoms, strings, integers and properties can be used in comparisons. The language uses {{{/=, ==, >=, =<, <}}} and {{{>}}}. The 
    248 results of comparisons are the same as in Erlang. The resulting expressions can be combined by {{{and}}}, {{{or}}}, and {{{not}}} operators, and parentheses can be used, too. The operator precedence for the filters is as follows: 
    249  
    250 ||||   '''Operator precedence (decreasing)'''   || 
    251 ||{{{not}}} ||unary ||  
    252 ||{{{/=, ==, >=, =<, <, >, =:=, =/=}}} ||left associative ||  
    253 ||{{{and}}} ||left associative || 
    254 ||{{{or}}} ||left associative || 
    255  
    256 ''Example:'' you may be interested in all the exported functions of a given module, or the functions with {{{0}}} arity, or maybe a combination of these: the exported functions with {{{0}}} arity. In the example exported and arity are both properties of functions and by using them it is possible to build a filter to select the required subset of functions. 
    257 {{{ 
    258 @module.functions[arity==0 and exported] 
    259 }}} 
    260  
    261 ==== Embedded queries ==== 
    262 Embedded queries can be used to query information about entities that is otherwise unavailable, that is it can not be expressed by the help of properties. 
    263  
    264 For example, we may need the functions with variables named {{{File}}}. This information can not be expressed with the help of properties. Without embedded queries it is only possible to query the variables named {{{File}}} and query the functions containing these variables after that, with the following query: 
    265 {{{ 
    266 mods.functions.variables[name=="File"].function_definition 
    267 }}} 
    268 Embedded queries make it possible to use these kind of queries effectively, without the need to continue with the query directly. The continuation of the query is in the filter, used like a property with a boolean value. The value is considered true if the result of the query is not empty. For the previous example using the following query will give the desired results. 
    269 {{{ 
    270 @mods.functions[.variables[name=="File"]] 
    271 }}} 
    272  
    273 === Iteration === 
    274  
    275 Iteration in the language means the repeated application of a query sequence. The queries are relations and a sequence of queries is a composition of these queries. Using iteration is possible if the domain and codomain of the query sequence is the same. The application is repeated exactly {{{int}}} times. 
    276  
    277 The result shown in this case is not only the result of the iteration but the partial results also, in the form of chains. 
    278  
    279 ''Example:'' 
    280 {{{ 
    281 @function.{calls}3 
    282 }}} 
    283 The result is the same set of entities as of {{{@function.calls.calls.calls}}}. The result shown in the first case will give more information: it gives the call chains with the maximum length of 3 starting from a given function. 
    284  
    285 === Transitive closure === 
    286  
    287 Transitive closure in the language means the closure of a query sequence. The query sequence here is the same as in iteration, a 
    288 binary relation with the same domain and codomain. 
    289  
    290 ''Example:'' 
    291 {{{ 
    292 @function.(calls)+ 
    293 }}} 
    294 The result shown after this semantic query is the list of all possible call chains starting from a given function.