From 0d016cdce1c688335dc265056137890d7a7850c9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn-Egil=20Dahlberg?= Date: Mon, 12 Dec 2016 17:00:19 +0100 Subject: Remove whitespace errors --- system/doc/reference_manual/typespec.xml | 71 ++++++++++++++++---------------- 1 file changed, 35 insertions(+), 36 deletions(-) diff --git a/system/doc/reference_manual/typespec.xml b/system/doc/reference_manual/typespec.xml index ced584ed35..1a3669c736 100644 --- a/system/doc/reference_manual/typespec.xml +++ b/system/doc/reference_manual/typespec.xml @@ -11,7 +11,7 @@ Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at - + http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software @@ -161,7 +161,7 @@ that M or N, or both, are zero.

- Because lists are commonly used, they have shorthand type notations. + Because lists are commonly used, they have shorthand type notations. The types list(T) and nonempty_list(T) have the shorthands [T] and [T,...], respectively. The only difference between the two shorthands is that [T] can be an @@ -169,7 +169,7 @@

Notice that the shorthand for list(), that is, the list of - elements of unknown type, is [_] (or [any()]), not []. + elements of unknown type, is [_] (or [any()]), not []. The notation [] specifies the singleton type for the empty list.

@@ -184,8 +184,8 @@ The notation #{} specifies the singleton type for the empty map.

- For convenience, the following types are also built-in. - They can be thought as predefined aliases for the type unions also shown in + For convenience, the following types are also built-in. + They can be thought as predefined aliases for the type unions also shown in the table.

@@ -201,37 +201,37 @@ bitstring()<<_:_*1>> - + boolean()'false' | 'true' - + byte()0..255 char()0..16#10ffff - + nil()[] number()integer() | float() - + list()[any()] - + maybe_improper_list()maybe_improper_list(any(), any()) - + nonempty_list()nonempty_list(any()) string()[char()] - + nonempty_string()[char(),...] - + iodata()iolist() | binary() @@ -243,7 +243,7 @@ module()atom() - + mfa(){module(),atom(),arity()} @@ -259,7 +259,7 @@ timeout()'infinity' | non_neg_integer() - no_return()none() + no_return()none() Built-in types, predefined aliases
@@ -284,11 +284,11 @@ Additional built-in types - +

Users are not allowed to define types with the same names as the predefined or built-in ones. This is checked by the compiler and - its violation results in a compilation error. + its violation results in a compilation error.

@@ -394,13 +394,13 @@ 

   -record(rec, {field1 :: Type1, field2, field3 :: Type3}).

- For fields without type annotations, their type defaults to any(). + For fields without type annotations, their type defaults to any(). That is, the previous example is a shorthand for the following: 

   -record(rec, {field1 :: Type1, field2 :: any(), field3 :: Type3}).

- In the presence of initial values for fields, + In the presence of initial values for fields, the type must be declared after the initialization, as follows: 

@@ -409,12 +409,12 @@
       The initial values for fields are to be compatible
       with (that is, a member of) the corresponding types.
       This is checked by the compiler and results in a compilation error
-      if a violation is detected. 
+      if a violation is detected.
     

     
       
Before Erlang/OTP 19, for fields without initial values,
       the singleton type 'undefined' was added to all declared types.
-      In other words, the following two record declarations had identical 
+      In other words, the following two record declarations had identical
       effects:

     
   -record(rec, {f1 = 42 :: integer(),
@@ -430,22 +430,22 @@
     

     
     

-      Any record, containing type information or not, once defined, 
+      Any record, containing type information or not, once defined,
       can be used as a type using the following syntax:
     

     
  #rec{}

     

-      In addition, the record fields can be further specified when using 
+      In addition, the record fields can be further specified when using
       a record type by adding type information about the field
       as follows:
     

     
  #rec{some_field :: Type}

     

-      Any unspecified fields are assumed to have the type in the original 
+      Any unspecified fields are assumed to have the type in the original
       record declaration.
     

   
-	
+
   

     Specifications for Functions
     

@@ -459,9 +459,9 @@
       else a compilation error occurs.
     

     

-      This form can also be used in header files (.hrl) to declare type 
-      information for exported functions. 
-      Then these header files can be included in files that (implicitly or 
+      This form can also be used in header files (.hrl) to declare type
+      information for exported functions.
+      Then these header files can be included in files that (implicitly or
       explicitly) import these functions.
     

     

@@ -475,14 +475,14 @@
     
   -spec Function(ArgName1 :: Type1, ..., ArgNameN :: TypeN) -> RT.

     

-      A function specification can be overloaded. 
+      A function specification can be overloaded.
       That is, it can have several types, separated by a semicolon (;):
     

     
   -spec foo(T1, T2) -> T3
          ; (T4, T5) -> T6.

     

-      A current restriction, which currently results in a warning 
+      A current restriction, which currently results in a warning
       (not an error) by the compiler, is that the domains of
       the argument types cannot overlap.
       For example, the following specification results in a warning:
@@ -491,9 +491,9 @@
   -spec foo(pos_integer()) -> pos_integer()
          ; (integer()) -> integer().

     

-      Type variables can be used in specifications to specify relations for 
-      the input and output arguments of a function. 
-      For example, the following specification defines the type of a 
+      Type variables can be used in specifications to specify relations for
+      the input and output arguments of a function.
+      For example, the following specification defines the type of a
       polymorphic identity function:
     

     
@@ -542,8 +542,8 @@
   -spec foo({X, integer()}) -> X when X :: atom()
          ; ([Y]) -> Y when Y :: number().

     

-      Some functions in Erlang are not meant to return; 
-      either because they define servers or because they are used to 
+      Some functions in Erlang are not meant to return;
+      either because they define servers or because they are used to
       throw exceptions, as in the following function:
     

     
  my_error(Err) -> erlang:throw({error, Err}).

@@ -555,4 +555,3 @@
     
  -spec my_error(term()) -> no_return().

   
 
-
-- 
cgit v1.2.3


From 74f4aa2897e7b2a3bac688d808b9b396fc35d1aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn-Egil=20Dahlberg?= 
Date: Mon, 12 Dec 2016 14:50:28 +0100
Subject: doc: Change "stands for" to "denotes" in typespec

---
 system/doc/reference_manual/typespec.xml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/system/doc/reference_manual/typespec.xml b/system/doc/reference_manual/typespec.xml
index 1a3669c736..c117b6e1d0 100644
--- a/system/doc/reference_manual/typespec.xml
+++ b/system/doc/reference_manual/typespec.xml
@@ -63,7 +63,7 @@
       Types consist of, and are built from, a set of predefined types,
       for example, integer(), atom(), and pid().
       Predefined types represent a typically infinite set of Erlang terms that
-      belong to this type.  For example, the type atom() stands for the
+      belong to this type.  For example, the type atom() denotes the
       set of all Erlang atoms.
     

     

@@ -131,11 +131,11 @@
         | nonempty_improper_list(Type1, Type2) %% Type1 and Type2 as above
         | nonempty_list(Type)                  %% Proper non-empty list
 
-  Map :: map()                                 %% stands for a map of any size
-       | #{}                                   %% stands for the empty map
+  Map :: map()                                 %% denotes a map of any size
+       | #{}                                   %% denotes the empty map
        | #{PairList}
 
-  Tuple :: tuple()                             %% stands for a tuple of any size
+  Tuple :: tuple()                             %% denotes a tuple of any size
          | {}
          | {TList}
 
-- 
cgit v1.2.3


From 4fbe5a6ea946de03693ffa1be671cf9af93e55eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn-Egil=20Dahlberg?= 
Date: Mon, 12 Dec 2016 16:54:42 +0100
Subject: doc: Enchance map pair optional/mandatory notes

---
 system/doc/reference_manual/typespec.xml | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/system/doc/reference_manual/typespec.xml b/system/doc/reference_manual/typespec.xml
index c117b6e1d0..a0ea41cb3b 100644
--- a/system/doc/reference_manual/typespec.xml
+++ b/system/doc/reference_manual/typespec.xml
@@ -142,8 +142,8 @@
   PairList :: Pair
             | Pair, PairList
 
-  Pair :: Type := Type                         %% denotes a pair that must be present
-        | Type => Type
+  Pair :: Type := Type                         %% denotes a mandatory pair
+        | Type => Type                         %% denotes an optional pair
 
   TList :: Type
          | Type, TList
@@ -176,7 +176,11 @@
     The general form of maps is #{PairList}. The key types in
     PairList are allowed to overlap, and if they do, the
     leftmost pair takes precedence. A map pair has a key in
-    PairList if it belongs to this type.
+    PairList if it belongs to this type. A PairList may contain
+    both 'mandatory' and 'optional' pairs where 'mandatory' denotes that
+    a key type, and its associated value type, must be present.
+    In the case of an 'optional' pair it is not required for the key type to
+    be present.
   

   

     Notice that the syntactic representation of map() is
-- 
cgit v1.2.3