summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRaimo Niskanen <raimo@erlang.org>2020-03-10 16:38:37 +0100
committerRaimo Niskanen <raimo@erlang.org>2020-03-10 16:38:37 +0100
commit2316d3b1e8970572f9349c424825db152044d3e0 (patch)
treececc8550733c78c2cfdbed3df34f8820836ef1af
parent9c96d60d0c4b4f3f7aa4df3b9178103682973365 (diff)
downloaderlang-2316d3b1e8970572f9349c424825db152044d3e0.tar.gz
Correct spelling of 'behaviour' and 'time-out'
-rw-r--r--system/doc/design_principles/statem.xml18
1 files changed, 9 insertions, 9 deletions
diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml
index 07030ed46d..06bffc72ee 100644
--- a/system/doc/design_principles/statem.xml
+++ b/system/doc/design_principles/statem.xml
@@ -4,7 +4,7 @@
<chapter>
<header>
<copyright>
- <year>2016</year><year>2019</year>
+ <year>2016</year><year>2020</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -22,7 +22,7 @@
</legalnotice>
- <title>gen_statem Behavior</title>
+ <title>gen_statem Behaviour</title>
<prepared></prepared>
<docno></docno>
<date></date>
@@ -84,12 +84,12 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
(see, for example, the Wikipedia article "Mealy machine").
</p>
<p>
- Like most <c>gen_</c> behaviors, <c>gen_statem</c> keeps
+ Like most <c>gen_</c> behaviours, <c>gen_statem</c> keeps
a server <c>Data</c> besides the state. Because of this, and as
there is no restriction on the number of states
(assuming that there is enough virtual machine memory)
or on the number of distinct input events,
- a state machine implemented with this behavior
+ a state machine implemented with this behaviour
is in fact Turing complete.
But it feels mostly like an Event-Driven Mealy machine.
</p>
@@ -191,7 +191,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
<marker id="Callback Modes" />
<title>Callback Modes</title>
<p>
- The <c>gen_statem</c> behavior supports two <em>callback modes</em>:
+ The <c>gen_statem</c> behaviour supports two <em>callback modes</em>:
</p>
<taglist>
<tag>
@@ -788,7 +788,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
<marker id="State Enter Calls" />
<title>State Enter Calls</title>
<p>
- The <c>gen_statem</c> behavior can if this is enabled,
+ The <c>gen_statem</c> behaviour can if this is enabled,
regardless of <em>callback mode</em>,
automatically
<seealso marker="stdlib:gen_statem#type-state_enter">
@@ -890,7 +890,7 @@ StateName(EventType, EventContent, Data) ->
<seealso marker="#Postponing Events">postponed </seealso>
and
<seealso marker="#Inserted Events">inserted</seealso>
- events cancel this timeout just as external events.
+ events cancel this time-out just as external events.
</item>
</taglist>
<p>
@@ -966,7 +966,7 @@ StateName(EventType, EventContent, Data) ->
<seealso marker="#Postponing Events">postponing</seealso>
an event in a <em>state change</em> with starting an
<seealso marker="#Event Time-Outs">event time-out</seealso>
- with time <c>0</c> there will be no timeout event inserted
+ with time <c>0</c> there will be no time-out event inserted
since the event time-out is cancelled by the postponed
event that is delivered due to the state change.
</p>
@@ -1848,7 +1848,7 @@ do_unlock() ->
as the receive statement is within the <c>gen_*</c> engine itself.
It must be there because all
<seealso marker="stdlib:sys"><c>sys</c></seealso>
- compatible behaviors must respond to system messages and therefore
+ compatible behaviours must respond to system messages and therefore
do that in their engine receive loop,
passing non-system messages to the <em>callback module</em>.
</p>