Deploy docs to GitHub Pages 2085239

Author: TolikPylypchuk

articles/async.html

@@ -120,7 +120,7 @@ <h2 id="async-match-expressions">Async Match Expressions</h2>
 pattern is matched successfully (sync actions are turned into async actions).</p>
 <p>Async match expressions can be executed using the <code>ExecuteAsync</code>, <code>ExecuteNonStrictAsync</code> and
 <code>ExecuteWithFallthroughAsync</code> methods.  The <code>ToFunction</code> method and its variations are also available.
-<code>ExecuteWithFallthroughAsync</code> returns an <code>IAsyncEnumerable</code> which enable lazy async execution of match expressions.</p>
+<code>ExecuteWithFallthroughAsync</code> returns an <code>IAsyncEnumerable</code> which enables lazy async execution of match expressions.</p>
 <p>The <code>Matchmaker.Linq</code> namespace contains the <code>EnumerateAsync</code> extension method for <code>IAsyncEnumerable&lt;T&gt;</code> which
 enumerates it and ignores the result. You can use it if you just want to execute the match statement with fall-through.</p>
 <p>Static async match expressions are also available. Use the <code>AsyncMatch.CreateStatic</code> methods to create them, just like

articles/expressions.html

@@ -95,9 +95,9 @@ <h3 id="creating-match-expressions">Creating Match Expressions</h3>
 <p>A match expression can be created using the <code>Create</code> methods of the static class <code>Match</code>.</p>
 <h3 id="adding-cases">Adding Cases</h3>
 <p>The <code>Match</code> classes include <code>Case</code> methods which are used to add a pattern and a function which is executed if the match
-is successful. Match expressions are immutable – <code>Case</code> methods return new match expressions; they do not affect the
+is successful. Match expressions are immutable — <code>Case</code> methods return new match expressions; they do not affect the
 ones on which they are called.</p>
-<p><code>Case</code> methods are generic – they also contain information about the pattern's transformation type. Match expressions
+<p><code>Case</code> methods are generic — they also contain information about the pattern's transformation type. Match expressions
 can contain patterns of arbitrary transformation types without knowing about these types.</p>
 <h3 id="executing-match-expressions">Executing Match Expressions</h3>
 <p>To execute a match expression, the <code>ExecuteOn</code> method is used. It takes the input value to match. There are two modes of
@@ -108,7 +108,7 @@ <h3 id="executing-match-expressions">Executing Match Expressions</h3>
 which executes the match expression in the non-strict mode. It returns <code>MatchResult&lt;TOutput&gt;</code> because the result might
 not be present.</p>
 <p>In the <code>Match&lt;TInput&gt;</code> class, the <code>ExecuteOn</code> method doesn't return anything, and also throws a <code>MatchException</code> if the
-match wasn't successful. This class also contains the <code>ExecuteNonStrict</code> method – it returns a boolean value which
+match wasn't successful. This class also contains the <code>ExecuteNonStrict</code> method — it returns a boolean value which
 indicates whether the match was successful and doesn't throw an exception if it wasn't.</p>
 <p>The <code>ToFunction</code> method and its variations are also available. They return a function which, when called, will execute
 the match expression.</p>
@@ -123,8 +123,8 @@ <h2 id="matching-with-fall-through">Matching with Fall-through</h2>
 is enabled for a pattern, then the expression will continue searching for the next successful pattern. If it isn't, then
 the expression will stop at this pattern and not go any further.</p>
 <p><code>Match.Create</code> is also overloaded to take the default fall-through behavior.</p>
-<p>Matching with fall-through is lazy i.e. it returns an <code>IEnumerable</code> and is only executed when this enumerable is
-enumerated. Because matching will fall-through is lazy, it doesn't have any modes of execution – the user must decide
+<p>Matching with fall-through is lazy, i.e., it returns an <code>IEnumerable</code> and is only executed when this enumerable is
+enumerated. Because matching will fall-through is lazy, it doesn't have any modes of execution — the user must decide
 whether to throw an exception or not if there were no successful matches.</p>
 <p>In the <code>Match&lt;TInput, TOutput&gt;</code> class, the <code>ExecuteWithFallthrough</code> method returns an <code>IEnumerable&lt;TOutput&gt;</code> which can
 be used to get all successful match results.</p>
@@ -178,12 +178,12 @@ <h3 id="the-initialization-problem">The Initialization Problem</h3>
         .ExecuteOn(i);
 </code></pre>
 <p>The problem here is that if we call <code>DoStuff</code> 10,000 times, we will initialize the match expression 10,000 times as
-well, even though it's actually the same expression. Having just 4 cases may not seem like much, but the lag does
-accumulate if we execute it thousands of times.</p>
+well, even though it's actually the same expression. Having just 4 cases may not seem like much, but the lag and
+allocations do accumulate if we execute it thousands of times.</p>
 <p>We can save the expression in a field and then call the <code>ExecuteOn</code> method on this field. But this makes the code much
 less readable because the case definitions are in a different place from the actual execution point.</p>
 <h3 id="the-solution">The Solution</h3>
-<p>There is a way to create static match expressions – expressions which will be initialized only once.</p>
+<p>There is a way to create static match expressions — expressions which will be initialized only once.</p>
 <p>The <code>Match</code> class contains the <code>CreateStatic</code> methods which allow the creation of static match expressions. Take a look
 at the modified example:</p>
 <pre><code class="lang-c#">void DoStuff(int i) =&gt;
@@ -199,7 +199,7 @@ <h3 id="the-solution">The Solution</h3>
 only once, and its initialization code is in the same place as its execution point.</p>
 <p>The parameter of the build action has the type <code>MatchBuilder&lt;TInput, TOutput</code> or <code>MatchBuilder&lt;TInput&gt;</code>, depending on
 which type of match expressions you are building. This type has the same methods for adding cases as the <code>Match</code> classes
-and is mutable – the methods return the same builder instance.</p>
+and is mutable — the methods return the same builder instance.</p>
 <p><code>MatchBuilder</code> also has the <code>Fallthrough</code> method which specifies the default fall-through behavior. But this method
 specifies fall-through behavior only for cases that are defined after it. For example:</p>
 <pre><code class="lang-c#">builder

articles/migration.html

@@ -91,11 +91,11 @@ <h1 id="migration-guide">Migration Guide</h1>
 <a href="https://github.com/TolikPylypchuk/PatternMatching">PatternMatching v1.2.0</a>.</p>
 <p>If you need to migrate from older versions, first migrate to version 1.2.0. You can do that just by reading the
 changelog, because previous versions contained much fewer changes and it's much simpler to migrate.</p>
-<p>In order to migrate from version 2.0.0 to version 2.1.0 action is required only if you implemented the
+<p>In order to migrate from version 2.0.0 to version 2.1.0, action is required only if you implemented the
 <code>IPattern&lt;TInput, TMatchResult&gt;</code> interface (which wasn't recommended). The less generic <code>IPattern&lt;TInput&gt;</code> interface was
 removed, so you should remove its <code>Match</code> method. That's it.</p>
 <p>No changes are required to migrate from version 2.1.0 to 3.1.0. Version 3.0.0 removed support for .NET Standard 2.0, but
-version 3.1.0 added it back, effectively undoing the only breaking change of 3.0.0.</p>
+version 3.1.0 added it back, effectively undoing its only breaking change.</p>
 <h2 id="general">General</h2>
 <p>Since this library has a new name, the namespace is different as well. Instead of the <code>PatternMatching</code> namespace there
 are three namespaces: <code>Matchmaker</code>, <code>Matchmaker.Patterns</code> and <code>Matchmaker.Linq</code>.</p>

articles/patterns.html

@@ -101,9 +101,9 @@ <h2 id="the-ipatterntinput-tmatchresult-interface">The <code>IPattern&lt;TInput,
 <li>Matches the input value with the pattern and returns a successful result if the match is successful.</li>
 <li>Transforms the input value. The returned result contains the transformed value if it's successful.</li>
 </ul>
-<p>Since options are not supported natively in C#, a custom type – <a href="results.html"><code>MatchResult&lt;T&gt;</code></a> – is used.</p>
+<p>Since options are not supported natively in C#, a custom type — <a href="results.html"><code>MatchResult&lt;T&gt;</code></a> — is used.</p>
 <p>The definition of patterns is similar to F#'s active patterns.</p>
-<p>Descriptions for patterns are not terribly important, but can be useful for debugging. As such, they are optional – if
+<p>Descriptions for patterns are not terribly important, but can be useful for debugging. As such, they are optional — if
 you don't want a pattern to have a description, it should be empty. A pattern's description should never be <code>null</code>.</p>
 <h2 id="null-values">Null Values</h2>
 <p>The results of patterns' matching can be <code>null</code>. This is why the <code>MatchResult&lt;T&gt;</code> type can contain a <code>null</code> value.</p>
@@ -131,7 +131,7 @@ <h2 id="linq-to-patterns">LINQ to Patterns</h2>
 <p>The <code>Matchmaker.Linq</code> namespace provides several extension methods for patterns:</p>
 <ul>
 <li><code>Select</code> maps a pattern's result value if it's successful.</li>
-<li><code>Pipe</code> creates a pattern pipeline – the result of the first pattern is the input of the second pattern.</li>
+<li><code>Pipe</code> creates a pattern pipeline — the result of the first pattern is the input of the second pattern.</li>
 <li><code>Cast</code> casts a pattern's result to a specified type. It's the same as piping a pattern to the <code>Type</code> pattern. If the
 input is <code>null</code>, then the match will fail only if the destination type is a non-nullable value type.</li>
 <li><code>Bind</code> flat-maps a pattern's result. If a pattern's result is successful, it calls the specified function and passes
@@ -142,17 +142,17 @@ <h2 id="linq-to-patterns">LINQ to Patterns</h2>
 the input if successful.</li>
 <li><code>Compose</code> is the same as the three methods above, but the composition operator is passed to it as well.</li>
 <li><code>Cached</code> returns a pattern which matches the same as the specified pattern but caches its results in a <code>null</code>-safe
-hash table. Every input will be matched only once – if it's matched again, the result will be taken from the cache. The
+hash table. Every input will be matched only once — if it's matched again, the result will be taken from the cache. The
 caching process is not thread-safe.</li>
 </ul>
 <p>All extension methods for patterns are overloaded to take a custom description.</p>
 <p>Since there are the <code>Select</code> and <code>Where</code> extensions on patterns, you can write them using C#'s query syntax.</p>
 <p>Patterns have the <code>Bind</code> and <code>Return</code> functions, so they are monads. To be more specific, patterns can be thought of as
 a combination of the Reader and Maybe monads.</p>
 <h2 id="immutability">Immutability</h2>
-<p>Every predefined pattern as well as patterns returned by the <code>CreatePattern</code> and extension methods are immutable.
-Calling an extension method on a pattern returns a new pattern – the old one is unchanged.</p>
-<p>An exception is the pattern returned by the <code>Cached</code> method, which is not immutable – it holds a mutable cache. But if a
+<p>All predefined patterns, as well as patterns returned by <code>CreatePattern</code> and extension methods, are immutable. Calling
+an extension method on a pattern returns a new pattern — the old one is unchanged.</p>
+<p>An exception is the pattern returned by the <code>Cached</code> method, which is not immutable — it holds a mutable cache. But if a
 pattern is referentially transparent (its <code>Match</code> method always returns the same result for the same input and doesn't
 have any side effects), then the caching pattern based on it can be thought of as immutable as well, because it doesn't
 matter how many times the base pattern's <code>Match</code> method is called.</p>
@@ -170,7 +170,7 @@ <h3 id="the-easy-way">The Easy Way</h3>
 <h3 id="the-hard-way">The Hard Way</h3>
 <p>If you want something more complex than a single function, you can create a class which extends the
 <code>Matchmaker.Patterns.Pattern&lt;TInput, TMatchResult&gt;</code> class. This is a base class for patterns, and it implements the
-<code>Description</code> property which you don't have to use if you don't want – by default the description is empty, which means
+<code>Description</code> property which you don't have to use if you don't want — by default the description is empty, which means
 that the pattern doesn't have a description.</p>
 <p>You can also implement the <code>IPattern&lt;TInput, TMatchResult&gt;</code> interface directly. There is no reason to do that instead of
 extending the <code>Pattern&lt;TInput, TMatchResult&gt;</code> class unless your class already extends another class. But in that case,

articles/results.html

@@ -98,8 +98,8 @@ <h1 id="match-results">Match Results</h1>
 <li>Users may use a different library/framework for functional features. There are a lot of those for C#.</li>
 </ul>
 <p>So, starting with version 2, instead of using the <code>OptionUnsafe&lt;T&gt;</code> type from language-ext, this library includes a
-<code>MatchResult&lt;T&gt;</code> type. This type is much like optional types from other libraries in that it may contain a value, or may
-not, except for a couple differences:</p>
+<code>MatchResult&lt;T&gt;</code> type. This type works much like optional types from other libraries in that it may contain a value, or
+may not, except for a couple differences:</p>
 <ul>
 <li><code>MatchResult&lt;T&gt;</code> is not a general-purpose optional type and shouldn't be used as such.</li>
 <li><code>MatchResult&lt;T&gt;</code> can contain <code>null</code> values and this is important to remember. This type is not used to avoid

articles/unions.html

@@ -148,7 +148,7 @@ <h1 id="discriminated-unions">Discriminated Unions</h1>
 </code></pre>
 <p>As you can see, we have to throw an exception in the <code>switch</code> version, because C# can't know that <code>ConsCell</code> and <code>Empty</code>
 are the only possible subclasses of <code>ConsList</code>. And for that reason, if we forget to define one of the cases in <code>switch</code>
-or in a match, we'll get an exception. In F# a warning is issued when the match is incomplete, but C# doesn't have the
+or in a match, we'll get an exception. In F#, a warning is issued when the match is incomplete, but C# doesn't have the
 notion of complete or incomplete matches. Of course, this match will fail if the provided list is <code>null</code>, but this can
 be handled using the <code>Null</code> pattern.</p>
 <p>With C# 8, there's a better way to match on discriminated unions, but we still have to explicitly throw an exception in