Function entity

Function entities correspond to Erlang functions. They can come from two sources: they are either defined in a module loaded into the database, or just referred to in the loaded code. In the latter case, information about the function may be incomplete.

Initial selector

• @fun at the start of a query, this selector can be used to refer to the "current" function (either a function invoked by the selected call-expression, or a function defined at the current selection).

Selectors

In parentheses you find the type of the result elements.

• refs (expression): returns every expression that refers to the function. These references can be either function applications, import/export directives or fun-expressions.
• dynref (expression): returns every expression that refers to the function by a dynamic function call (e.g. an apply call, for details see DynamicCallAnalysis). Note that you have to run dynamic call analysis prior to using this query.
• calls (function): returns the set of function entities called in the body of the function.
• dyncalls (function): returns the set of functions dynamically called in body of the function (for details, see DynamicCallAnalysis).
• called_by (function): returns every function that calls the specified function (not including dynamic calls).
• dyn_calledby (function): returns the set of functions that call the given function dynamically (for details, see DynamicCallAnalysis).
• args (expression): gives the function arguments as a list of expression entities.
• body (expression): returns the top-level expressions of each clause body.
• exprs (expression): returns the top-level argument, guard, and body expressions of each clause.
• vars (variable): returns the set of variable entities defined (bound) in the body of the function.
• file (file): returns the file entity (the module) that the given function is defined in.

Properties

The following properties are defined on function entities:

• name (atom, string): gives the name of the function.
• exported (bool): returns true if the function is exported.
• arity (int): gives the arity (number of arguments).
• bif (bool): returns true if the function is an auto-imported built-in function.
• pure (bool): returns true if the function is free of side-effects?. We have to mention here, that those functions that are not loaded into the database of RefactorErl (for example, library functions) are considered as impure. If you need a more precise analysis, you should add the affected files to the database of RefactorErl. The knowledge about the BIF-s is built into the tool.
• dirty (bool): returns true if the function has side-effects?, or in other words, it is impure.
• defined (bool): returns true if the definition of the function is loaded into the database.
• module (atom): returns the name of the defining module.
• spec (string): returns the specification of the function (If it is not available in the source code, RefactorErl calculates it.)