File: expressions.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
links: PTS
area: main
in suites: etch, etch-m68k
size: 23,284 kB
ctags: 10,724
sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (1853 lines) | stat: -rw-r--r-- 44,433 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>Expressions</TITLE>
  <SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="6"><!-- Empty --></A>
<H2>6 Expressions</H2>

<P>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: <A HREF="macros.html">Macros</A> and
<A HREF="records.html">Records</A>.<A NAME="6.1"><!-- Empty --></A>
<H3>6.1 Expression Evaluation</H3>

<P>All subexpressions are evaluated before an expression itself is
evaluated, unless explicitly stated otherwise. For example,
consider the expression:
<PRE>
Expr1 + Expr2
    
</PRE>

<P><CODE>Expr1</CODE> and <CODE>Expr2</CODE>, which are also expressions, are
evaluated first - in any order - before the addition is
performed.

<P>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 <CODE>badarg</CODE> run-time error.<A NAME="term"><!-- Empty --></A><A NAME="6.2"><!-- Empty --></A>
<H3>6.2 Terms</H3>

<P>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 NAME="6.3"><!-- Empty --></A>
<H3>6.3 Variables</H3>

<P>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.
<P>Variables start with an uppercase letter or underscore (_)
and may contain alphanumeric characters, underscore and @.
Examples:
<PRE>
X
Name1
PhoneNumber
Phone_number
_
_Height
    
</PRE>

<P>Variables are bound to values using
<A HREF="patterns.html">pattern matching</A>. Erlang
uses <STRONG>single assignment</STRONG>, a variable can only be bound
once.
<P>The <STRONG>anonymous variable</STRONG> is denoted by underscore (_) and
can be used when a variable is required but its value can be
ignored. Example:
<PRE>
[H|_] = [1,2,3]
    
</PRE>

<P>Variables starting with underscore (_), for example
<CODE>_Height</CODE>, 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
<PRE>
member(_, []) -&#62;
    [].
    
</PRE>

<P>can be rewritten to be more readable:
<PRE>
member(Elem, []) -&#62;
    [].
    
</PRE>

<P>This will however cause a warning for an unused variable
<CODE>Elem</CODE>, if the code is compiled with the flag
<CODE>warn_unused_vars</CODE> set. Instead, the code can be rewritten
to:
<PRE>
member(_Elem, []) -&#62;
    [].
    
</PRE>

<P>Note that since variables starting with an underscore are
not anonymous, this will match:
<PRE>
{_,_} = {1,2}
    
</PRE>

<P>But this will fail:
<PRE>
{_N,_N} = {1,2}
    
</PRE>

<P>The scope for a variable is its function clause.
Variables bound in a branch of an <CODE>if</CODE>, <CODE>case</CODE>, 
or <CODE>receive</CODE> expression must be bound in all branches 
to have a value outside the expression, otherwise they
will be regarded as 'unsafe' outside the expression.
<P>For the <CODE>try</CODE> 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 NAME="pattern"><!-- Empty --></A><A NAME="6.4"><!-- Empty --></A>
<H3>6.4 Patterns</H3>

<P>A pattern has the same structure as a term but may contain
unbound variables. Example:
<PRE>
Name1
[H|T]
{error,Reason}
    
</PRE>

<P>Patterns are allowed in clause heads, <CODE>case</CODE> and
<CODE>receive</CODE> expressions, and match expressions.<A NAME="6.4.1"><!-- Empty --></A>
<H4>6.4.1 Match Operator = in Patterns</H4>

<P>If <CODE>Pattern1</CODE> and <CODE>Pattern2</CODE> are valid patterns,
        then the following is also a valid pattern:
<PRE>
Pattern1 = Pattern2
      
</PRE>

<P>When matched against a term, both <CODE>Pattern1</CODE> and
        <CODE>Pattern2</CODE> will be matched against the term. The idea
        behind this feature is to avoid reconstruction of terms.
        Example:
<PRE>
f({connect,From,To,Number,Options}, To) -&#62;
    Signal = {connect,From,To,Number,Options},
    ...;
f(Signal, To) -&#62;
    ignore.
      
</PRE>

<P>can instead be written as
<PRE>
f({connect,_,To,_,_} = Signal, To) -&#62;
    ...;
f(Signal, To) -&#62;
    ignore.
      
</PRE>
<A NAME="6.4.2"><!-- Empty --></A>
<H4>6.4.2 String Prefix in Patterns</H4>

<P>When matching strings, the following is a valid pattern:
<PRE>
f(&#34;prefix&#34; ++ Str) -&#62; ...
      
</PRE>

<P>This is syntactic sugar for the equivalent, but harder to
        read
<PRE>
f([$p,$r,$e,$f,$i,$x | Str]) -&#62; ...
      
</PRE>
<A NAME="6.4.3"><!-- Empty --></A>
<H4>6.4.3 Expressions in Patterns</H4>

<P>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:
<PRE>
case {Value, Result} of
    {?THRESHOLD+1, ok} -&#62; ...
      
</PRE>

<P>This feature was added in Erlang 5.0/OTP R7.<A NAME="6.5"><!-- Empty --></A>
<H3>6.5 Match</H3>

<PRE>
Expr1 = Expr2
    
</PRE>

<P>Matches <CODE>Expr1</CODE>, a pattern, against <CODE>Expr2</CODE>.
If the matching succeeds, any unbound variable in the pattern
becomes bound and the value of <CODE>Expr2</CODE> is returned.
<P>If the matching fails, a <CODE>badmatch</CODE> run-time error will
occur.
<P>Examples:
<PRE>
1&#62; <STRONG>{A, B} = {answer, 42}.</STRONG>
{answer,42}
2&#62; <STRONG>A.</STRONG>
answer
3&#62; <STRONG>{C, D} = [1, 2].</STRONG>
** exited: {{badmatch,[1,2]},[{erl_eval,expr,3}]} **
    
</PRE>
<A NAME="calls"><!-- Empty --></A><A NAME="6.6"><!-- Empty --></A>
<H3>6.6 Function Calls</H3>

<PRE>
ExprF(Expr1,...,ExprN)
ExprM:ExprF(Expr1,...,ExprN)
    
</PRE>

<P><CODE>ExprM</CODE> should evalutate to a module name and <CODE>ExprF</CODE>
to a function name or a fun.
<P>When including the module name, the function is said to be
called by using the <STRONG>fully qualified function name</STRONG>.
This is often referred to as a <STRONG>remote</STRONG> or <STRONG>external
        function call</STRONG>. Example:
<PRE>
lists:keysearch(Name, 1, List)
    
</PRE>

<P>The module name can be omitted, if <CODE>ExprF</CODE> 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 <STRONG>implicitly qualified function name</STRONG>.
Examples:
<PRE>
handle(Msg, State)
spawn(m, init, [])
    
</PRE>

<P>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.
<P>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
<A HREF="code.html">Compilation and Code Loading</A>.

<P>If <CODE>ExprF</CODE> evaluates to a fun, only the format
<CODE>ExprF(Expr1,...,ExprN)</CODE> is correct. Example:
<PRE>
Fun1 = fun(X) -&#62; X+1 end
Fun1(3)
=&#62; 4

Fun2 = {lists,append}
Fun2([1,2],[3,4])
=&#62; [1,2,3,4]
    
</PRE>

<P>See also the chapter about
<A HREF="functions.html#eval">Function Evaluation</A>.
<A NAME="6.7"><!-- Empty --></A>
<H3>6.7 If</H3>

<PRE>
if
    GuardSeq1 -&#62;
        Body1;
    ...;
    GuardSeqN -&#62;
        BodyN
end
    
</PRE>

<P>The branches of an <CODE>if</CODE>-expression are scanned sequentially
until a guard sequence <CODE>GuardSeq</CODE> which evaluates to true is
found. Then the corresponding <CODE>Body</CODE> (sequence of expressions
separated by ',') is evaluated.
<P>The return value of <CODE>Body</CODE> is the return value of
the <CODE>if</CODE> expression.
<P>If no guard sequence is true, an <CODE>if_clause</CODE> run-time error
will occur. If necessary, the guard expression <CODE>true</CODE> can be
used in the last branch, as that guard sequence is always true.

<P>Example:
<PRE>
is_greater_than(X, Y) -&#62;
    if
        X&#62;Y -&#62;
            true;
        true -&#62; % works as an 'else' branch
            false
    end
    
</PRE>
<A NAME="case"><!-- Empty --></A><A NAME="6.8"><!-- Empty --></A>
<H3>6.8 Case</H3>

<PRE>
case Expr of
    Pattern1 [when GuardSeq1] -&#62;
        Body1;
    ...;
    PatternN [when GuardSeqN] -&#62;
        BodyN
end
    
</PRE>

<P>The expression <CODE>Expr</CODE> is evaluated and the patterns
<CODE>Pattern</CODE> are sequentially matched against the result. If a
match succeeds and the optional guard sequence <CODE>GuardSeq</CODE> is
true, the corresponding <CODE>Body</CODE> is evaluated.
<P>The return value of <CODE>Body</CODE> is the return value of
the <CODE>case</CODE> expression.
<P>If there is no matching pattern with a true guard sequence,
a <CODE>case_clause</CODE> run-time error will occur.
<P>Example:
<PRE>
is_valid_signal(Signal) -&#62;
    case Signal of
        {signal, _What, _From, _To} -&#62;
            true;
        {signal, _What, _To} -&#62;
            true;
        _Else -&#62;
            false
    end.
    
</PRE>
<A NAME="send"><!-- Empty --></A><A NAME="6.9"><!-- Empty --></A>
<H3>6.9 Send</H3>

<PRE>
Expr1 ! Expr2
    
</PRE>

<P>Sends the value of <CODE>Expr2</CODE> as a message to the process
specified by <CODE>Expr1</CODE>. The value of <CODE>Expr2</CODE> is also
the return value of the expression.
<P><CODE>Expr1</CODE> must evaluate to a pid, a registered name (atom) or
a tuple <CODE>{Name,Node}</CODE>, where <CODE>Name</CODE> is an atom and
<CODE>Node</CODE> a node name, also an atom.
<P>
<UL>

<LI>
If <CODE>Expr1</CODE> evaluates to a name, but this name is not
        registered, a <CODE>badarg</CODE> run-time error will occur.
</LI>


<LI>
Sending a message to a pid never fails, even if the pid
        identifies a non-existing process.
</LI>


<LI>
Distributed message sending, that is if <CODE>Expr1</CODE>
        evaluates to a tuple <CODE>{Name,Node}</CODE> (or a pid located at
        another node), also never fails.
</LI>


</UL>
<A NAME="receive"><!-- Empty --></A><A NAME="6.10"><!-- Empty --></A>
<H3>6.10 Receive</H3>

<PRE>
receive
    Pattern1 [when GuardSeq1] -&#62;
        Body1;
    ...;
    PatternN [when GuardSeqN] -&#62;
        BodyN
end
    
</PRE>

<P>Receives messages sent to the process using the send operator
(!). The patterns <CODE>Pattern</CODE> 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 <CODE>GuardSeq</CODE> is true, the corresponding
<CODE>Body</CODE> is evaluated. The matching message is consumed, that
is removed from the mailbox, while any other messages in
the mailbox remain unchanged.
<P>The return value of <CODE>Body</CODE> is the return value of
the <CODE>receive</CODE> expression.
<P><CODE>receive</CODE> never fails. Execution is suspended, possibly
indefinitely, until a message arrives that does match one of
the patterns and with a true guard sequence. 
<P>Example:
<PRE>
wait_for_onhook() -&#62;
    receive
        onhook -&#62;
            disconnect(),
            idle();
        {connect, B} -&#62;
            B ! {busy, self()},
            wait_for_onhook()
    end.
    
</PRE>

<P>It is possible to augment the <CODE>receive</CODE> expression with a
timeout:
<PRE>
receive
    Pattern1 [when GuardSeq1] -&#62;
        Body1;
    ...;
    PatternN [when GuardSeqN] -&#62;
        BodyN
after
    ExprT -&#62;
        BodyT
end
    
</PRE>

<P><CODE>ExprT</CODE> should evaluate to an integer. The highest allowed
value is 16#ffffffff, that is, the value must fit in 32 bits.
<CODE>receive..after</CODE> works exactly as <CODE>receive</CODE>, except
that if no matching message has arrived within <CODE>ExprT</CODE>
milliseconds, then <CODE>BodyT</CODE> is evaluated instead and its
return value becomes the return value of the <CODE>receive..after</CODE>
expression.
<P>Example:
<PRE>
wait_for_onhook() -&#62;
    receive
        onhook -&#62;
            disconnect(),
            idle();
        {connect, B} -&#62;
            B ! {busy, self()},
            wait_for_onhook()
    after
        60000 -&#62;
            disconnect(),
            error()
    end.
    
</PRE>

<P>It is legal to use a <CODE>receive..after</CODE> expression with no
branches:
<PRE>
receive
after
    ExprT -&#62;
        BodyT
end
    
</PRE>

<P>This construction will not consume any messages, only suspend
execution in the process for <CODE>ExprT</CODE> milliseconds and can be
used to implement simple timers.
<P>Example:
<PRE>
timer() -&#62;
    spawn(m, timer, [self()]).

timer(Pid) -&#62;
    receive
    after
        5000 -&#62;
            Pid ! timeout
    end.
    
</PRE>

<P>There are two special cases for the timeout value <CODE>ExprT</CODE>:

<P>
<DL>

<DT>
<CODE>infinity</CODE>
</DT>

<DD>
The process should wait indefinitely for a matching message
        -- this is the same as not using a timeout. Can be
        useful for timeout values that are calculated at run-time.

</DD>

<DT>
0
</DT>

<DD>
If there is no matching message in the mailbox, the timeout
        will occur immediately.
</DD>

</DL>
<A NAME="6.11"><!-- Empty --></A>
<H3>6.11 Term Comparisons</H3>

<PRE>
Expr1 <STRONG>op</STRONG> Expr2
    
</PRE>

<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Term Comparison Operators.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>op</STRONG>
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>Description</STRONG>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
==
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
equal to
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
/=
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
not equal to
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
=&#60;
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
less than or equal to
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
&#60;
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
less than
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
&#62;=
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
greater than or equal to
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
&#62;
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
greater than
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
=:=
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
exactly equal to
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
=/=
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
exactly not equal to
    </TD>

  </TR>

</TABLE>
</CENTER>

<P>The arguments may be of different data types. The following
order is defined:
<PRE>
number &#60; atom &#60; reference &#60; fun &#60; port &#60; pid &#60; tuple &#60; list &#60; binary
    
</PRE>

<P>Lists are compared element by element. Tuples are ordered by
size, two tuples with the same size are compared element by
element.
<P>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.
<P>Returns the Boolean value of the expression, <CODE>true</CODE> or
<CODE>false</CODE>.
<P>Examples:
<PRE>
1&#62; <STRONG>1==1.0.</STRONG>
true
2&#62; <STRONG>1=:=1.0.</STRONG>
false
3&#62; <STRONG>1 &#62; a.</STRONG>
false
    
</PRE>
<A NAME="6.12"><!-- Empty --></A>
<H3>6.12 Arithmetic Expressions</H3>

<PRE>
<STRONG>op</STRONG> Expr
Expr1 <STRONG>op</STRONG> Expr2
    
</PRE>

<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Arithmetic Operators.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>op</STRONG>
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>Description</STRONG>
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>Argument type</STRONG>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
+
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
unary +
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
-
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
unary -
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
+
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
-
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
*
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
/
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
floating point division
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
number
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bnot
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
unary bitwise not
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
div
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer division
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
rem
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer remainder of X/Y
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
band
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bitwise and
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bor
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bitwise or
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bxor
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
arithmetic bitwise xor
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bsl
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
arithmetic bitshift left
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bsr
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
bitshift right
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
integer
    </TD>

  </TR>

</TABLE>
</CENTER>

<P>Examples:
<PRE>
1&#62; <STRONG>+1.</STRONG>
1
2&#62; <STRONG>-1.</STRONG>
-1
3&#62; <STRONG>1+1.</STRONG>
2
4&#62; <STRONG>4/2.</STRONG>
2.00000
5&#62; <STRONG>5 div 2.</STRONG>
2
6&#62; <STRONG>5 rem 2.</STRONG>
1
7&#62; <STRONG>2#10 band 2#01.</STRONG>
0
8&#62; <STRONG>2#10 bor 2#01.</STRONG>
3
    
</PRE>
<A NAME="6.13"><!-- Empty --></A>
<H3>6.13 Boolean Expressions</H3>

<PRE>
<STRONG>op</STRONG> Expr
Expr1 <STRONG>op</STRONG> Expr2
    
</PRE>

<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Logical Operators.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>op</STRONG>
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<STRONG>Description</STRONG>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
not
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
unary logical not
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
and
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
logical and
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
or
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
logical or
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
xor
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
logical xor
    </TD>

  </TR>

</TABLE>
</CENTER>

<P>Examples:
<PRE>
1&#62; <STRONG>not true.</STRONG>
false
2&#62; <STRONG>true and false.</STRONG>
false
3&#62; <STRONG>true xor false.</STRONG>
true
    
</PRE>
<A NAME="6.14"><!-- Empty --></A>
<H3>6.14 Short-Circuit Boolean Expressions</H3>

<PRE>
Expr1 orelse Expr2
Expr1 andalso Expr2
    
</PRE>

<P>Boolean expressions where <CODE>Expr2</CODE> is evaluated only if
necessary. That is, <CODE>Expr2</CODE> is evaluated only if <CODE>Expr1</CODE>
evaluates to <CODE>false</CODE> in an <CODE>orelse</CODE> expression, or only
if <CODE>Expr1</CODE> evaluates to <CODE>true</CODE> in an <CODE>andalso</CODE>
expression. Returns the Boolean value of the expression, that is
<CODE>true</CODE> or <CODE>false</CODE>.
<P>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.
<P>Example 1:
<PRE>
case A &#62;= -1.0 andalso math:sqrt(A+1) &#62; B of
    
</PRE>

<P>This will work even if <CODE>A</CODE> is less than <CODE>-1.0</CODE>,
since in that case, <CODE>math:sqrt/1</CODE> is never evaluated.
<P>Example 2:
<PRE>
OnlyOne = is_atom(L) orelse
         (is_list(L) andalso length(L) == 1),
    
</PRE>

<P>This feature was added in Erlang 5.1/OTP R8.<A NAME="6.15"><!-- Empty --></A>
<H3>6.15 List Operations</H3>

<PRE>
Expr1 ++ Expr2
Expr1 -- Expr2
    
</PRE>

<P>The list concatenation operator <CODE>++</CODE> appends its second
argument to its first and returns the resulting list.
<P>The list subtraction operator <CODE>--</CODE> 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.
<P>Example:
<PRE>
1&#62; <STRONG>[1,2,3]++[4,5].</STRONG>
[1,2,3,4,5]
2&#62; <STRONG>[1,2,3,2,1,2]--[2,1,2].</STRONG>
[3,1,2]
    
</PRE>
<A NAME="bit_syntax"><!-- Empty --></A><A NAME="6.16"><!-- Empty --></A>
<H3>6.16 Bit Syntax Expressions</H3>

<PRE>
&#60;&#60;&#62;&#62;
&#60;&#60;E1,...,En&#62;&#62;
    
</PRE>

<P>Each element <CODE>Ei</CODE> specifies a <STRONG>segment</STRONG> of
the binary. Each element <CODE>Ei</CODE> is a value, followed by an
optional <STRONG>size expression</STRONG> and an optional <STRONG>type
        specifier list</STRONG>.
<PRE>
Ei = Value |
     Value:Size |
     Value/TypeSpecifierList |
     Value:Size/TypeSpecifierList
    
</PRE>

<P>Used in a binary construction, <CODE>Value</CODE> 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.
<P>Used in a binary matching, <CODE>Value</CODE> must be a variable, or
an integer, float or string.
<P>Note that, for example, using a string literal as in
<CODE>&#60;&#60;&#34;abc&#34;&#62;&#62;</CODE> is syntactic sugar for <CODE>&#60;&#60;$a,$b,$c&#62;&#62;</CODE>.
<P>Used in a binary construction, <CODE>Size</CODE> is an expression
similar to <CODE>Value</CODE>, which should evaluate to an integer.
<P>Used in a binary matching, <CODE>Size</CODE> must be an integer, or
a variable bound to an integer.
<P>The value of <CODE>Size</CODE> specifies the size of the segment in
units (see below). The default value depends on the type (see
below). For <CODE>integer</CODE> it is 8, for <CODE>float</CODE> it is 64,
for <CODE>binary</CODE> 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.

<P><CODE>TypeSpecifierList</CODE> is a list of type specifiers, in any
order, separated by hyphens (-). Default values are used for any
omitted type specifiers.
<P>
<DL>

<DT>
<CODE>Type</CODE> = <CODE>integer</CODE> | <CODE>float</CODE> |
        <CODE>binary</CODE>
</DT>

<DD>
The default is <CODE>integer</CODE>.
</DD>

<DT>
<CODE>Signedness</CODE> = <CODE>signed</CODE> | <CODE>unsigned</CODE>
</DT>

<DD>
        Only matters for matching. The default is <CODE>unsigned</CODE>.

</DD>

<DT>
<CODE>Endianness</CODE> = <CODE>big</CODE> | <CODE>little</CODE> |
        <CODE>native</CODE>
</DT>

<DD>
        Native-endian means that the endian will be resolved at load
        time to be either big-endian or little-endian, depending on
        what is native for the CPU that the Erlang machine is run on.
        The default is <CODE>big</CODE>.

</DD>

<DT>
<CODE>Unit</CODE> = <CODE>unit:IntegerLiteral</CODE>
</DT>

<DD>
        The allowed range is 1..256. Defaults to 1 for <CODE>integer</CODE>
        and <CODE>float</CODE>, and to 8 for <CODE>binary</CODE>.

</DD>

</DL>

<P>The value of <CODE>Size</CODE> 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 <CODE>badarg</CODE> run-time error will occur. Also, a
segment of type <CODE>binary</CODE> must have a size evenly divisble
by 8.
<P>Examples:
<PRE>
1&#62; <STRONG>Bin1 = &#60;&#60;1,17,42&#62;&#62;.</STRONG>
&#60;&#60;1,17,42&#62;&#62;
2&#62; <STRONG>Bin2 = &#60;&#60;&#34;abc&#34;&#62;&#62;.</STRONG>
&#60;&#60;97,98,99&#62;&#62;
3&#62; <STRONG>Bin3 = &#60;&#60;1,17,42:16&#62;&#62;.</STRONG>
&#60;&#60;1,17,0,42&#62;&#62;
4&#62; <STRONG>&#60;&#60;A,B,C:16&#62;&#62; = &#60;&#60;1,17,42:16&#62;&#62;.</STRONG>
&#60;&#60;1,17,0,42&#62;&#62;
5&#62; <STRONG>C.</STRONG>
42
6&#62; <STRONG>&#60;&#60;D:16,E,F&#62;&#62; = &#60;&#60;1,17,42:16&#62;&#62;.</STRONG>
&#60;&#60;1,17,0,42&#62;&#62;
7&#62; <STRONG>D.</STRONG>
273
8&#62; <STRONG>F.</STRONG>
42
9&#62; <STRONG>&#60;&#60;G,H/binary&#62;&#62; = &#60;&#60;1,17,42:16&#62;&#62;.</STRONG>
&#60;&#60;1,17,0,42&#62;&#62;
10&#62; <STRONG>H.</STRONG>
&#60;&#60;17,0,42&#62;&#62;
    
</PRE>

<P>Note that binary patterns cannot be nested.
<P>Note also that &#34;<CODE>B=&#60;&#60;1&#62;&#62;</CODE>&#34; is interpreted as
&#34;<CODE>B =&#60; &#60;1&#62;&#62;</CODE>&#34; which is a syntax error. The correct way is
to write a space after '=': &#34;<CODE>B= &#60;&#60;1&#62;&#62;</CODE>.
<P>More examples can be found in <STRONG>Programming Examples</STRONG>.<A NAME="funs"><!-- Empty --></A><A NAME="6.17"><!-- Empty --></A>
<H3>6.17 Fun Expressions</H3>

<PRE>
fun
    (Pattern11,...,Pattern1N) [when GuardSeq1] -&#62;
        Body1;
    ...;
    (PatternK1,...,PatternKN) [when GuardSeqK] -&#62;
        BodyK
end
    
</PRE>

<P>A fun expression begins with the keyword <CODE>fun</CODE> and ends
with the keyword <CODE>end</CODE>. Between them should be a function
declaration, similar to a
<A HREF="functions.html#syntax">regular function
        declaration</A>, except that no function name is
specified.
<P>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.
<P>The return value of the expression is the resulting fun.
<P>Examples:
<PRE>
1&#62; <STRONG>Fun1 = fun (X) -&#62; X+1 end.</STRONG>
#Fun&#60;erl_eval.6.39074546&#62;
2&#62; <STRONG>Fun1(2).</STRONG>
3
3&#62; <STRONG>Fun2 = fun (X) when X&#62;=5 -&#62; gt; (X) -&#62; lt end.</STRONG>
#Fun&#60;erl_eval.6.39074546&#62;
4&#62; <STRONG>Fun2(7).</STRONG>
gt
    
</PRE>

<P>The following fun expressions are also allowed:
<PRE>
fun Name/Arity
fun Module:Name/Arity
    
</PRE>

<P>In <CODE>Name/Arity</CODE>, <CODE>Name</CODE> is an atom and <CODE>Arity</CODE> is an integer.
<CODE>Name/Arity</CODE> must specify an existing local function. The expression is
syntactic sugar for:
<PRE>
fun (Arg1,...,ArgN) -&#62; Name(Arg1,...,ArgN) end
    
</PRE>

<P>In <CODE>Module:Name/Arity</CODE>, <CODE>Module</CODE> and <CODE>Name</CODE> are atoms
and <CODE>Arity</CODE> is an integer.
A fun defined in this way will refer to the function <CODE>Name</CODE>
with arity <CODE>Arity</CODE> in the <STRONG>latest</STRONG> version of module <CODE>Module</CODE>.


<P>When applied to a number N of arguments, a tuple
<CODE>{Module,FunctionName}</CODE> is interpreted as a fun, referring
to the function <CODE>FunctionName</CODE> with arity N in the module
<CODE>Module</CODE>. The function must be exported.
<STRONG>This usage is deprecated.</STRONG> 
See <A HREF="#calls">Function Calls</A> for an example.

<P>More examples can be found in <STRONG>Programming Examples</STRONG>.<A NAME="catch"><!-- Empty --></A><A NAME="6.18"><!-- Empty --></A>
<H3>6.18 Catch and Throw</H3>

<PRE>
catch Expr
    
</PRE>

<P>Returns the value of <CODE>Expr</CODE> unless an exception
occurs during the evaluation. In that case, the exception is
caught. For exceptions of class <CODE>error</CODE>, 
that is run-time errors: <CODE>{'EXIT',{Reason,Stack}}</CODE> 
is returned. For exceptions of class <CODE>exit</CODE>, that is
the code called <CODE>exit(Term)</CODE>: <CODE>{'EXIT',Term}</CODE> is returned. 
For exceptions of class <CODE>throw</CODE>, that is
the code called <CODE>throw(Term)</CODE>: <CODE>Term</CODE> is returned.

<P><CODE>Reason</CODE> depends on the type of error that occurred, and
<CODE>Stack</CODE> is the stack of recent function calls, see
<A HREF="errors.html#exit_reasons">Errors and Error
        Handling</A>.
<P>Examples:
<P> 
<PRE>
1&#62; <STRONG>catch 1+2.</STRONG>
3
2&#62; <STRONG>catch 1+a.</STRONG>
{'EXIT',{badarith,[...]}}
    
</PRE>

<P>Note that <CODE>catch</CODE> has low precedence and catch
subexpressions often needs to be enclosed in a block
expression or in parenthesis:
<PRE>
3&#62; <STRONG>A = catch 1+2.</STRONG>
** 1: syntax error before: 'catch' **
4&#62; <STRONG>A = (catch 1+2).</STRONG>
3
    
</PRE>

<P>The BIF <CODE>throw(Any)</CODE> can be used for non-local return from
a function. It must be evaluated within a <CODE>catch</CODE>, which will
return the value <CODE>Any</CODE>. Example:
<PRE>
5&#62; <STRONG>catch throw(hello).</STRONG>
hello
    
</PRE>

<P>If <CODE>throw/1</CODE> is not evaluated within a catch, a
<CODE>nocatch</CODE> run-time error will occur.<A NAME="try"><!-- Empty --></A><A NAME="6.19"><!-- Empty --></A>
<H3>6.19 Try</H3>

<PRE>
try Expr
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -&#62;
        ExceptionBody1;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -&#62;
        ExceptionBodyN
end
    
</PRE>

<P>This is an enhancement of <A HREF="#catch">catch</A>
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 <CODE>try</CODE> or <CODE>catch</CODE> or to default
error handling.

<P>Note that althought the keyword <CODE>catch</CODE> is used in the
<CODE>try</CODE> expression there is not a <CODE>catch</CODE> expression
whithin the <CODE>try</CODE> expression.

<P>Returns the value of <CODE>Expr</CODE> unless an exception occurs
during the evaluation. In that case the exception is caught and the
patterns <CODE>ExceptionPattern</CODE> with the right exception
class <CODE>Class</CODE> are sequentially matched against the caught
exception. An omitted <CODE>Class</CODE> is shorthand for <CODE>throw</CODE>.
If a match succeeds and the optional guard
sequence <CODE>ExceptionGuardSeq</CODE> is true, the corresponding
<CODE>ExceptionBody</CODE> is evaluated to become the return value.

<P>If an exception occurs during evaluation of <CODE>Expr</CODE> but 
there is no matching <CODE>ExceptionPattern</CODE> of the right
<CODE>Class</CODE> with a true guard sequence, the exception is
passed on as if <CODE>Expr</CODE> had not been enclosed in a 
<CODE>try</CODE> expression.

<P>If an exception occurs during evaluation of 
<CODE>ExceptionBody</CODE> it is not caught.

<P>The <CODE>try</CODE> expression can have an <CODE>of</CODE>
section:


<PRE>
try Expr of
    Pattern1 [when GuardSeq1] -&#62;
        Body1;
    ...;
    PatternN [when GuardSeqN] -&#62;
        BodyN
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -&#62;
        ExceptionBody1;
    ...;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -&#62;
        ExceptionBodyN
end
    
</PRE>

<P>If the evaluation of <CODE>Expr</CODE> succedes without an
exception, the value is then matched against the
patterns <CODE>Pattern</CODE> in the same way as for a
<A HREF="#case">case</A> expression to
produce the return value, except that if the matching fails, 
a <CODE>try_clause</CODE> run-time error will occur.

<P>If an exception occurs during evaluation of
<CODE>Body</CODE> it is not caught.

<P>The <CODE>try</CODE> expression can also be augumented with an
<CODE>after</CODE> section, intended to be used for cleanup
with side effects:


<PRE>
try Expr of
    Pattern1 [when GuardSeq1] -&#62;
        Body1;
    ...;
    PatternN [when GuardSeqN] -&#62;
        BodyN
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -&#62;
        ExceptionBody1;
    ...;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -&#62;
        ExceptionBodyN
after
    AfterBody
end
    
</PRE>

<P>The <CODE>AfterBody</CODE> is evaluated after either 
<CODE>Body</CODE> or <CODE>ExceptionBody</CODE> no matter 
which one. The evaluated value of the <CODE>AfterBody</CODE> is
lost; the return value of the <CODE>try</CODE> expression is
the same with an <CODE>after</CODE> section as without.

<P>Even if an exception occurs during evaluation of
<CODE>Body</CODE> or <CODE>ExceptionBody</CODE>, the <CODE>AfterBody</CODE>
is evaluated. In this case the exception is caught
and passed on after the <CODE>AfterBody</CODE> has been
evaluated, so the exception from the <CODE>try</CODE> expression
is the same with an <CODE>after</CODE> section as without.

<P>If an exception occurs during evaluation of
<CODE>AfterBody</CODE> itself it is not caught, so if
the <CODE>AfterBody</CODE> is evaluated due to an exception
in <CODE>Expr</CODE>, <CODE>Body</CODE> or <CODE>ExceptionBody</CODE>, 
that exception is lost and masked by the new exception.

<P>The <CODE>of</CODE>, <CODE>catch</CODE> and <CODE>after</CODE> sections, 
are all optional in the <CODE>try</CODE> expression, as long as
there is at least a <CODE>catch</CODE> or an <CODE>after</CODE> section,
so the following are also valid <CODE>try</CODE> expressions:

<PRE>
try Expr of 
    Pattern when GuardSeq -&#62; 
        Body 
after 
    AfterBody 
end

try Expr 
catch 
    ExpressionPattern -&#62; 
        ExpressionBody
after
    AfterBody
end

try Expr after AfterBody end
</PRE>

<P>Example of using <CODE>after</CODE>, this code will close the file
even in the event of exceptions in <CODE>file:read/2</CODE>
or in <CODE>binary_to_term/1</CODE>, and exceptions will be the
same as without the <CODE>try</CODE>...<CODE>after</CODE>...<CODE>end</CODE>
expression:

<PRE>
termize_file(Name) -&#62;
    {ok,F} = file:open(Name, [read,binary]),
    try
        {ok,Bin} = file:read(F, 1024*1024),
        binary_to_term(Bin)
    after
        file:close(F)
    end.
</PRE>

<P>Example: Using <CODE>try</CODE> to emulate <CODE>catch Expr</CODE>
<PRE>
try Expr
catch
    throw:Term -&#62; Term;
    exit:Reason -&#62; {'EXIT',Reason}
    error:Reason -&#62; {'EXIT',{Reason,erlang:get_stacktrace()}}
end
</PRE>
<A NAME="6.20"><!-- Empty --></A>
<H3>6.20 Parenthesized Expressions</H3>

<PRE>
(Expr)
    
</PRE>

<P>Parenthesized expressions are useful to override
<A HREF="#prec">operator precedences</A>,
for example in arithmethic expressions:
<PRE>
1&#62; <STRONG>1 + 2 * 3.</STRONG>
7
2&#62; <STRONG>(1 + 2) * 3.</STRONG>
9
    
</PRE>
<A NAME="6.21"><!-- Empty --></A>
<H3>6.21 Block Expressions</H3>

<PRE>
begin
   Expr1,
   ...,
   ExprN
end
    
</PRE>

<P>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 <CODE>ExprN</CODE>.<A NAME="lcs"><!-- Empty --></A><A NAME="6.22"><!-- Empty --></A>
<H3>6.22 List Comprehensions</H3>

<P>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.
<P>List comprehensions are analogous to set comprehensions in
Zermelo-Frankel set theory and are called ZF expressions in
Miranda. They are analogous to the <CODE>setof</CODE> and
<CODE>findall</CODE> predicates in Prolog.
<P>List comprehensions are written with the following syntax:
<PRE>
[Expr || Qualifier1,...,QualifierN]
    
</PRE>

<P><CODE>Expr</CODE> is an arbitrary expression, and each
<CODE>Qualifier</CODE> is either a generator or a filter.
<P>
<UL>

<LI>
A <STRONG>generator</STRONG> is written as:<BR>

<CODE>Pattern &#60;- ListExpr</CODE>.<BR>

        <CODE>ListExpr</CODE> must be an expression which evaluates to a
        list of terms.
</LI>


<LI>
A <STRONG>filter</STRONG> is an expression which evaluates to
        <CODE>true</CODE> or <CODE>false</CODE>.
</LI>


</UL>

<P>The variables in the generator patterns shadow variables in
the function clause surrounding the list comprehensions.
<P>A list comprehension returns a list, where the elements are
the result of evaluating <CODE>Expr</CODE> for each combination of
generator list elements for which all filters are true.
<P>

<P>Example:
<PRE>
1&#62; <STRONG>[X*2 || X &#60;- [1,2,3]].</STRONG>
[2,4,6]
    
</PRE>

<P>More examples can be found in <STRONG>Programming Examples</STRONG>.<A NAME="guards"><!-- Empty --></A><A NAME="6.23"><!-- Empty --></A>
<H3>6.23 Guard Sequences</H3>

<P>A <STRONG>guard sequence</STRONG> is a sequence of guards, separated
by semicolon (;). The guard sequence is true if at least one of
the guards is true.<BR>

<CODE>Guard1;...;GuardK</CODE>
<P>A <STRONG>guard</STRONG> is a sequence of guard expressions, separated
by comma (,). The guard is true if all guard expressions
evaluate to <CODE>true</CODE>.<BR>

<CODE>GuardExpr1,...,GuardExprN</CODE>
<P>The set of valid <STRONG>guard expressions</STRONG> (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:
<P>
<UL>

<LI>
the atom <CODE>true</CODE>,
</LI>


<LI>
other constants (terms and bound variables), all regarded
        as false,
</LI>


<LI>
calls to the BIFs specified below,
</LI>


<LI>
term comparisons,
</LI>


<LI>
arithmetic expressions,
</LI>


<LI>
boolean expressions, and
</LI>


<LI>
short-circuit boolean expressions.
</LI>


</UL>

<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Type Test BIFs.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_atom/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_binary/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_constant/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_float/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_function/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_function/2</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_integer/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_list/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_number/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_pid/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_port/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_reference/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_tuple/1</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_record/2</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>is_record/3</CODE>
    </TD>

  </TR>

</TABLE>
</CENTER>

<P>Note that each type test BIF has an older equivalent, without
the <CODE>is_</CODE> 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.
<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Other BIFs Allowed in Guard Expressions.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>abs(Number)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>element(N, Tuple)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>float(Term)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>hd(List)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>length(List)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>node()</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>node(Pid|Ref|Port)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>round(Number)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>self()</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>size(Tuple|Binary)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>tl(List)</CODE>
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>trunc(Number)</CODE>
    </TD>

  </TR>

</TABLE>
</CENTER>
<A NAME="prec"><!-- Empty --></A><A NAME="6.24"><!-- Empty --></A>
<H3>6.24 Operator Precedence</H3>

<P>Operator precedence in falling priority:
<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
  <CAPTION ALIGN=BOTTOM><EM>Operator Precedence.</EM></CAPTION>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
:
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
#
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
Unary + - bnot not
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
/ * div rem band and
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
Left associative
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
+ - bor bxor bsl bsr or xor
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
Left associative
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
++ --
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
Right associative
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
== /= =&#60; &#60; &#62;= &#62; =:= =/=
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
-
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
andalso
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
orelse
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
= !
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
Right associative
    </TD>

  </TR>
  <TR>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">
catch
    </TD>
    <TD ALIGN="LEFT" VALIGN="MIDDLE">

    </TD>

  </TR>

</TABLE>
</CENTER>

<P>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:
<PRE>
<STRONG>6 + 5 * 4 - 3 / 2</STRONG> evaluates to
<STRONG>6 + 20 - 1.5</STRONG> evaluates to
<STRONG>26 - 1.5</STRONG> evaluates to
<STRONG>24.5</STRONG>
    
</PRE>
<CENTER>
<HR>
<SMALL>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>