cerl
Module
Module Summary
Description
Core Erlang abstract syntax trees.
This module defines an abstract data type for representing Core Erlang source code as syntax trees.
A recommended starting point for the first-time user is the documentation of the function type/1.
NOTES:
This module deals with the composition and decomposition of syntactic entities (as opposed to semantic ones); its purpose is to hide all direct references to the data structures used to represent these entities. With few exceptions, the functions in this module perform no semantic interpretation of their inputs, and in general, the user is assumed to pass type-correct arguments - if this is not done, the effects are not defined.
Currently, the internal data structure used is the same as the record-based data structures used traditionally in the Beam compiler.
The internal representations of abstract syntax trees are subject to change without notice, and should not be documented outside this module. Furthermore, we do not give any guarantees on how an abstract syntax tree may or may not be represented, with the following exceptions: no syntax tree is represented by a single atom, such as none, by a list constructor [X | Y], or by the empty list []. This can be relied on when writing functions that operate on syntax trees.
DATA TYPES
- c_binary() = #c_binary{}
- c_bitstr() = #c_bitstr{}
- c_call() = #c_call{}
- c_clause() = #c_clause{}
- c_cons() = #c_cons{}
- c_fun() = #c_fun{}
- c_let() = #c_let{}
- c_literal() = #c_literal{}
- c_map() = #c_map{}
- c_map_pair() = #c_map_pair{}
- c_module() = #c_module{}
- c_tuple() = #c_tuple{}
- c_values() = #c_values{}
- c_var() = #c_var{}
- cerl()
-
An abstract Core Erlang syntax tree.
Every abstract syntax tree has a type, given by the function type/1. In addition, each syntax tree has a list of user annotations (cf. get_ann/1), which are included in the Core Erlang syntax.
- map_op() = #c_literal{val=assoc} | #c_literal{val=exact}
- var_name() = integer() | atom() | {atom(), integer()}
Creates a syntax tree corresponding to an Erlang term. Term must be a literal term, i.e., one that can be represented as a source code literal. Thus, it may not contain a process identifier, port, reference, binary or function value as a subterm.
Note: This is a constant time operation.
See also: ann_abstract/2, concrete/1, is_literal/1, is_literal_term/1.
See also: abstract/1.
See also: c_alias/2.
See also: c_apply/2.
Types
See also: c_atom/1.
See also: c_binary/1.
Equivalent to ann_c_bitstr(As, Value, Size, abstract(1), Type, Flags).
See also: ann_c_bitstr/5, c_bitstr/5.
See also: c_call/3.
See also: c_case/2.
See also: c_catch/1.
See also: c_char/1.
See also: ann_c_clause/3, c_clause/3.
See also: c_cons/2.
See also: c_cons_skel/2.
See also: c_float/1.
See also: c_fun/2.
See also: c_int/1.
See also: c_let/3.
See also: c_letrec/2.
See also: ann_c_module/5, c_module/3.
See also: ann_c_module/4, c_module/4.
See also: c_nil/0.
See also: c_primop/2.
Equivalent to ann_c_receive(As, Clauses, c_atom(infinity), c_atom(true)).
See also: c_atom/1, c_receive/3.
See also: ann_c_receive/2, c_receive/3.
See also: c_seq/2.
See also: c_string/1.
See also: c_try/5.
See also: c_tuple/1.
See also: c_tuple_skel/1.
See also: c_values/1.
See also: c_var/1.
See also: make_data/2.
See also: make_data_skel/2.
Equivalent to ann_make_list(As, List, none).
Types
See also: ann_make_list/2, make_list/2.
Creates a syntax tree with the given annotations, type and subtrees. See make_tree/2 for details.
See also: make_tree/2.
Returns the list of argument subtrees of an abstract function application.
See also: apply_arity/1, c_apply/2.
Returns the number of argument subtrees of an abstract function application.
Note: this is equivalent to length(apply_args(Node)), but potentially more efficient.
See also: apply_args/1, c_apply/2.
Returns the literal string represented by an abstract atom. This always includes surrounding single-quote characters.
Note that an abstract atom may have several literal representations, and that the representation yielded by this function is not fixed; e.g., atom_lit(c_atom("a\012b")) could yield the string "\'a\\nb\'".
See also: c_atom/1.
Returns the list of segment subtrees of an abstract binary-template.
See also: c_binary/1, c_bitstr/5.
Returns the total size in bits of an abstract bit-string template. If the size field is an integer literal, the result is the product of the size and unit values; if the size field is the atom literal all, the atom all is returned. If the size is not a literal, the atom any is returned.
See also: c_bitstr/5.
Creates an abstract pattern alias. The result represents "Variable = Pattern".
See also: alias_pat/1, alias_var/1, ann_c_alias/3, c_clause/3, is_c_alias/1, update_c_alias/3.
Creates an abstract function application. If Arguments is [A1, ..., An], the result represents "apply Operator(A1, ..., An)".
See also: ann_c_apply/3, apply_args/1, apply_arity/1, apply_op/1, c_call/3, c_primop/2, is_c_apply/1, update_c_apply/3.
Types
Creates an abstract atom literal. The print name of the atom is the character sequence represented by Name.
Note: passing a string as argument to this function causes a corresponding atom to be created for the internal representation.
See also: ann_c_atom/2, atom_lit/1, atom_name/1, atom_val/1, is_c_atom/1.
Creates an abstract binary-template. A binary object is in this context a sequence of an arbitrary number of bits. (The number of bits used to be evenly divisible by 8, but after the introduction of bit strings in the Erlang language, the choice was made to use the binary template for all bit strings.) It is specified by zero or more bit-string template segments of arbitrary lengths (in number of bits). If Segments is [S1, ..., Sn], the result represents "#{S1, ..., Sn}#". All the Si must have type bitstr.
See also: ann_c_binary/2, binary_segments/1, c_bitstr/5, is_c_binary/1, update_c_binary/2.
Equivalent to c_bitstr(Value, abstract(all), abstract(1), Type, Flags).
Equivalent to c_bitstr(Value, Size, abstract(1), Type, Flags).
Creates an abstract bit-string template. These can only occur as components of an abstract binary-template (see c_binary/1). The result represents "#<Value>(Size, Unit, Type, Flags)", where Unit must represent a positive integer constant, Type must represent a constant atom (one of 'integer', 'float', or 'binary'), and Flags must represent a constant list "[F1, ..., Fn]" where all the Fi are atoms.
See also: ann_c_bitstr/6, bitstr_flags/1, bitstr_size/1, bitstr_type/1, bitstr_unit/1, bitstr_val/1, c_binary/1, is_c_bitstr/1, update_c_bitstr/6.
Creates an abstract inter-module call. If Arguments is [A1, ..., An], the result represents "call Module:Name(A1, ..., An)".
See also: ann_c_call/4, c_apply/2, c_primop/2, call_args/1, call_arity/1, call_module/1, call_name/1, is_c_call/1, update_c_call/4.
Creates an abstract case-expression. If Clauses is [C1, ..., Cn], the result represents "case Argument of C1 ... Cn end". Clauses must not be empty.
See also: ann_c_case/3, c_clause/3, case_arg/1, case_arity/1, case_clauses/1, is_c_case/1, update_c_case/3.
Creates an abstract catch-expression. The result represents "catch Body".
Note: catch-expressions can be rewritten as try-expressions, and will eventually be removed from Core Erlang.
See also: ann_c_catch/2, c_try/5, catch_body/1, is_c_catch/1, update_c_catch/2.
Types
Creates an abstract character literal. If the local implementation of Erlang defines char() as a subset of integer(), this function is equivalent to c_int/1. Otherwise, if the given value is an integer, it will be converted to the character with the corresponding code. The lexical representation of a character is "$Char", where Char is a single printing character or an escape sequence.
See also: ann_c_char/2, c_int/1, c_string/1, char_lit/1, char_val/1, is_c_char/1, is_print_char/1.
Creates an an abstract clause. If Patterns is [P1, ..., Pn], the result represents "<P1, ..., Pn> when Guard -> Body".
See also: ann_c_clause/4, c_case/2, c_clause/2, c_receive/3, clause_arity/1, clause_body/1, clause_guard/1, clause_pats/1, clause_vars/1, is_c_clause/1, update_c_clause/4.
Creates an abstract list constructor. The result represents "[Head | Tail]". Note that if both Head and Tail have type literal, then the result will also have type literal, and annotations on Head and Tail are lost.
Recall that in Erlang, the tail element of a list constructor is not necessarily a list.
See also: ann_c_cons/3, c_cons_skel/2, c_nil/0, cons_hd/1, cons_tl/1, is_c_cons/1, is_c_list/1, list_elements/1, list_length/1, make_list/2, update_c_cons/3.
Creates an abstract list constructor skeleton. Does not fold constant literals, i.e., the result always has type cons, representing "[Head | Tail]".
This function is occasionally useful when it is necessary to have annotations on the subnodes of a list constructor node, even when the subnodes are constant literals. Note however that is_literal/1 will yield false and concrete/1 will fail if passed the result from this function.
fold_literal/1 can be used to revert a node to the normal-form representation.
See also: ann_c_cons_skel/3, c_cons/2, c_nil/0, concrete/1, fold_literal/1, is_c_cons/1, is_c_list/1, is_literal/1, update_c_cons_skel/3.
Creates an abstract floating-point literal. The lexical representation is the decimal floating-point numeral of Value.
See also: ann_c_float/2, float_lit/1, float_val/1, is_c_float/1.
Equivalent to c_var({Name, Arity}).
See also: ann_c_fname/3, fname_arity/1, fname_id/1, is_c_fname/1, update_c_fname/3.
Creates an abstract fun-expression. If Variables is [V1, ..., Vn], the result represents "fun (V1, ..., Vn) -> Body". All the Vi must have type var.
See also: ann_c_fun/3, fun_arity/1, fun_body/1, fun_vars/1, is_c_fun/1, update_c_fun/3.
Creates an abstract integer literal. The lexical representation is the canonical decimal numeral of Value.
See also: ann_c_int/2, c_char/1, int_lit/1, int_val/1, is_c_int/1.
Creates an abstract let-expression. If Variables is [V1, ..., Vn], the result represents "let <V1, ..., Vn> = Argument in Body". All the Vi must have type var.
See also: ann_c_let/4, is_c_let/1, let_arg/1, let_arity/1, let_body/1, let_vars/1, update_c_let/4.
Creates an abstract letrec-expression. If Definitions is [{V1, F1}, ..., {Vn, Fn}], the result represents "letrec V1 = F1 ... Vn = Fn in Body. All the Vi must have type var and represent function names. All the Fi must have type 'fun'.
See also: ann_c_letrec/3, is_c_letrec/1, letrec_body/1, letrec_defs/1, letrec_vars/1, update_c_letrec/3.
Equivalent to c_module(Name, Exports, [], Definitions).
Creates an abstract module definition. The result represents
module Name [E1, ..., Ek]
attributes [K1 = T1, ...,
Km = Tm]
V1 = F1
...
Vn = Fn
end
if Exports = [E1, ..., Ek], Attributes = [{K1, T1}, ..., {Km, Tm}], and Definitions = [{V1, F1}, ..., {Vn, Fn}].
Name and all the Ki must be atom literals, and all the Ti must be constant literals. All the Vi and Ei must have type var and represent function names. All the Fi must have type 'fun'.
See also: ann_c_module/4, ann_c_module/5, c_atom/1, c_fun/2, c_module/3, c_var/1, is_literal/1, module_attrs/1, module_defs/1, module_exports/1, module_name/1, module_vars/1, update_c_module/5.
Creates an abstract empty list. The result represents "[]". The empty list is traditionally called "nil".
See also: ann_c_nil/1, c_cons/2, is_c_list/1.
Creates an abstract primitive operation call. If Arguments is [A1, ..., An], the result represents "primop Name(A1, ..., An)". Name must be an atom literal.
See also: ann_c_primop/3, c_apply/2, c_call/3, is_c_primop/1, primop_args/1, primop_arity/1, primop_name/1, update_c_primop/3.
Creates an abstract receive-expression. If Clauses is [C1, ..., Cn], the result represents "receive C1 ... Cn after Timeout -> Action end".
See also: ann_c_receive/4, c_receive/1, is_c_receive/1, receive_action/1, receive_clauses/1, receive_timeout/1, update_c_receive/4.
Creates an abstract sequencing expression. The result represents "do Argument Body".
See also: ann_c_seq/3, is_c_seq/1, seq_arg/1, seq_body/1, update_c_seq/3.
Creates an abstract string literal. Equivalent to creating an abstract list of the corresponding character literals (cf. is_c_string/1), but is typically more efficient. The lexical representation of a string is ""Chars"", where Chars is a sequence of printing characters or spaces.
See also: ann_c_string/2, c_char/1, is_c_string/1, is_print_string/1, string_lit/1, string_val/1.
Creates an abstract try-expression. If Variables is [V1, ..., Vn] and ExceptionVars is [X1, ..., Xm], the result represents "try Argument of <V1, ..., Vn> -> Body catch <X1, ..., Xm> -> Handler". All the Vi and Xi must have type var.
See also: ann_c_try/6, c_catch/1, is_c_try/1, try_arg/1, try_body/1, try_vars/1, update_c_try/6.
Creates an abstract tuple. If Elements is [E1, ..., En], the result represents "{E1, ..., En}". Note that if all nodes in Elements have type literal, or if Elements is empty, then the result will also have type literal and annotations on nodes in Elements are lost.
Recall that Erlang has distinct 1-tuples, i.e., {X} is always distinct from X itself.
See also: ann_c_tuple/2, c_tuple_skel/1, is_c_tuple/1, tuple_arity/1, tuple_es/1, update_c_tuple/2.
Creates an abstract tuple skeleton. Does not fold constant literals, i.e., the result always has type tuple, representing "{E1, ..., En}", if Elements is [E1, ..., En].
This function is occasionally useful when it is necessary to have annotations on the subnodes of a tuple node, even when all the subnodes are constant literals. Note however that is_literal/1 will yield false and concrete/1 will fail if passed the result from this function.
fold_literal/1 can be used to revert a node to the normal-form representation.
See also: ann_c_tuple_skel/2, c_tuple/1, concrete/1, fold_literal/1, is_c_tuple/1, is_literal/1, tuple_es/1, update_c_tuple_skel/2.
Creates an abstract value list. If Elements is [E1, ..., En], the result represents "<E1, ..., En>".
See also: ann_c_values/2, is_c_values/1, update_c_values/2, values_arity/1, values_es/1.
Types
Creates an abstract variable. A variable is identified by its name, given by the Name parameter.
If a name is given by a single atom, it should either be a "simple" atom which does not need to be single-quoted in Erlang, or otherwise its print name should correspond to a proper Erlang variable, i.e., begin with an uppercase character or an underscore. Names on the form {A, N} represent function name variables "A/N"; these are special variables which may be bound only in the function definitions of a module or a letrec. They may not be bound in let expressions and cannot occur in clause patterns. The atom A in a function name may be any atom; the integer N must be nonnegative. The functions c_fname/2 etc. are utilities for handling function name variables.
When printing variable names, they must have the form of proper Core Erlang variables and function names. E.g., a name represented by an integer such as 42 could be formatted as "_42", an atom 'Xxx' simply as "Xxx", and an atom foo as "_foo". However, one must assure that any two valid distinct names are never mapped to the same strings. Tuples such as {foo, 2} representing function names can simply by formatted as "'foo'/2", with no risk of conflicts.
See also: ann_c_var/2, c_fname/2, c_letrec/2, c_module/4, is_c_var/1, update_c_var/2, var_name/1.
Returns the list of argument subtrees of an abstract inter-module call.
See also: c_call/3, call_arity/1.
Returns the number of argument subtrees of an abstract inter-module call.
Note: this is equivalent to length(call_args(Node)), but potentially more efficient.
See also: c_call/3, call_args/1.
Equivalent to clause_arity(hd(case_clauses(Node))), but potentially more efficient.
See also: c_case/2, case_clauses/1, clause_arity/1.
Returns the list of clause subtrees of an abstract case-expression.
See also: c_case/2, case_arity/1.
Returns the literal string represented by an abstract character. This includes a leading $ character. Currently, all characters that are not in the set of ISO 8859-1 (Latin-1) "printing" characters will be escaped.
See also: c_char/1.
Returns the number of pattern subtrees of an abstract clause.
Note: this is equivalent to length(clause_pats(Node)), but potentially more efficient.
See also: c_clause/3, clause_pats/1.
Returns the list of all abstract variables in the patterns of an abstract clause. The order of listing is not defined.
See also: c_clause/3, pat_list_vars/1.
Returns the Erlang term represented by a syntax tree. An exception is thrown if Node does not represent a literal term.
Note: This is a constant time operation.
See also: abstract/1, is_literal/1.
Returns the tail subtree of an abstract list constructor.
Recall that the tail does not necessarily represent a proper list.
See also: c_cons/2.
Returns the list of subtrees of a data constructor node. If the arity of the constructor is zero, the result is the empty list.
Note: if data_type(Node) is cons, the number of subtrees is exactly two. If data_type(Node) is {atomic, Value}, the number of subtrees is zero.
See also: data_arity/1, data_type/1, is_data/1, make_data/2.
Types
Returns a type descriptor for a data constructor node. (Cf. is_data/1.) This is mainly useful for comparing types and for constructing new nodes of the same type (cf. make_data/2). If Node represents an integer, floating-point number, atom or empty list, the result is {atomic, Value}, where Value is the value of concrete(Node), otherwise the result is either cons or tuple.
Type descriptors can be compared for equality or order (in the Erlang term order), but remember that floating-point values should in general never be tested for equality.
See also: concrete/1, is_data/1, make_data/2, type/1.
Returns the identifier part of an abstract function name variable.
See also: c_fname/2, fname_arity/1.
Assures that literals have a compact representation. This is occasionally useful if c_cons_skel/2, c_tuple_skel/1 or unfold_literal/1 were used in the construction of Node, and you want to revert to the normal "folded" representation of literals. If Node represents a tuple or list constructor, its elements are rewritten recursively, and the node is reconstructed using c_cons/2 or c_tuple/1, respectively; otherwise, Node is not changed.
See also: c_cons/2, c_cons_skel/2, c_tuple/1, c_tuple_skel/1, is_literal/1, unfold_literal/1.
Types
Translates an explicit record representation to a corresponding abstract syntax tree. The records are defined in the file "core_parse.hrl".
See also: to_records/1, type/1.
Returns the number of parameter subtrees of an abstract fun-expression.
Note: this is equivalent to length(fun_vars(Node)), but potentially more efficient.
See also: c_fun/2, fun_vars/1.
Returns the list of parameter subtrees of an abstract fun-expression.
See also: c_fun/2, fun_arity/1.
Returns the list of user annotations associated with a syntax tree node. For a newly created node, this is the empty list. The annotations may be any terms.
See also: set_ann/2.
Returns true if Node is an abstract inter-module call expression; otherwise false.
See also: c_call/3.
Returns true if Node may represent a character literal, otherwise false.
If the local implementation of Erlang defines char() as a subset of integer(), then is_c_int(Node) will also yield true.
See also: c_char/1, is_print_char/1.
Returns true if Node is an abstract function name variable, otherwise false.
See also: c_fname/2, c_var/1, var_name/1.
Returns true if Node represents a proper list, otherwise false. A proper list is either the empty list [], or a cons cell [Head | Tail], where recursively Tail is a proper list.
Note: Because Node is a syntax tree, the actual run-time values corresponding to its subtrees may often be partially or completely unknown. Thus, if Node represents e.g. "[... | Ns]" (where Ns is a variable), then the function will return false, because it is not known whether Ns will be bound to a list at run-time. If Node instead represents e.g. "[1, 2, 3]" or "[A | []]", then the function will return true.
See also: c_cons/2, c_nil/0, list_elements/1, list_length/1.
Returns true if Node is an abstract primitive operation call, otherwise false.
See also: c_primop/2.
Returns true if Node may represent a string literal, otherwise false. Strings are defined as lists of characters; see is_c_char/1 for details.
See also: c_string/1, is_c_char/1, is_print_string/1.
Returns true if Node represents a data constructor, otherwise false. Data constructors are cons cells, tuples, and atomic literals.
See also: data_arity/1, data_es/1, data_type/1.
Returns true if Node is a leaf node, otherwise false. The current leaf node types are literal and var.
Note: all literals (cf. is_literal/1) are leaf nodes, even if they represent structured (constant) values such as {foo, [bar, baz]}. Also note that variables are leaf nodes but not literals.
See also: is_literal/1, type/1.
Returns true if Node represents a literal term, otherwise false. This function returns true if and only if the value of concrete(Node) is defined.
Note: This is a constant time operation.
See also: abstract/1, concrete/1, fold_literal/1.
Returns true if Term can be represented as a literal, otherwise false. This function takes time proportional to the size of Term.
See also: abstract/1.
Returns true if Node may represent a "printing" character, otherwise false. (Cf. is_c_char/1.) A "printing" character has either a given graphical representation, or a "named" escape sequence such as "\n". Currently, only ISO 8859-1 (Latin-1) character values are recognized.
See also: c_char/1, is_c_char/1.
Returns true if Node may represent a string literal containing only "printing" characters, otherwise false. See is_c_string/1 and is_print_char/1 for details. Currently, only ISO 8859-1 (Latin-1) character values are recognized.
See also: c_string/1, is_c_string/1, is_print_char/1.
Returns the number of left-hand side variables of an abstract let-expression.
Note: this is equivalent to length(let_vars(Node)), but potentially more efficient.
See also: c_let/3, let_vars/1.
Returns the list of left-hand side variables of an abstract let-expression.
See also: c_let/3, let_arity/1.
Returns the list of definitions of an abstract letrec-expression. If Node represents "letrec V1 = F1 ... Vn = Fn in Body", the returned value is [{V1, F1}, ..., {Vn, Fn}].
See also: c_letrec/2.
Returns the list of left-hand side function variable subtrees of a letrec-expression. If Node represents "letrec V1 = F1 ... Vn = Fn in Body", the returned value is [V1, ..., Vn].
See also: c_letrec/2.
Returns the list of element subtrees of an abstract list. Node must represent a proper list. E.g., if Node represents "[X1, X2 | [X3, X4 | []]", then list_elements(Node) yields the list [X1, X2, X3, X4].
See also: c_cons/2, c_nil/0, is_c_list/1, list_length/1, make_list/2.
Returns the number of element subtrees of an abstract list. Node must represent a proper list. E.g., if Node represents "[X1 | [X2, X3 | [X4, X5, X6]]]", then list_length(Node) returns the integer 6.
Note: this is equivalent to length(list_elements(Node)), but potentially more efficient.
See also: c_cons/2, c_nil/0, is_c_list/1, list_elements/1.
Creates a data constructor node with the specified type and subtrees. (Cf. data_type/1.) An exception is thrown if the length of Elements is invalid for the given Type; see data_es/1 for arity constraints on constructor types.
See also: ann_make_data/3, data_es/1, data_type/1, make_data_skel/2, update_data/3.
Like make_data/2, but analogous to c_tuple_skel/1 and c_cons_skel/2.
See also: ann_make_data_skel/3, c_cons_skel/2, c_tuple_skel/1, make_data/2, update_data_skel/3.
Equivalent to make_list(List, none).
Types
Creates an abstract list from the elements in List and the optional Tail. If Tail is none, the result will represent a nil-terminated list, otherwise it represents "[... | Tail]".
See also: ann_make_list/3, c_cons/2, c_nil/0, list_elements/1, update_list/3.
Creates a syntax tree with the given type and subtrees. Type must be a node type name (cf. type/1) that does not denote a leaf node type (cf. is_leaf/1). Groups must be a nonempty list of groups of syntax trees, representing the subtrees of a node of the given type, in left-to-right order as they would occur in the printed program text, grouped by category as done by subtrees/1.
The result of ann_make_tree(get_ann(Node), type(Node), subtrees(Node)) (cf. update_tree/2) represents the same source code text as the original Node, assuming that subtrees(Node) yields a nonempty list. However, it does not necessarily have the exact same data representation as Node.
See also: ann_make_tree/3, is_leaf/1, subtrees/1, type/1, update_tree/2.
Creates a meta-representation of a syntax tree. The result represents an Erlang expression "MetaTree" which, if evaluated, will yield a new syntax tree representing the same source code text as Tree (although the actual data representation may be different). The expression represented by MetaTree is implementation independent with regard to the data structures used by the abstract syntax tree implementation.
Any node in Tree whose node type is var (cf. type/1), and whose list of annotations (cf. get_ann/1) contains the atom meta_var, will remain unchanged in the resulting tree, except that exactly one occurrence of meta_var is removed from its annotation list.
The main use of the function meta/1 is to transform a data structure Tree, which represents a piece of program code, into a form that is representation independent when printed. E.g., suppose Tree represents a variable named "V". Then (assuming a function print/1 for printing syntax trees), evaluating print(abstract(Tree)) - simply using abstract/1 to map the actual data structure onto a syntax tree representation - would output a string that might look something like "{var, ..., 'V'}", which is obviously dependent on the implementation of the abstract syntax trees. This could e.g. be useful for caching a syntax tree in a file. However, in some situations like in a program generator generator (with two "generator"), it may be unacceptable. Using print(meta(Tree)) instead would output a representation independent syntax tree generating expression; in the above case, something like "cerl:c_var('V')".
The implementation tries to generate compact code with respect to literals and lists.
See also: abstract/1, get_ann/1, type/1.
Returns the list of pairs of attribute key/value subtrees of an abstract module definition.
See also: c_module/4.
Returns the list of left-hand side function variable subtrees of an abstract module definition.
See also: c_module/4.
Returns the list of all abstract variables in the given patterns. An exception is thrown if some element in Patterns does not represent a well-formed Core Erlang clause pattern. The order of listing is not defined.
See also: clause_vars/1, pat_vars/1.
Returns the list of all abstract variables in a pattern. An exception is thrown if Node does not represent a well-formed Core Erlang clause pattern. The order of listing is not defined.
See also: clause_vars/1, pat_list_vars/1.
Returns the list of argument subtrees of an abstract primitive operation call.
See also: c_primop/2, primop_arity/1.
Returns the number of argument subtrees of an abstract primitive operation call.
Note: this is equivalent to length(primop_args(Node)), but potentially more efficient.
See also: c_primop/2, primop_args/1.
Sets the list of user annotations of Node to Annotations.
See also: add_ann/2, copy_ann/2, get_ann/1.
Returns the literal string represented by an abstract string. This includes surrounding double-quote characters "...". Currently, characters that are not in the set of ISO 8859-1 (Latin-1) "printing" characters will be escaped, except for spaces.
See also: c_string/1.
Returns the grouped list of all subtrees of a node. If Node is a leaf node (cf. is_leaf/1), this is the empty list, otherwise the result is always a nonempty list, containing the lists of subtrees of Node, in left-to-right order as they occur in the printed program text, and grouped by category. Often, each group contains only a single subtree.
Depending on the type of Node, the size of some groups may be variable (e.g., the group consisting of all the elements of a tuple), while others always contain the same number of elements - usually exactly one (e.g., the group containing the argument expression of a case-expression). Note, however, that the exact structure of the returned list (for a given node type) should in general not be depended upon, since it might be subject to change without notice.
The function subtrees/1 and the constructor functions make_tree/2 and update_tree/2 can be a great help if one wants to traverse a syntax tree, visiting all its subtrees, but treat nodes of the tree in a uniform way in most or all cases. Using these functions makes this simple, and also assures that your code is not overly sensitive to extensions of the syntax tree data type, because any node types not explicitly handled by your code can be left to a default case.
For example:
postorder(F, Tree) ->
F(case subtrees(Tree) of
[] -> Tree;
List -> update_tree(Tree,
[[postorder(F, Subtree)
|| Subtree <- Group]
|| Group <- List])
end).
maps the function F on Tree and all its subtrees, doing a post-order traversal of the syntax tree. (Note the use of update_tree/2 to preserve annotations.) For a simple function like:
f(Node) ->
case type(Node) of
atom -> atom("a_" ++ atom_name(Node));
_ -> Node
end.
the call postorder(fun f/1, Tree) will yield a new representation of Tree in which all atom names have been extended with the prefix "a_", but nothing else (including annotations) has been changed.
See also: is_leaf/1, make_tree/2, update_tree/2.
Translates an abstract syntax tree to a corresponding explicit record representation. The records are defined in the file "cerl.hrl".
See also: from_records/1, type/1.
Returns the number of element subtrees of an abstract tuple.
Note: this is equivalent to length(tuple_es(Node)), but potentially more efficient.
See also: c_tuple/1, tuple_es/1.
Returns the type tag of Node. Current node types are:
alias
apply
binary
bitstr
call
case
catch
clause
cons
fun
let
letrec
literal
map
map_pair
module
primop
receive
seq
try
tuple
values
var
Note: The name of the primary constructor function for a node type is always the name of the type itself, prefixed by "c_"; recognizer predicates are correspondingly prefixed by "is_c_". Furthermore, to simplify preservation of annotations (cf. get_ann/1), there are analogous constructor functions prefixed by "ann_c_" and "update_c_", for setting the annotation list of the new node to either a specific value or to the annotations of an existing node, respectively.
See also: abstract/1, c_alias/2, c_apply/2, c_binary/1, c_bitstr/5, c_call/3, c_case/2, c_catch/1, c_clause/3, c_cons/2, c_fun/2, c_let/3, c_letrec/2, c_module/3, c_primop/2, c_receive/1, c_seq/2, c_try/5, c_tuple/1, c_values/1, c_var/1, data_type/1, from_records/1, get_ann/1, meta/1, subtrees/1, to_records/1.
Assures that literals have a fully expanded representation. If Node represents a literal tuple or list constructor, its elements are rewritten recursively, and the node is reconstructed using c_cons_skel/2 or c_tuple_skel/1, respectively; otherwise, Node is not changed. The fold_literal/1 can be used to revert to the normal compact representation.
See also: c_cons/2, c_cons_skel/2, c_tuple/1, c_tuple_skel/1, fold_literal/1, is_literal/1.
See also: c_alias/2.
See also: c_apply/2.
See also: c_binary/1.
Equivalent to update_c_bitstr(Node, Value, Size, abstract(1), Type, Flags).
See also: c_bitstr/5, update_c_bitstr/5.
See also: c_call/3.
See also: c_case/2.
See also: c_catch/1.
See also: c_clause/3.
See also: c_cons/2.
See also: c_cons_skel/2.
See also: c_fun/2.
See also: c_let/3.
See also: c_letrec/2.
See also: c_module/4.
See also: c_primop/2.
See also: c_receive/3.
See also: c_seq/2.
See also: c_try/5.
See also: c_tuple/1.
See also: c_tuple_skel/1.
See also: c_values/1.
See also: c_var/1.
See also: make_data/2.
See also: make_data_skel/2.
Equivalent to update_list(Old, List, none).
Types
See also: make_list/2, update_list/2.
Creates a syntax tree with the given subtrees, and the same type and annotations as the Old node. This is equivalent to ann_make_tree(get_ann(Node), type(Node), Groups), but potentially more efficient.
See also: ann_make_tree/3, get_ann/1, type/1, update_tree/3.
Creates a syntax tree with the given type and subtrees, and the same annotations as the Old node. This is equivalent to ann_make_tree(get_ann(Node), Type, Groups), but potentially more efficient.
See also: ann_make_tree/3, get_ann/1, update_tree/2.
Returns the number of element subtrees of an abstract value list.
Note: This is equivalent to length(values_es(Node)), but potentially more efficient.
See also: c_values/1, values_es/1.
Returns the list of element subtrees of an abstract value list.
See also: c_values/1, values_arity/1.