![[Ericsson AB]](min_head.gif)
In this chapter, all valid Erlang expressions are listed. When writing Erlang programs, it is also allowed to use macro- and record expressions. However, these expressions are expanded during compilation and are in that sense not true Erlang expressions. Macro- and record expressions are covered in separate chapters: Macros and Records.
All subexpressions are evaluated before an expression itself is evaluated, unless explicitly stated otherwise. For example, consider the expression:
Expr1 + Expr2
Expr1 and Expr2, which are also expressions, are
evaluated first - in any order - before the addition is
performed.
Many of the operators can only be applied to arguments of a
certain type. For example, arithmetic operators can only be
applied to numbers. An argument of the wrong type will cause
a badarg run-time error.
The simplest form of expression is a term, that is an integer, float, atom, string, list or tuple. The return value is the term itself.
A variable is an expression. If a variable is bound to a value, the return value is this value. Unbound variables are only allowed in patterns.
Variables start with an uppercase letter or underscore (_) and may contain alphanumeric characters, underscore and @. Examples:
X
Name1
PhoneNumber
Phone_number
_
_Height
Variables are bound to values using pattern matching. Erlang uses single assignment, a variable can only be bound once.
The anonymous variable is denoted by underscore (_) and can be used when a variable is required but its value can be ignored. Example:
[H|_] = [1,2,3]
Variables starting with underscore (_), for example
_Height, are normal variables, not anonymous. They are
however ignored by the compiler in the sense that they will not
generate any warnings for unused variables. Example: The following
code
member(_, []) ->
[].
can be rewritten to be more readable:
member(Elem, []) ->
[].
This will however cause a warning for an unused variable
Elem, if the code is compiled with the flag
warn_unused_vars set. Instead, the code can be rewritten
to:
member(_Elem, []) ->
[].
Note that since variables starting with an underscore are not anonymous, this will match:
{_,_} = {1,2}
But this will fail:
{_N,_N} = {1,2}
The scope for a variable is its function clause.
Variables bound in a branch of an if, case,
or receive expression must be bound in all branches
to have a value outside the expression, otherwise they
will be regarded as 'unsafe' outside the expression.
For the try expression introduced in
Erlang 5.4/OTP-R10B, variable scoping is limited so that
variables bound in the expression are always 'unsafe' outside
the expression. This will be improved.
A pattern has the same structure as a term but may contain unbound variables. Example:
Name1
[H|T]
{error,Reason}
Patterns are allowed in clause heads, case and
receive expressions, and match expressions.
If Pattern1 and Pattern2 are valid patterns,
then the following is also a valid pattern:
Pattern1 = Pattern2
When matched against a term, both Pattern1 and
Pattern2 will be matched against the term. The idea
behind this feature is to avoid reconstruction of terms.
Example:
f({connect,From,To,Number,Options}, To) ->
Signal = {connect,From,To,Number,Options},
...;
f(Signal, To) ->
ignore.
can instead be written as
f({connect,_,To,_,_} = Signal, To) ->
...;
f(Signal, To) ->
ignore.
When matching strings, the following is a valid pattern:
f("prefix" ++ Str) -> ...
This is syntactic sugar for the equivalent, but harder to read
f([$p,$r,$e,$f,$i,$x | Str]) -> ...
An arithmetic expression can be used within a pattern, if it uses only numeric or bitwise operators, and if its value can be evaluated to a constant at compile-time. Example:
case {Value, Result} of
{?THRESHOLD+1, ok} -> ...
This feature was added in Erlang 5.0/OTP R7.
Expr1 = Expr2
Matches Expr1, a pattern, against Expr2.
If the matching succeeds, any unbound variable in the pattern
becomes bound and the value of Expr2 is returned.
If the matching fails, a badmatch run-time error will
occur.
Examples:
1> {A, B} = {answer, 42}.
{answer,42}
2> A.
answer
3> {C, D} = [1, 2].
** exited: {{badmatch,[1,2]},[{erl_eval,expr,3}]} **
ExprF(Expr1,...,ExprN)
ExprM:ExprF(Expr1,...,ExprN)
ExprM should evalutate to a module name and ExprF
to a function name or a fun.
When including the module name, the function is said to be called by using the fully qualified function name. This is often referred to as a remote or external function call. Example:
lists:keysearch(Name, 1, List)
The module name can be omitted, if ExprF evaluates to
the name of a local function, an imported function, or an
auto-imported BIF. Then the function is said to be called by
using the implicitly qualified function name.
Examples:
handle(Msg, State)
spawn(m, init, [])
To avoid possible ambiguities, the fully qualified function name must be used when calling a function with the same name as a BIF, and the compiler does not allow defining a function with the same name as an imported function.
Note that when calling a local function, there is a difference between using the implicitly or fully qualified function name, as the latter always refer to the latest version of the module. See Compilation and Code Loading.
If ExprF evaluates to a fun, only the format
ExprF(Expr1,...,ExprN) is correct. Example:
Fun1 = fun(X) -> X+1 end
Fun1(3)
=> 4
Fun2 = {lists,append}
Fun2([1,2],[3,4])
=> [1,2,3,4]
See also the chapter about Function Evaluation.
if
GuardSeq1 ->
Body1;
...;
GuardSeqN ->
BodyN
end
The branches of an if-expression are scanned sequentially
until a guard sequence GuardSeq which evaluates to true is
found. Then the corresponding Body (sequence of expressions
separated by ',') is evaluated.
The return value of Body is the return value of
the if expression.
If no guard sequence is true, an if_clause run-time error
will occur. If necessary, the guard expression true can be
used in the last branch, as that guard sequence is always true.
Example:
is_greater_than(X, Y) ->
if
X>Y ->
true;
true -> % works as an 'else' branch
false
end
case Expr of
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
end
The expression Expr is evaluated and the patterns
Pattern are sequentially matched against the result. If a
match succeeds and the optional guard sequence GuardSeq is
true, the corresponding Body is evaluated.
The return value of Body is the return value of
the case expression.
If there is no matching pattern with a true guard sequence,
a case_clause run-time error will occur.
Example:
is_valid_signal(Signal) ->
case Signal of
{signal, _What, _From, _To} ->
true;
{signal, _What, _To} ->
true;
_Else ->
false
end.
Expr1 ! Expr2
Sends the value of Expr2 as a message to the process
specified by Expr1. The value of Expr2 is also
the return value of the expression.
Expr1 must evaluate to a pid, a registered name (atom) or
a tuple {Name,Node}, where Name is an atom and
Node a node name, also an atom.
Expr1 evaluates to a name, but this name is not
registered, a badarg run-time error will occur.
Expr1
evaluates to a tuple {Name,Node} (or a pid located at
another node), also never fails.
receive
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
end
Receives messages sent to the process using the send operator
(!). The patterns Pattern are sequentially matched
against the first message in time order in the mailbox, then
the second, and so on. If a match succeeds and the optional
guard sequence GuardSeq is true, the corresponding
Body is evaluated. The matching message is consumed, that
is removed from the mailbox, while any other messages in
the mailbox remain unchanged.
The return value of Body is the return value of
the receive expression.
receive never fails. Execution is suspended, possibly
indefinitely, until a message arrives that does match one of
the patterns and with a true guard sequence.
Example:
wait_for_onhook() ->
receive
onhook ->
disconnect(),
idle();
{connect, B} ->
B ! {busy, self()},
wait_for_onhook()
end.
It is possible to augment the receive expression with a
timeout:
receive
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
after
ExprT ->
BodyT
end
ExprT should evaluate to an integer. The highest allowed
value is 16#ffffffff, that is, the value must fit in 32 bits.
receive..after works exactly as receive, except
that if no matching message has arrived within ExprT
milliseconds, then BodyT is evaluated instead and its
return value becomes the return value of the receive..after
expression.
Example:
wait_for_onhook() ->
receive
onhook ->
disconnect(),
idle();
{connect, B} ->
B ! {busy, self()},
wait_for_onhook()
after
60000 ->
disconnect(),
error()
end.
It is legal to use a receive..after expression with no
branches:
receive
after
ExprT ->
BodyT
end
This construction will not consume any messages, only suspend
execution in the process for ExprT milliseconds and can be
used to implement simple timers.
Example:
timer() ->
spawn(m, timer, [self()]).
timer(Pid) ->
receive
after
5000 ->
Pid ! timeout
end.
There are two special cases for the timeout value ExprT:
infinity
Expr1 op Expr2
| op | Description |
| == | equal to |
| /= | not equal to |
| =< | less than or equal to |
| < | less than |
| >= | greater than or equal to |
| > | greater than |
| =:= | exactly equal to |
| =/= | exactly not equal to |
The arguments may be of different data types. The following order is defined:
number < atom < reference < fun < port < pid < tuple < list < binary
Lists are compared element by element. Tuples are ordered by size, two tuples with the same size are compared element by element.
All comparison operators except =:= and =/= are of type coerce: When comparing an integer and a float, the integer is first converted to a float. In the case of =:= and =/=, there is no type conversion.
Returns the Boolean value of the expression, true or
false.
Examples:
1> 1==1.0.
true
2> 1=:=1.0.
false
3> 1 > a.
false
op Expr
Expr1 op Expr2
| op | Description | Argument type |
| + | unary + | number |
| - | unary - | number |
| + | number | |
| - | number | |
| * | number | |
| / | floating point division | number |
| bnot | unary bitwise not | integer |
| div | integer division | integer |
| rem | integer remainder of X/Y | integer |
| band | bitwise and | integer |
| bor | bitwise or | integer |
| bxor | arithmetic bitwise xor | integer |
| bsl | arithmetic bitshift left | integer |
| bsr | bitshift right | integer |
Examples:
1> +1.
1
2> -1.
-1
3> 1+1.
2
4> 4/2.
2.00000
5> 5 div 2.
2
6> 5 rem 2.
1
7> 2#10 band 2#01.
0
8> 2#10 bor 2#01.
3
op Expr
Expr1 op Expr2
| op | Description |
| not | unary logical not |
| and | logical and |
| or | logical or |
| xor | logical xor |
Examples:
1> not true.
false
2> true and false.
false
3> true xor false.
true
Expr1 orelse Expr2
Expr1 andalso Expr2
Boolean expressions where Expr2 is evaluated only if
necessary. That is, Expr2 is evaluated only if Expr1
evaluates to false in an orelse expression, or only
if Expr1 evaluates to true in an andalso
expression. Returns the Boolean value of the expression, that is
true or false.
As of Erlang 5.5/OTP R11B, short-circuit boolean expressions are allowed in guards. In guards, however, evaluation is always short-circuited since guard tests are known to be free of side effects.
Example 1:
case A >= -1.0 andalso math:sqrt(A+1) > B of
This will work even if A is less than -1.0,
since in that case, math:sqrt/1 is never evaluated.
Example 2:
OnlyOne = is_atom(L) orelse
(is_list(L) andalso length(L) == 1),
This feature was added in Erlang 5.1/OTP R8.
Expr1 ++ Expr2
Expr1 -- Expr2
The list concatenation operator ++ appends its second
argument to its first and returns the resulting list.
The list subtraction operator -- produces a list which
is a copy of the first argument, subjected to the following
procedure: for each element in the second argument, the first
occurrence of this element (if any) is removed.
Example:
1> [1,2,3]++[4,5].
[1,2,3,4,5]
2> [1,2,3,2,1,2]--[2,1,2].
[3,1,2]
<<>>
<<E1,...,En>>
Each element Ei specifies a segment of
the binary. Each element Ei is a value, followed by an
optional size expression and an optional type
specifier list.
Ei = Value |
Value:Size |
Value/TypeSpecifierList |
Value:Size/TypeSpecifierList
Used in a binary construction, Value is an expression
which should evaluate to an integer, float or binary.
If the expression is something else than a single literal or
variable, it should be enclosed in parenthesis.
Used in a binary matching, Value must be a variable, or
an integer, float or string.
Note that, for example, using a string literal as in
<<"abc">> is syntactic sugar for <<$a,$b,$c>>.
Used in a binary construction, Size is an expression
similar to Value, which should evaluate to an integer.
Used in a binary matching, Size must be an integer, or
a variable bound to an integer.
The value of Size specifies the size of the segment in
units (see below). The default value depends on the type (see
below). For integer it is 8, for float it is 64,
for binary it is all of the binary. In matching, this
default value is only valid for the very last element. All other
binary elements in the matching must have a size specification.
TypeSpecifierList is a list of type specifiers, in any
order, separated by hyphens (-). Default values are used for any
omitted type specifiers.
Type = integer | float |
binary
integer.
Signedness = signed | unsigned
unsigned.
Endianness = big | little |
native
big.
Unit = unit:IntegerLiteral
integer
and float, and to 8 for binary.
The value of Size multiplied with the unit gives
the number of bits for the segment. Each segment can consist of
zero or more bits, but the total number of bits must be divisible
by 8, or a badarg run-time error will occur. Also, a
segment of type binary must have a size evenly divisble
by 8.
Examples:
1> Bin1 = <<1,17,42>>.
<<1,17,42>>
2> Bin2 = <<"abc">>.
<<97,98,99>>
3> Bin3 = <<1,17,42:16>>.
<<1,17,0,42>>
4> <<A,B,C:16>> = <<1,17,42:16>>.
<<1,17,0,42>>
5> C.
42
6> <<D:16,E,F>> = <<1,17,42:16>>.
<<1,17,0,42>>
7> D.
273
8> F.
42
9> <<G,H/binary>> = <<1,17,42:16>>.
<<1,17,0,42>>
10> H.
<<17,0,42>>
Note that binary patterns cannot be nested.
Note also that "B=<<1>>" is interpreted as
"B =< <1>>" which is a syntax error. The correct way is
to write a space after '=': "B= <<1>>.
More examples can be found in Programming Examples.
fun
(Pattern11,...,Pattern1N) [when GuardSeq1] ->
Body1;
...;
(PatternK1,...,PatternKN) [when GuardSeqK] ->
BodyK
end
A fun expression begins with the keyword fun and ends
with the keyword end. Between them should be a function
declaration, similar to a
regular function
declaration, except that no function name is
specified.
Variables in a fun head shadow variables in the function clause surrounding the fun expression, and variables bound in a fun body are local to the fun body.
The return value of the expression is the resulting fun.
Examples:
1> Fun1 = fun (X) -> X+1 end.
#Fun<erl_eval.6.39074546>
2> Fun1(2).
3
3> Fun2 = fun (X) when X>=5 -> gt; (X) -> lt end.
#Fun<erl_eval.6.39074546>
4> Fun2(7).
gt
The following fun expressions are also allowed:
fun Name/Arity
fun Module:Name/Arity
In Name/Arity, Name is an atom and Arity is an integer.
Name/Arity must specify an existing local function. The expression is
syntactic sugar for:
fun (Arg1,...,ArgN) -> Name(Arg1,...,ArgN) end
In Module:Name/Arity, Module and Name are atoms
and Arity is an integer.
A fun defined in this way will refer to the function Name
with arity Arity in the latest version of module Module.
When applied to a number N of arguments, a tuple
{Module,FunctionName} is interpreted as a fun, referring
to the function FunctionName with arity N in the module
Module. The function must be exported.
This usage is deprecated.
See Function Calls for an example.
More examples can be found in Programming Examples.
catch Expr
Returns the value of Expr unless an exception
occurs during the evaluation. In that case, the exception is
caught. For exceptions of class error,
that is run-time errors: {'EXIT',{Reason,Stack}}
is returned. For exceptions of class exit, that is
the code called exit(Term): {'EXIT',Term} is returned.
For exceptions of class throw, that is
the code called throw(Term): Term is returned.
Reason depends on the type of error that occurred, and
Stack is the stack of recent function calls, see
Errors and Error
Handling.
Examples:
1> catch 1+2.
3
2> catch 1+a.
{'EXIT',{badarith,[...]}}
Note that catch has low precedence and catch
subexpressions often needs to be enclosed in a block
expression or in parenthesis:
3> A = catch 1+2.
** 1: syntax error before: 'catch' **
4> A = (catch 1+2).
3
The BIF throw(Any) can be used for non-local return from
a function. It must be evaluated within a catch, which will
return the value Any. Example:
5> catch throw(hello).
hello
If throw/1 is not evaluated within a catch, a
nocatch run-time error will occur.
try Exprs
catch
[Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
ExceptionBody1;
[ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
ExceptionBodyN
end
This is an enhancement of
catch that appeared in
Erlang 5.4/OTP-R10B. It gives the possibility do distinguish
between different exception classes, and to choose to handle only
the desired ones, passing the others on to an enclosing
try or catch or to default error handling.
Note that although the keyword catch is used in
the try expression, there is not a catch expression
within the try expression.
Returns the value of Exprs (a sequence of expressions
Expr1, ..., ExprN) unless an exception occurs during
the evaluation. In that case the exception is caught and
the patterns ExceptionPattern with the right exception
class Class are sequentially matched against the caught
exception. An omitted Class is shorthand for throw.
If a match succeeds and the optional guard sequence
ExceptionGuardSeq is true, the corresponding
ExceptionBody is evaluated to become the return value.
If an exception occurs during evaluation of Exprs but
there is no matching ExceptionPattern of the right
Class with a true guard sequence, the exception is passed
on as if Exprs had not been enclosed in a try
expression.
If an exception occurs during evaluation of ExceptionBody
it is not caught.
The try expression can have an of
section:
try Exprs of
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
catch
[Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
ExceptionBody1;
...;
[ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
ExceptionBodyN
end
If the evaluation of Exprs succeeds without an exception,
the patterns Pattern are sequentially matched against
the result in the same way as for a
case expression, except that if
the matching fails, a try_clause run-time error will occur.
An exception occuring during the evaluation of Body is
not caught.
The try expression can also be augmented with an
after section, intended to be used for cleanup with side
effects:
try Exprs of
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
catch
[Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
ExceptionBody1;
...;
[ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
ExceptionBodyN
after
AfterBody
end
AfterBody is evaluated after either Body or
ExceptionBody no matter which one. The evaluated value of
AfterBody is lost; the return value of the try
expression is the same with an after section as without.
Even if an exception occurs during evaluation of Body or
ExceptionBody, AfterBody is evaluated. In this case
the exception is passed on after AfterBody has been
evaluated, so the exception from the try expression is
the same with an after section as without.
If an exception occurs during evaluation of AfterBody
itself it is not caught, so if AfterBody is evaluated after
an exception in Exprs, Body or ExceptionBody,
that exception is lost and masked by the exception in
AfterBody.
The of, catch and after sections are all
optional, as long as there is at least a catch or an
after section, so the following are valid try
expressions:
try Exprs of
Pattern when GuardSeq ->
Body
after
AfterBody
end
try Exprs
catch
ExpressionPattern ->
ExpressionBody
after
AfterBody
end
try Exprs after AfterBody end
Example of using after, this code will close the file
even in the event of exceptions in file:read/2 or in
binary_to_term/1, and exceptions will be the same as
without the try...after...end expression:
termize_file(Name) ->
{ok,F} = file:open(Name, [read,binary]),
try
{ok,Bin} = file:read(F, 1024*1024),
binary_to_term(Bin)
after
file:close(F)
end.
Example: Using try to emulate catch Expr.
try Expr
catch
throw:Term -> Term;
exit:Reason -> {'EXIT',Reason}
error:Reason -> {'EXIT',{Reason,erlang:get_stacktrace()}}
end
(Expr)
Parenthesized expressions are useful to override operator precedences, for example in arithmethic expressions:
1> 1 + 2 * 3.
7
2> (1 + 2) * 3.
9
begin
Expr1,
...,
ExprN
end
Block expressions provide a way to group a sequence of
expressions, similar to a clause body. The return value is
the value of the last expression ExprN.
List comprehensions are a feature of many modern functional programming languages. Subject to certain rules, they provide a succinct notation for generating elements in a list.
List comprehensions are analogous to set comprehensions in
Zermelo-Frankel set theory and are called ZF expressions in
Miranda. They are analogous to the setof and
findall predicates in Prolog.
List comprehensions are written with the following syntax:
[Expr || Qualifier1,...,QualifierN]
Expr is an arbitrary expression, and each
Qualifier is either a generator or a filter.
Pattern <- ListExpr.ListExpr must be an expression which evaluates to a
list of terms.
true or false.
The variables in the generator patterns shadow variables in the function clause surrounding the list comprehensions.
A list comprehension returns a list, where the elements are
the result of evaluating Expr for each combination of
generator list elements for which all filters are true.
Example:
1> [X*2 || X <- [1,2,3]].
[2,4,6]
More examples can be found in Programming Examples.
A guard sequence is a sequence of guards, separated
by semicolon (;). The guard sequence is true if at least one of
the guards is true.
Guard1;...;GuardK
A guard is a sequence of guard expressions, separated
by comma (,). The guard is true if all guard expressions
evaluate to true.
GuardExpr1,...,GuardExprN
The set of valid guard expressions (sometimes called guard tests) is a subset of the set of valid Erlang expressions. The reason for restricting the set of valid expressions is that evaluation of a guard expression must be guaranteed to be free of side effects. Valid guard expressions are:
true,
is_atom/1
|
is_binary/1
|
is_constant/1
|
is_float/1
|
is_function/1
|
is_function/2
|
is_integer/1
|
is_list/1
|
is_number/1
|
is_pid/1
|
is_port/1
|
is_reference/1
|
is_tuple/1
|
is_record/2
|
is_record/3
|
Note that each type test BIF has an older equivalent, without
the is_ prefix. These old BIFs are retained for backwards
compatibility only and should not be used in new code. They are
also only allowed at top level. For example, they are not allowed
in boolean expressions in guards.
abs(Number)
|
element(N, Tuple)
|
float(Term)
|
hd(List)
|
length(List)
|
node()
|
node(Pid|Ref|Port)
|
round(Number)
|
self()
|
size(Tuple|Binary)
|
tl(List)
|
trunc(Number)
|
Operator precedence in falling priority:
| : | |
| # | |
| Unary + - bnot not | |
| / * div rem band and | Left associative |
| + - bor bxor bsl bsr or xor | Left associative |
| ++ -- | Right associative |
| == /= =< < >= > =:= =/= | - |
| andalso | |
| orelse | |
| = ! | Right associative |
| catch |
When evaluating an expression, the operator with the highest priority is evaluated first. Operators with the same priority are evaluated according to their associativity. Example: The left associative arithmethic operators are evaluated left to right:
6 + 5 * 4 - 3 / 2 evaluates to
6 + 20 - 1.5 evaluates to
26 - 1.5 evaluates to
24.5