From 9fe8adf35c16ab5d4566b03f3b36863c90b5b6dd Mon Sep 17 00:00:00 2001 From: Hans Bolinder Date: Thu, 12 Mar 2015 15:35:13 +0100 Subject: Update Erlang Reference Manual Language cleaned up by the technical writers xsipewe and tmanevik from Combitech. Proofreading and corrections by Hans Bolinder. --- system/doc/reference_manual/expressions.xml | 732 +++++++++++++++------------- 1 file changed, 391 insertions(+), 341 deletions(-) (limited to 'system/doc/reference_manual/expressions.xml') diff --git a/system/doc/reference_manual/expressions.xml b/system/doc/reference_manual/expressions.xml index 62a344ad58..fd3cfabd3d 100644 --- a/system/doc/reference_manual/expressions.xml +++ b/system/doc/reference_manual/expressions.xml @@ -4,7 +4,7 @@
- 20032013 + 20032015 Ericsson AB. All Rights Reserved. @@ -28,13 +28,17 @@ expressions.xml
-

In this chapter, all valid Erlang expressions are listed. +

In this section, 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.

+ separate sections: +

+ +

Preprocessor

 +

Records

 +
Expression Evaluation @@ -48,15 +52,15 @@ Expr1 + Expr2 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.

+ applied to numbers. An argument of the wrong type causes + a badarg runtime error.

Terms

The simplest form of expression is a term, that is an integer, - float, atom, string, list, map or tuple. + float, atom, string, list, map, or tuple. The return value is the term itself.

@@ -65,9 +69,10 @@ Expr1 + Expr2

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:

+

Variables start with an uppercase letter or underscore (_). + Variables can contain alphanumeric characters, underscore and @. +

+

Examples:

 X
 Name1
@@ -77,18 +82,20 @@ _
 _Height

Variables are bound to values using pattern matching. Erlang - uses single assignment, a variable can only be bound + uses single assignment, that is, 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:

+ ignored.

+

Example:

 [H|_] = [1,2,3]
-

Variables starting with underscore (_), for example +

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

+ however ignored by the compiler in the sense that they do not + generate any warnings for unused variables.

+

Example:

+

The following code:

 member(_, []) ->
     [].
@@ -96,36 +103,37 @@ member(_, []) -> 
 member(Elem, []) ->
     [].
-

This will however cause a warning for an unused variable +

This causes 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:

+

Notice that since variables starting with an underscore are + not anonymous, this matches:

 {_,_} = {1,2}
-

But this will fail:

+

But this fails:

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

+ to have a value outside the expression. Otherwise they + are regarded as 'unsafe' outside the expression.

For the try expression introduced in - Erlang 5.4/OTP-R10B, variable scoping is limited so that + 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.

+ the expression. This is to be improved.

Patterns -

A pattern has the same structure as a term but may contain - unbound variables. Example:

+

A pattern has the same structure as a term but can contain + unbound variables.

+

Example:

 Name1
 [H|T]
@@ -136,13 +144,13 @@ Name1
     

       Match Operator = in Patterns
       
If Pattern1 and Pattern2 are valid patterns,
-        then the following is also a valid pattern:

+        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:

+        Pattern2 are  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},
@@ -163,16 +171,20 @@ f(Signal, To) ->
       
 f("prefix" ++ Str) -> ...

       
This is syntactic sugar for the equivalent, but harder to
-        read

+        read:

       
 f([$p,$r,$e,$f,$i,$x | Str]) -> ...

     

 
     

       Expressions in Patterns
-      
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:

+      
An arithmetic expression can be used within a pattern if
+        it meets both of the following two conditions:

+      
+        It uses only numeric or bitwise operators.
+        Its value can be evaluated to a constant when complied.
+      
+      
Example:

       
 case {Value, Result} of
     {?THRESHOLD+1, ok} -> ...

@@ -182,21 +194,21 @@ case {Value, Result} of
 
   

     Match
+    
The following matches Expr1, a pattern, against
+      Expr2:

     
 Expr1 = Expr2

-    
Matches Expr1, a pattern, against Expr2.
-      If the matching succeeds, any unbound variable in the pattern
+    
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:

+    
If the matching fails, a badmatch run-time error occurs.

+    
Examples:

     
 1> {A, B} = {answer, 42}.
 {answer,42}
 2> A.
 answer
 3> {C, D} = [1, 2].
-** exception error: no match of right hand side value [1,2]

+** exception error: no match of right-hand side value [1,2]
@@ -210,27 +222,28 @@ ExprM:ExprF(Expr1,...,ExprN) ExprF must be an atom or an expression that evaluates to an atom. 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:

+ to as a remote or external function call.

+

Example:

lists:keysearch(Name, 1, List)

In the second form of function calls, ExprF(Expr1,...,ExprN), ExprF must be an atom or evaluate to a fun.

-

If ExprF is an atom the function is said to be called by +

If ExprF is an atom, the function is said to be called by using the implicitly qualified function name. If the function ExprF is locally defined, it is called. - Alternatively if ExprF is explicitly imported from module - M, M:ExprF(Expr1,...,ExprN) is called. If + Alternatively, if ExprF is explicitly imported from the + M module, M:ExprF(Expr1,...,ExprN) is called. If ExprF is neither declared locally nor explicitly imported, ExprF must be the name of an automatically - imported BIF. Examples:

+ imported BIF.

+

Examples:

handle(Msg, State) spawn(m, init, []) -

Examples where ExprF is a fun:

+

Examples where ExprF is a fun:

Fun1 = fun(X) -> X+1 end Fun1(3) @@ -239,16 +252,15 @@ Fun1(3) fun lists:append/2([1,2], [3,4]) => [1,2,3,4] -

Note that when calling a local function, there is a difference - between using the implicitly or fully qualified function name, as - the latter always refers to the latest version of the module. See - Compilation and Code Loading.

- -

See also the chapter about - Function Evaluation.

+

Notice that when calling a local function, there is a difference + between using the implicitly or fully qualified function name. + The latter always refers to the latest version of the module. + See Compilation and Code Loading + and + Function Evaluation.

- Local Function Names Clashing With Auto-imported BIFs + Local Function Names Clashing With Auto-Imported BIFs

If a local function has the same name as an auto-imported BIF, the semantics is that implicitly qualified function calls are directed to the locally defined function, not to the BIF. To avoid @@ -260,9 +272,9 @@ fun lists:append/2([1,2], [3,4])

Before OTP R14A (ERTS version 5.8), an implicitly qualified function call to a function having the same name as an auto-imported BIF always resulted in the BIF being called. In - newer versions of the compiler the local function is instead - called. The change is there to avoid that future additions to the - set of auto-imported BIFs does not silently change the behavior + newer versions of the compiler, the local function is called instead. + This is to avoid that future additions to the + set of auto-imported BIFs do not silently change the behavior of old code.

However, to avoid that old (pre R14) code changed its @@ -272,8 +284,8 @@ fun lists:append/2([1,2], [3,4]) 5.8) and have an implicitly qualified call to that function in your code, you either need to explicitly remove the auto-import using a compiler directive, or replace the call with a fully - qualified function call, otherwise you will get a compilation - error. See example below:

+ qualified function call. Otherwise you get a compilation + error. See the following example:

-export([length/1,f/1]). @@ -290,9 +302,10 @@ f(X) when erlang:length(X) > 3 -> %% Calls erlang:length/1, long.

The same logic applies to explicitly imported functions from - other modules as to locally defined functions. To both import a + other modules, as to locally defined functions. + It is not allowed to both import a function from another module and have the function declared in the - module at the same time is not allowed.

+ module at the same time:

-export([f/1]). @@ -310,10 +323,10 @@ f(X) -> length(X). %% mod:length/1 is called -

For auto-imported BIFs added to Erlang in release R14A and thereafter, +

For auto-imported BIFs added in Erlang/OTP R14A and thereafter, overriding the name with a local function or explicit import is always allowed. However, if the -compile({no_auto_import,[F/A]) - directive is not used, the compiler will issue a warning whenever + directive is not used, the compiler issues a warning whenever the function is called in the module using the implicitly qualified function name.

@@ -330,15 +343,16 @@ if BodyN end

The branches of an if-expression are scanned sequentially - until a guard sequence GuardSeq which evaluates to true is + until a guard sequence GuardSeq that 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 +

If no guard sequence is evaluated as true, + an if_clause run-time error + occurs. If necessary, the guard expression true can be used in the last branch, as that guard sequence is always true.

-

Example:

+

Example:

 is_greater_than(X, Y) ->
     if
@@ -367,8 +381,8 @@ end

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:

+ a case_clause run-time error occurs.

+

Example:

 is_valid_signal(Signal) ->
     case Signal of
@@ -389,15 +403,15 @@ 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 must evaluate to a pid, a registered name (atom), or + a tuple {Name,Node}. Name is an atom and + Node is a node name, also an atom.

If Expr1 evaluates to a name, but this name is not - registered, a badarg run-time error will occur. + registered, a badarg run-time error occurs. Sending a message to a pid never fails, even if the pid identifies a non-existing process. - Distributed message sending, that is if Expr1 + Distributed message sending, that is, if Expr1 evaluates to a tuple {Name,Node} (or a pid located at another node), also never fails. @@ -420,14 +434,14 @@ end 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 + 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 +

receive never fails. The execution is suspended, possibly + indefinitely, until a message arrives that matches one of the patterns and with a true guard sequence.

-

Example:

+

Example:

 wait_for_onhook() ->
     receive
@@ -438,7 +452,7 @@ wait_for_onhook() ->
             B ! {busy, self()},
             wait_for_onhook()
     end.
-

It is possible to augment the receive expression with a +

The receive expression can be augmented with a timeout:

 receive
@@ -451,14 +465,14 @@ 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. +

ExprT is to 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:

+ milliseconds, then BodyT is evaluated instead. The + return value of BodyT then becomes the return value + of the receive..after expression.

+

Example:

 wait_for_onhook() ->
     receive
@@ -481,10 +495,10 @@ after
     ExprT ->
         BodyT
 end
-

This construction will not consume any messages, only suspend - execution in the process for ExprT milliseconds and can be +

This construction does not consume any messages, only suspends + execution in the process for ExprT milliseconds. This can be used to implement simple timers.

-

Example:

+

Example:

 timer() ->
     spawn(m, timer, [self()]).
@@ -498,12 +512,12 @@ timer(Pid) ->
     
There are two special cases for the timeout value ExprT:

     
       infinity
-      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.
+      The process is to wait indefinitely for a matching message;
+       this is the same as not using a timeout. This can be
+       useful for timeout values that are calculated at runtime.
       0
       If there is no matching message in the mailbox, the timeout
-       will occur immediately.
+       occurs immediately.
@@ -518,39 +532,39 @@ Expr1 op Expr2 == - equal to + Equal to /= - not equal to + Not equal to =< - less than or equal to + Less than or equal to < - less than + Less than >= - greater than or equal to + Greater than or equal to > - greater than + Greater than =:= - exactly equal to + Exactly equal to =/= - exactly not equal to + Exactly not equal to Term Comparison Operators. -

The arguments may be of different data types. The following +

The arguments can be of different data types. The following order is defined:

 number < atom < reference < fun < port < pid < tuple < list < bit string
@@ -558,17 +572,18 @@ number < atom < reference < fun < port < pid < tuple < list size, two tuples with the same size are compared element by element.

When comparing an integer to a float, the term with the lesser - precision will be converted into the other term's type, unless the - operator is one of =:= or =/=. A float is more precise than + precision is converted into the type of the other term, unless the + operator is one of =:= or =/=. A float is more precise than an integer until all significant figures of the float are to the left of the decimal point. This happens when the float is larger/smaller than +/-9007199254740992.0. The conversion strategy is changed depending on the size of the float because otherwise comparison of large floats and integers would lose their transitivity.

-

Returns the Boolean value of the expression, true or - false.

-

Examples:

+

Term comparison operators return the Boolean value of the + expression, true or false.

+ +

Examples:

 1> 1==1.0.
 true
@@ -585,19 +600,19 @@ false
Expr1 op Expr2 - op + Operator Description - Argument type + Argument Type + - unary + - number + Unary + + Number - - unary - - number + Unary - + Number + @@ -607,62 +622,62 @@ Expr1 op Expr2 -   - number + Number *   - number + Number / - floating point division - number + Floating point division + Number bnot - unary bitwise not - integer + Unary bitwise NOT + Integer div - integer division - integer + Integer division + Integer rem - integer remainder of X/Y - integer + Integer remainder of X/Y + Integer band - bitwise and - integer + Bitwise AND + Integer bor - bitwise or - integer + Bitwise OR + Integer bxor - arithmetic bitwise xor - integer + Arithmetic bitwise XOR + Integer bsl - arithmetic bitshift left - integer + Arithmetic bitshift left + Integer bsr - bitshift right - integer + Bitshift right + Integer Arithmetic Operators.
-

Examples:

+

Examples:

 1> +1.
 1
@@ -697,28 +712,28 @@ Expr1 op Expr2
Expr1 op Expr2 - op + Operator Description not - unary logical not + Unary logical NOT and - logical and + Logical AND or - logical or + Logical OR xor - logical xor + Logical XOR Logical Operators.
-

Examples:

+

Examples:

 1> not true.
 false
@@ -737,28 +752,37 @@ true
     
 Expr1 orelse Expr2
 Expr1 andalso Expr2

-    
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 either the value of Expr1 (that is,
+    
Expr2 is evaluated only if
+      necessary. That is, Expr2 is evaluated only if:

+    
+      
Expr1 evaluates to false in an
+      orelse expression.

+      
+    
+      
or

+    
+      
Expr1 evaluates to true in an
+      andalso expression.

+      
+    
+    
Returns either the value of Expr1 (that is,
       true or false) or the value of Expr2
-      (if Expr2 was evaluated).

+      (if Expr2 is evaluated).

 
-    
Example 1:

+    
Example 1:

     
 case A >= -1.0 andalso math:sqrt(A+1) > B of

-    
This will work even if A is less than -1.0,
+    
This works even if A is less than -1.0,
       since in that case, math:sqrt/1 is never evaluated.

-    
Example 2:

+    
Example 2:

     
 OnlyOne = is_atom(L) orelse
          (is_list(L) andalso length(L) == 1),

 
-    
From R13A, Expr2 is no longer required to evaluate to a
-    boolean value. As a consequence, andalso and orelse
+    
From Erlang/OTP R13A, Expr2 is no longer required to evaluate to a
+    Boolean value. As a consequence, andalso and orelse
     are now tail-recursive.  For instance, the following function is
-    tail-recursive in R13A and later:

+    tail-recursive in Erlang/OTP R13A and later:

 
     
 all(Pred, [Hd|Tail]) ->
@@ -774,11 +798,11 @@ 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
+    
The list subtraction operator -- produces a list that
+      is a copy of the first argument. The procedure is a follows:
+      for each element in the second argument, the first
       occurrence of this element (if any) is removed.

-    
Example:

+    
Example:

     
 1> [1,2,3]++[4,5].
 [1,2,3,4,5]
@@ -786,8 +810,8 @@ Expr1 -- Expr2

 [3,1,2]

The complexity of A -- B is - proportional to length(A)*length(B), meaning that it - will be very slow if both A and B are + proportional to length(A)*length(B). That is, it + becomes very slow if both A and B are long lists.

 @@ -802,7 +826,7 @@ Expr1 -- Expr2

#{ K => V }

- New maps may include multiple associations at construction by listing every + New maps can include multiple associations at construction by listing every association:

#{ K1 => V1, .., Kn => Vn } @@ -816,11 +840,11 @@ Expr1 -- Expr2

Keys and values are separated by the => arrow and associations are - separated by ,. + separated by a comma ,.

- Examples: + Examples:

M0 = #{}, % empty map @@ -829,14 +853,14 @@ M2 = #{1 => 2, b => b}, % multiple associations with literals M3 = #{k => {A,B}}, % single association with variables M4 = #{{"w", 1} => f()}. % compound key associated with an evaluated expression

- where, A and B are any expressions and M0 through M4 + Here, A and B are any expressions and M0 through M4 are the resulting map terms.

- If two matching keys are declared, the latter key will take precedence. + If two matching keys are declared, the latter key takes precedence.

- Example: + Example: 

@@ -846,54 +870,57 @@ M4 = #{{"w", 1} => f()}.  % compound key associated with an evaluated expression
 #{1 => b, 1.0 => a}

- The order in which the expressions constructing the keys and their - associated values are evaluated is not defined. The syntactic order of + The order in which the expressions constructing the keys (and their + associated values) are evaluated is not defined. The syntactic order of the key-value pairs in the construction is of no relevance, except in - the above mentioned case of two matching keys. + the recently mentioned case of two matching keys.

Updating Maps

- Updating a map has similar syntax as constructing it. + Updating a map has a similar syntax as constructing it.

- An expression defining the map to be updated is put in front of the expression - defining the keys to be updated and their respective values. + An expression defining the map to be updated, is put in front of the expression + defining the keys to be updated and their respective values:

M#{ K => V }

- where M is a term of type map and K and V are any expression. + Here M is a term of type map and K and V are any expression.

If key K does not match any existing key in the map, a new association - will be created from key K to value V. If key K matches - an existing key in map M its associated value will be replaced by the - new value V. In both cases the evaluated map expression will return a new map. + is created from key K to value V. +

+

If key K matches an existing key in map M, + its associated value + is replaced by the new value V. In both cases, the evaluated map expression + returns a new map.

- If M is not of type map an exception of type badmap is thrown. + If M is not of type map, an exception of type badmap is thrown.

- To only update an existing value, the following syntax is used, + To only update an existing value, the following syntax is used:

M#{ K := V }

- where M is an term of type map, V is an expression and K - is an expression which evaluates to an existing key in M. + Here M is a term of type map, V is an expression and K + is an expression that evaluates to an existing key in M.

- If key K does not match any existing keys in map M an exception - of type badarg will be triggered at runtime. If a matching key K - is present in map M its associated value will be replaced by the new - value V and the evaluated map expression returns a new map. + If key K does not match any existing keys in map M, an exception + of type badarg is triggered at runtime. If a matching key K + is present in map M, its associated value is replaced by the new + value V, and the evaluated map expression returns a new map.

- If M is not of type map an exception of type badmap is thrown. + If M is not of type map, an exception of type badmap is thrown.

- Examples: + Examples:

M0 = #{}, @@ -902,10 +929,10 @@ M2 = M1#{a => 1, b => 2}, M3 = M2#{"function" => fun() -> f() end}, M4 = M3#{a := 2, b := 3}. % 'a' and 'b' was added in `M1` and `M2`.

- where M0 is any map. It follows that M1 .. M4 are maps as well. + Here M0 is any map. It follows that M1 .. M4 are maps as well.

- More Examples: + More Examples: 

 1> M = #{1 => a}.
@@ -921,83 +948,84 @@ M4 = M3#{a := 2, b := 3}.  % 'a' and 'b' was added in `M1` and `M2`.
 		  As in construction, the order in which the key and value expressions
 		  are evaluated is not defined. The
 		  syntactic order of the key-value pairs in the update is of no
-		  relevance, except in the case where two keys match, in which
-		  case the latter value is used.
+		  relevance, except in the case where two keys match.
+		  In that case, the latter value is used.
Maps in Patterns

- Matching of key-value associations from maps is done in the following way: + Matching of key-value associations from maps is done as follows:

#{ K := V } = M

- where M is any map. The key K has to be an expression with bound - variables or a literals, and V can be any pattern with either bound or + Here M is any map. The key K must be an expression with bound + variables or literals. V can be any pattern with either bound or unbound variables.

- If the variable V is unbound, it will be bound to the value associated - with the key K, which has to exist in the map M. If the variable - V is bound, it has to match the value associated with K in M. + If the variable V is unbound, it becomes bound to the value associated + with the key K, which must exist in the map M. If the variable + V is bound, it must match the value associated with K in M.

-

Example:

- +

Example:

+
 1> M = #{"tuple" => {1,2}}.
 #{"tuple" => {1,2}}
 2> #{"tuple" := {1,B}} = M.
 #{"tuple" => {1,2}}
 3> B.
-2.
+2.

- This will bind variable B to integer 2. + This binds variable B to integer 2.

- Similarly, multiple values from the map may be matched: + Similarly, multiple values from the map can be matched:

#{ K1 := V1, .., Kn := Vn } = M

- where keys K1 .. Kn are any expressions with literals or bound variables. If all - keys exist in map M all variables in V1 .. Vn will be matched to the + Here keys K1 .. Kn are any expressions with literals or bound variables. If all + keys exist in map M, all variables in V1 .. Vn is matched to the associated values of their respective keys.

- If the matching conditions are not met, the match will fail, either with + If the matching conditions are not met, the match fails, either with:

- - a badmatch exception, if used in the context of the matching operator - as in the example, +

A badmatch exception.

+

This is if it is used in the context of the matching operator + as in the example.

 - - or resulting in the next clause being tested in function heads and - case expressions. +

Or resulting in the next clause being tested in function heads and + case expressions.

Matching in maps only allows for := as delimiters of associations. +

+

The order in which keys are declared in matching has no relevance.

- Duplicate keys are allowed in matching and will match each pattern associated - to the keys. + Duplicate keys are allowed in matching and match each pattern associated + to the keys:

#{ K := V1, K := V2 } = M

- Matching an expression against an empty map literal will match its type but - no variables will be bound: + Matching an expression against an empty map literal, matches its type but + no variables are bound:

#{} = Expr

- This expression will match if the expression Expr is of type map, otherwise - it will fail with an exception badmatch. + This expression matches if the expression Expr is of type map, otherwise + it fails with an exception badmatch.

- Matching syntax: Example with literals in function heads + Matching Syntax

- Matching of literals as keys are allowed in function heads. + Matching of literals as keys are allowed in function heads:

%% only start if not_started @@ -1014,17 +1042,19 @@ handle_call(change, From, #{ state := start } = S) ->
Maps in Guards

- Maps are allowed in guards as long as all sub-expressions are valid guard expressions. + Maps are allowed in guards as long as all subexpressions are valid guard expressions.

- Two guard BIFs handles maps: + Two guard BIFs handle maps:

is_map/1 + in the erlang module map_size/1 + in the erlang module
@@ -1044,29 +1074,34 @@ Ei = Value | Value/TypeSpecifierList | Value:Size/TypeSpecifierList

Used in a bit string construction, Value is an expression - which should evaluate to an integer, float or bit string. If the - expression is something else than a single literal or variable, it - should be enclosed in parenthesis.

+ that is to evaluate to an integer, float, or bit string. If the + expression is not a single literal or variable, it + is to be enclosed in parenthesis.

Used in a bit string matching, Value must be a variable, - or an integer, float or string.

+ or an integer, float, or string.

-

Note that, for example, using a string literal as in +

Notice that, for example, using a string literal as in >]]> is syntactic sugar for >]]>.

Used in a bit string construction, Size is an expression - which should evaluate to an integer.

+ that is to evaluate to an integer.

-

Used in a bit string matching, Size must be an integer or a +

Used in a bit string 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 and bitstring it is - the whole binary or bit string. In matching, this default value is only - valid for the very last element. All other bit string or binary + below):

+ + For integer it is 8. + For float it is 64. + For binary and bitstring it is + the whole binary or bit string. + +

In matching, this default value is only + valid for the last element. All other bit string or binary elements in the matching must have a size specification.

For the utf8, utf16, and utf32 types, @@ -1090,7 +1125,7 @@ Ei = Value | The default is unsigned. Endianness= big | little | native - Native-endian means that the endianness will be resolved at load + Native-endian means that the endianness is 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. Endianness only matters when the Type is either integer, @@ -1099,7 +1134,7 @@ Ei = Value | Unit= unit:IntegerLiteral The allowed range is 1..256. Defaults to 1 for integer, - float and bitstring, and to 8 for binary. + float, and bitstring, and to 8 for binary. No unit specifier must be given for the types utf8, utf16, and utf32. @@ -1110,8 +1145,8 @@ Ei = Value |

When constructing binaries, if the size N of an integer segment is too small to contain the given integer, the most significant - bits of the integer will be silently discarded and only the N least - significant bits will be put into the binary.

+ bits of the integer are silently discarded and only the N least + significant bits are put into the binary.

The types utf8, utf16, and utf32 specifies encoding/decoding of the Unicode Transformation Formats UTF-8, UTF-16, @@ -1120,39 +1155,39 @@ Ei = Value |

When constructing a segment of a utf type, Value must be an integer in the range 0..16#D7FF or 16#E000....16#10FFFF. Construction - will fail with a badarg exception if Value is + fails with a badarg exception if Value is outside the allowed ranges. The size of the resulting binary - segment depends on the type and/or Value. For utf8, - Value will be encoded in 1 through 4 bytes. For - utf16, Value will be encoded in 2 or 4 - bytes. Finally, for utf32, Value will always be - encoded in 4 bytes.

+ segment depends on the type or Value, or both:

+ + For utf8, Value is encoded in 1-4 bytes. + For utf16, Value is encoded in 2 or 4 bytes. + For utf32, Value is always be encoded in 4 bytes. + -

When constructing, a literal string may be given followed +

When constructing, a literal string can be given followed by one of the UTF types, for example: >]]> - which is syntatic sugar for + which is syntactic sugar for >]]>.

-

A successful match of a segment of a utf type results +

A successful match of a segment of a utf type, results in an integer in the range 0..16#D7FF or 16#E000..16#10FFFF. - The match will fail if returned value - would fall outside those ranges.

+ The match fails if the returned value falls outside those ranges.

-

A segment of type utf8 will match 1 to 4 bytes in the binary, +

A segment of type utf8 matches 1-4 bytes in the binary, if the binary at the match position contains a valid UTF-8 sequence. (See RFC-3629 or the Unicode standard.)

-

A segment of type utf16 may match 2 or 4 bytes in the binary. - The match will fail if the binary at the match position does not contain +

A segment of type utf16 can match 2 or 4 bytes in the binary. + The match fails if the binary at the match position does not contain a legal UTF-16 encoding of a Unicode code point. (See RFC-2781 or the Unicode standard.)

-

A segment of type utf32 may match 4 bytes in the binary in the - same way as an integer segment matching 32 bits. - The match will fail if the resulting integer is outside the legal ranges +

A segment of type utf32 can match 4 bytes in the binary in the + same way as an integer segment matches 32 bits. + The match fails if the resulting integer is outside the legal ranges mentioned above.

-

Examples:

+

Examples:

 1> Bin1 = <<1,17,42>>.
 <<1,17,42>>
@@ -1181,11 +1216,13 @@ Ei = Value |
 13> <<1024/utf8>>.
 <<208,128>>
-

Note that bit string patterns cannot be nested.

-

Note also that ">]]>" is interpreted as +

Notice that bit string patterns cannot be nested.

+

Notice also that ">]]>" is interpreted as ">]]>" which is a syntax error. The correct way is to write a space after '=': ">]]>.

-

More examples can be found in Programming Examples.

+

More examples are provided in + + Programming Examples.

@@ -1200,16 +1237,16 @@ fun BodyK end

A fun expression begins with the keyword fun and ends - with the keyword end. Between them should be a function + with the keyword end. Between them is to be a function declaration, similar to a regular function declaration, - except that the function name is optional and should be a variable if + except that the function name is optional and is to be a variable, if any.

Variables in a fun head shadow the function name and both shadow - variables in the function clause surrounding the fun expression, and - variables bound in a fun body are local to the fun body.

+ variables in the function clause surrounding the fun expression. + Variables bound in a fun body are local to the fun body.

The return value of the expression is the resulting fun.

-

Examples:

+

Examples:

 1> Fun1 = fun (X) -> X+1 end.
 #Fun<erl_eval.6.39074546>
@@ -1232,15 +1269,17 @@ fun Module:Name/Arity
syntactic sugar for:

 fun (Arg1,...,ArgN) -> Name(Arg1,...,ArgN) end
-

In Module:Name/Arity, Module and Name are atoms - and Arity is an integer. Starting from the R15 release, - Module, Name, and Arity may also be variables. - A fun defined in this way will refer to the function Name +

In Module:Name/Arity, Module, and Name are atoms + and Arity is an integer. Starting from Erlang/OTP R15, + Module, Name, and Arity can also be variables. + A fun defined in this way refers to the function Name with arity Arity in the latest version of module - Module. A fun defined in this way will not be dependent on - the code for module in which it is defined. + Module. A fun defined in this way is not dependent on + the code for the module in which it is defined.

-

More examples can be found in Programming Examples.

+

More examples are provided in + + Programming Examples.

@@ -1250,23 +1289,26 @@ fun (Arg1,...,ArgN) -> Name(Arg1,...,ArgN) end 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.

+ 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:

-

+ Exit Reasons.

+

Examples:

 1> catch 1+2.
 3
 2> catch 1+a.
 {'EXIT',{badarith,[...]}}
-

Note that catch has low precedence and catch +

Notice that catch has low precedence and catch subexpressions often needs to be enclosed in a block expression or in parenthesis:

@@ -1275,13 +1317,14 @@ catch Expr
 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:

+ a function. It must be evaluated within a catch, which + returns 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.

+ nocatch run-time error occurs.

@@ -1297,14 +1340,17 @@ catch 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 + Erlang 5.4/OTP R10B. It gives the possibility to:

+ + Distinguish between different exception classes. + Choose to handle only the desired ones. + Passing the others on to an enclosing + try or catch, or to default error handling. + +

Notice 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 +

It 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 @@ -1318,7 +1364,7 @@ end 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 +

If an exception occurs during evaluation of ExceptionBody, it is not caught.

The try expression can have an of section: @@ -1341,7 +1387,7 @@ end 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.

+ the matching fails, a try_clause run-time error occurs.

An exception occurring during the evaluation of Body is not caught.

The try expression can also be augmented with an @@ -1364,7 +1410,7 @@ after AfterBody end

AfterBody is evaluated after either Body or - ExceptionBody no matter which one. The evaluated value of + 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 @@ -1373,13 +1419,13 @@ end 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, + 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 +

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 + after section. So the following are valid try expressions:

try Exprs of @@ -1398,9 +1444,9 @@ after end try Exprs after AfterBody end -

Example of using after, this code will close the file +

Next is an example of using after. This closes 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 + binary_to_term/1. The exceptions are the same as without the try...after...end expression:

termize_file(Name) -> @@ -1411,7 +1457,7 @@ termize_file(Name) -> after file:close(F) end. -

Example: Using try to emulate catch Expr.

+

Next is an example of using try to emulate catch Expr:

try Expr catch @@ -1427,7 +1473,7 @@ end (Expr)

Parenthesized expressions are useful to override operator precedences, - for example in arithmetic expressions:

+ for example, in arithmetic expressions:

 1> 1 + 2 * 3.
 7
@@ -1451,7 +1497,7 @@ end
List Comprehensions -

List comprehensions are a feature of many modern functional +

List comprehensions is 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 @@ -1461,32 +1507,34 @@ end

List comprehensions are written with the following syntax:

 [Expr || Qualifier1,...,QualifierN]
-

Expr is an arbitrary expression, and each +

Here, Expr is an arbitrary expression, and each Qualifier is either a generator or a filter.

A generator is written as:

  .

-ListExpr must be an expression which evaluates to a +ListExpr must be an expression, which evaluates to a list of terms. A bit string generator is written as:

  .

-BitStringExpr must be an expression which evaluates to a +BitStringExpr must be an expression, which evaluates to a bitstring. - A filter is an expression which evaluates to + A filter is an expression, which evaluates to true or false. -

The variables in the generator patterns shadow variables in the function - clause surrounding the list comprehensions.

A list comprehension +

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 and bit string generator - elements for which all filters are true.

Example:

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

- +

More examples are provoded in + + Programming Examples.

@@ -1500,34 +1548,35 @@ end the following syntax:

 << BitString || Qualifier1,...,QualifierN >>
-

BitString is a bit string expression, and each +

Here, BitString is a bit string expression and each Qualifier is either a generator, a bit string generator or a filter.

A generator is written as:

  .

- ListExpr must be an expression which evaluates to a + ListExpr must be an expression that evaluates to a list of terms. A bit string generator is written as:

  .

-BitStringExpr must be an expression which evaluates to a +BitStringExpr must be an expression that evaluates to a bitstring. - A filter is an expression which evaluates to + A filter is an expression that evaluates to true or false. -

The variables in the generator patterns shadow variables in - the function clause surrounding the bit string comprehensions.

+

The variables in the generator patterns, shadow variables in + the function clause, surrounding the bit string comprehensions.

A bit string comprehension returns a bit string, which is created by concatenating the results of evaluating BitString - for each combination of bit string generator elements for which all + for each combination of bit string generator elements, for which all filters are true.

-

-

Example:

+

Example:

-1> << << (X*2) >> || 
+1> << << (X*2) >> ||
 <<X>> <= << 1,2,3 >> >>.
 <<2,4,6>>
-

More examples can be found in Programming Examples.

+

More examples are provided in + + Programming Examples.

@@ -1536,27 +1585,27 @@ end

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. (The remaining guards, if any, will not be - evaluated.)

-Guard1;...;GuardK

+ the guards is true. (The remaining guards, if any, are not + evaluated.)

+

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

+ 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:

+ of side effects. Valid guard expressions are the following:

- the atom true, - other constants (terms and bound variables), all regarded - as false, - calls to the BIFs specified below, - term comparisons, - arithmetic expressions, - boolean expressions, and - short-circuit expressions (andalso/orelse). + The atom true + Other constants (terms and bound variables), all regarded + as false + Calls to the BIFs specified in table Type Test BIFs + Term comparisons + Arithmetic expressions + Boolean expressions + Short-circuit expressions (andalso/orelse) @@ -1610,13 +1659,13 @@ end is_tuple/1 - Type Test BIFs. + Type Test BIFs
-

Note that most type test BIFs have older equivalents, without +

Notice that most type test BIFs have older equivalents, without the is_ prefix. These old BIFs are retained for backwards - compatibility only and should not be used in new code. They are + compatibility only and are not to be used in new code. They are also only allowed at top level. For example, they are not allowed - in boolean expressions in guards.

+ in Boolean expressions in guards.

abs(Number) @@ -1666,14 +1715,14 @@ end tuple_size(Tuple) - Other BIFs Allowed in Guard Expressions. + Other BIFs Allowed in Guard Expressions
-

If an arithmetic expression, a boolean expression, a +

If an arithmetic expression, a Boolean expression, a short-circuit expression, or a call to a guard BIF fails (because of invalid arguments), the entire guard fails. If the guard was part of a guard sequence, the next guard in the sequence (that is, - the guard following the next semicolon) will be evaluated.

+ the guard following the next semicolon) is evaluated.

@@ -1726,12 +1775,13 @@ end catch   - Operator Precedence. + Operator Precedence

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 arithmetic operators are evaluated left to + are evaluated according to their associativity.

+

Example:

+

The left associative arithmetic operators are evaluated left to right:

 6 + 5 * 4 - 3 / 2 evaluates to
-- 
cgit v1.2.3