cerl

cerl

cerl
Core Erlang abstract syntax trees.

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.

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.

Appends Annotations to the list of user annotations of Node.

Note: this is equivalent to set_ann(Node, Annotations ++ get_ann(Node)), but potentially more efficient.

See also: get_ann/1, set_ann/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 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 operator subtree of an abstract function application.

See also: 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 printname of an abstract atom.

See also: c_atom/1.

Returns the value represented by an abstract atom.

See also: c_atom/1.

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 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.

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 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 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 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 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 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 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.

Returns the module subtree of an abstract inter-module call.

See also: c_call/3.

Returns the name subtree of an abstract inter-module call.

See also: c_call/3.

Returns the argument subtree of an abstract case-expression.

See also: c_case/2.

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 value represented by an abstract character literal.

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 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.

Copies the list of user annotations from Source to Target.

Note: this is equivalent to set_ann(Target, get_ann(Source)), but potentially more efficient.

See also: get_ann/1, set_ann/2.

Returns the number of subtrees of a data constructor node. This is equivalent to length(data_es(Node)), but potentially more efficient.

See also: data_es/1, is_data/1.

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.

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 numeral string represented by a floating-point literal node.

See also: c_float/1.

Returns the value represented by a floating-point literal node.

See also: c_float/1.

Returns the arity part of an abstract function name variable.

See also: c_fname/2, fname_id/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.

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 body subtree of an abstract fun-expression.

See also: c_fun/2.

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 the numeral string represented by an integer literal node.

See also: c_int/1.

Returns the value represented by an integer literal node.

See also: c_int/1.

Returns true if Node is an abstract pattern alias, otherwise false.

See also: c_alias/2.

Returns true if Node is an abstract function application, otherwise false.

See also: c_apply/2.

Returns true if Node represents an atom literal, otherwise false.

See also: c_atom/1.

Returns true if Node is an abstract binary-template; otherwise false.

See also: c_binary/1.

Returns true if Node is an abstract bit-string template; otherwise false.

See also: c_bitstr/5.

Returns true if Node is an abstract inter-module call expression; otherwise false.

See also: c_call/3.

Returns true if Node is an abstract case-expression; otherwise false.

See also: c_case/2.

Returns true if Node is an abstract catch-expression, otherwise false.

See also: c_catch/1.

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 clause, otherwise false.

See also: c_clause/3.

Returns true if Node is an abstract list constructor, otherwise false.

Returns true if Node represents a floating-point literal, otherwise false.

See also: c_float/1.

Returns true if Node is an abstract fun-expression, otherwise false.

See also: c_fun/2.

Returns true if Node represents an integer literal, otherwise false.

See also: c_int/1.

Returns true if Node is an abstract let-expression, otherwise false.

See also: c_let/3.

Returns true if Node is an abstract letrec-expression, otherwise false.

See also: c_letrec/2.

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 map constructor, otherwise false.

Returns true if Node is an abstract module definition, otherwise false.

See also: type/1.

Returns true if Node is an abstract empty list, otherwise false.

Returns true if Node is an abstract primitive operation call, otherwise false.

See also: c_primop/2.

Returns true if Node is an abstract receive-expression, otherwise false.

See also: c_receive/3.

Returns true if Node is an abstract sequencing expression, otherwise false.

See also: c_seq/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 is an abstract try-expression, otherwise false.

See also: c_try/5.

Returns true if Node is an abstract tuple, otherwise false.

See also: c_tuple/1.

Returns true if Node is an abstract value list; otherwise false.

See also: c_values/1.

Returns true if Node is an abstract variable, otherwise false.

See also: c_var/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 argument subtree of an abstract let-expression.

See also: c_let/3.

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 body subtree of an abstract let-expression.

See also: c_let/3.

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 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 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 exports 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 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.

Returns the list of clause subtrees of an abstract receive-expression.

See also: c_receive/3.

Returns the argument subtree of an abstract sequencing expression.

See also: c_seq/2.

Returns the body subtree of an abstract sequencing expression.

See also: c_seq/2.

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 value represented by an abstract string literal.

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 expression subtree of an abstract try-expression.

See also: c_try/5.

Returns the success body subtree of an abstract try-expression.

See also: c_try/5.

Returns the list of exception variable subtrees of an abstract try-expression.

See also: c_try/5.

Returns the exception body subtree of an abstract try-expression.

See also: c_try/5.

Returns the list of success variable subtrees of an abstract try-expression.

See also: c_try/5.

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.

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.

Richard Carlsson carlsson.richard@gmail.com