ploeh blog 2018-07-18T08:06:25+00:00 Mark Seemann danish software design http://blog.ploeh.dk Angular addition monoid http://blog.ploeh.dk/2018/07/16/angular-addition-monoid 2018-07-16T14:40:00+00:00 Mark Seemann <div id="post"> <p> <em>Geometric angles can be added together. Angular addition forms a monoid.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/10/06/monoids">series about monoids</a>. In short, a <em>monoid</em> is an associative binary operation with a neutral element (also known as <em>identity</em>). </p> <p> In geometry, an angle is a measure of how two crossing lines relate to each other. In mathematics, angles are usually represented in radians, but in daily use, they're mostly measured in degrees between 0 and 360. </p> <h3 id="beb83a6d54c6454085e6bf78e381cd9a"> Angular addition <a href="#beb83a6d54c6454085e6bf78e381cd9a" title="permalink">#</a> </h3> <p> You can always draw an angle within a circle. Here's a 45° angle: </p> <p> <img src="/content/binary/angle-45.png" alt="A 45° angle."> </p> <p> If you add another 90° angle to that, you get a 135° angle: </p> <p> <img src="/content/binary/angle-45-90.png" alt="A 45° angle and a 90° angle added to it."> </p> <p> What do you get if you add 90° to 315°? </p> <p> <img src="/content/binary/angle-315-plus-90.png" alt="A 315° angle and a 90° angle next to it."> </p> <p> Well, you get 45°, of course! </p> <p> <img src="/content/binary/angle-315-90.png" alt="A 315° angle and a 90° angle overlaid on the first one."> </p> <p> There's only 360° in a circle, so overflow is handled, in this case, by subtracting 360°. In general, however, angular addition is nothing but modulo 360 addition. </p> <h3 id="53d5cb53bc904c9c8430ed21973fc490"> Angle struct <a href="#53d5cb53bc904c9c8430ed21973fc490" title="permalink">#</a> </h3> <p> You can model a geometric angle as a struct. Here's a simple example: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">struct</span>&nbsp;<span style="color:#2b91af;">Angle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">decimal</span>&nbsp;degrees; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;Angle(<span style="color:blue;">decimal</span>&nbsp;degrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.degrees&nbsp;=&nbsp;degrees&nbsp;%&nbsp;360m; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(<span style="color:blue;">this</span>.degrees&nbsp;&lt;&nbsp;0) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.degrees&nbsp;+=&nbsp;360m; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;FromDegrees(<span style="color:blue;">decimal</span>&nbsp;degrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Angle</span>(degrees); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;FromRadians(<span style="color:blue;">double</span>&nbsp;radians) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Angle</span>((<span style="color:blue;">decimal</span>)((180D&nbsp;/&nbsp;<span style="color:#2b91af;">Math</span>.PI)&nbsp;*&nbsp;radians)); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;Add(<span style="color:#2b91af;">Angle</span>&nbsp;other) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Angle</span>(<span style="color:blue;">this</span>.degrees&nbsp;+&nbsp;other.degrees); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;Identity&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Angle</span>(0); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;Equals(<span style="color:blue;">object</span>&nbsp;obj) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(obj&nbsp;<span style="color:blue;">is</span>&nbsp;<span style="color:#2b91af;">Angle</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;((<span style="color:#2b91af;">Angle</span>)obj).degrees&nbsp;==&nbsp;<span style="color:blue;">this</span>.degrees; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">base</span>.Equals(obj); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">int</span>&nbsp;GetHashCode() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.degrees.GetHashCode(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;<span style="color:blue;">operator</span>&nbsp;==(<span style="color:#2b91af;">Angle</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x.Equals(y); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;<span style="color:blue;">operator</span>&nbsp;!=(<span style="color:#2b91af;">Angle</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;!x.Equals(y); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice the <code>Add</code> method, <a href="http://blog.ploeh.dk/2017/10/06/monoids">which is a binary operation</a>; it's an instance method on <code>Angle</code>, takes another <code>Angle</code> as input, and returns an <code>Angle</code> value. </p> <h3 id="65f48d17d79b4096a8c192ec7675496d"> Associativity <a href="#65f48d17d79b4096a8c192ec7675496d" title="permalink">#</a> </h3> <p> Not only is <code>Add</code> a binary operation; it's also associative. Here's an example: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:#2b91af;">Angle</span>.FromDegrees(135); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:#2b91af;">Angle</span>.FromDegrees(180); <span style="color:blue;">var</span>&nbsp;z&nbsp;=&nbsp;<span style="color:#2b91af;">Angle</span>.FromDegrees(300); <span style="color:blue;">var</span>&nbsp;left&nbsp;&nbsp;=&nbsp;x.Add(y).Add(z); <span style="color:blue;">var</span>&nbsp;right&nbsp;=&nbsp;x.Add(y.Add(z));</pre> </p> <p> Notice that <code>left</code> first evaluates <code>x.Add(y)</code>, which is 315°; then it adds 300°, which is 615°, but normalises to 255°. On the other hand, <code>right</code> first evaluates <code>y.Add(z)</code>, which is 480°, but normalises to 120°. It then adds those 120° to <code>x</code>, for a final result of 255°. Since <code>left</code> and <code>right</code> are both 255°, this illustrates that <code>Add</code> is associative. </p> <p> Obviously, this is only a single example, so it's no proof. While still not a proof, you can demonstrate the associativity property with more confidence by writing a property-based test. Here's one using <a href="https://fscheck.github.io/FsCheck">FsCheck</a> and <a href="https://xunit.github.io">xUnit.net</a>: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AddIsAssociative(<span style="color:#2b91af;">Angle</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.Add(y).Add(z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.Add(y.Add(z))); }</pre> </p> <p> By default, FsCheck generates 100 test cases, but even when I experimentally change the configuration to run 100,000 test cases, they all pass. For full disclosure, however, I'll admit that I defined the data generators to only use <code>NormalFloat</code> for the radian values, and only <code>decimal</code> values with up to 10 decimal places. If you try to use entirely unconstrained floating points, you'll see test failures caused by rounding errors. </p> <p> Changing the data generator is one way to address rounding errors. Another way is to add a bit of fuzzy tolerance to the assertion. In any case, though, the <code>Add</code> operation is associative. That rounding errors occur is an implementation detail of floating point arithmetic. </p> <h3 id="a912f6c80aeb4619b30476e3183edcc9"> Identity <a href="#a912f6c80aeb4619b30476e3183edcc9" title="permalink">#</a> </h3> <p> The above code listing defines a value called <code>Identity</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Angle</span>&nbsp;Identity&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Angle</span>(0);</pre> </p> <p> <em>As an Angle, I want my Add and Identity members to obey the monoid laws so that I can be a monoid.</em> </p> <p> As an example, both <code>left</code> and <code>right</code> should be <code>true</code> in the following: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:#2b91af;">Angle</span>.FromDegrees(370); <span style="color:blue;">var</span>&nbsp;left&nbsp;&nbsp;=&nbsp;x&nbsp;==&nbsp;<span style="color:#2b91af;">Angle</span>.Identity.Add(x); <span style="color:blue;">var</span>&nbsp;right&nbsp;=&nbsp;x&nbsp;==&nbsp;x.Add(<span style="color:#2b91af;">Angle</span>.Identity);</pre> </p> <p> That does, indeed, turn out to be the case. </p> <p> Again, you can generalise using FsCheck: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AddHasIdentity(<span style="color:#2b91af;">Angle</span>&nbsp;x) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;<span style="color:#2b91af;">Angle</span>.Identity.Add(x)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;x.Add(<span style="color:#2b91af;">Angle</span>.Identity)); }</pre> </p> <p> Once more, a reservation identical to the one given above must be given when it comes to floating point arithmetic. </p> <h3 id="c1fd56a6390148b6a74ba539096f8524"> Conclusion <a href="#c1fd56a6390148b6a74ba539096f8524" title="permalink">#</a> </h3> <p> The <code>Add</code> method is an associative, binary operation with identity; it's a monoid. </p> <p> As far as I can tell, any modulo-based addition is a monoid, but while, say, modulo 37 addition probably doesn't have any practical application, modulo 360 addition does, because it's how you do angular addition. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/10/10/strings-lists-and-sequences-as-a-monoid">Strings, lists, and sequences as a monoid</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Typing and testing problem 23 http://blog.ploeh.dk/2018/07/09/typing-and-testing-problem-23 2018-07-09T07:03:00+00:00 Mark Seemann <div id="post"> <p> <em>Yet another reflection on the relationship between types and tests, this time with a simple example.</em> </p> <p> The debate about dynamic typing versus static typing still goes on. If it ever gets resolved, I suppose it'll be in the far future. Until then, one's position is bound to be determined mostly by experience and belief. I openly admit that I prefer statically typed languages like <a href="http://fsharp.org">F#</a> and <a href="https://www.haskell.org">Haskell</a>. </p> <p> As I've <a href="http://blog.ploeh.dk/2016/02/10/types-properties-software">previously touched on</a>, I can't help seeing types as a <a href="https://en.wikipedia.org/wiki/Slider_(computing)">slider</a>. The more to the right you pull it, the stronger the type system. The more to the left you pull it, the more you'll need automated tests to give you a sense of confidence in your code. </p> <p> In this article, I'll share an small revelation recently given to me. </p> <h3 id="16a20a29aa8842ce94d78fba54b0dad9"> Problem 23 <a href="#16a20a29aa8842ce94d78fba54b0dad9" title="permalink">#</a> </h3> <p> Somewhere, a <a href="https://stackoverflow.com">Stack Overflow</a> user was going through <a href="https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems">Ninety-Nine Haskell Problems</a>, and <a href="https://stackoverflow.com/q/46791466/126014">asked how to unit test problem 23</a>. </p> <p> The problem is elementary: <blockquote> <a href="https://wiki.haskell.org/99_questions/21_to_28">"Extract a given number of randomly selected elements from a list."</a> </blockquote> Here's an example of the intended use: </p> <p> <pre>λ&gt; rndSelect "abcdefgh" 3 "fag"</pre> </p> <p> The first argument to <code>rndSelect</code> is the candidates from which to pick elements; in this case the letters <em>a</em> to <em>h</em>. The second argument is the number of values to select; in this case the number <em>3</em>. </p> <h3 id="4d98d4998ffd4721b942a03649007f09"> Test plan <a href="#4d98d4998ffd4721b942a03649007f09" title="permalink">#</a> </h3> <p> How does one test a function like that? Clearly, when randomness is involved, you'll need some way to regulate the randomness in order to <a href="https://martinfowler.com/articles/nonDeterminism.html">make tests deterministic</a>. With my blinders on, I assumed that this was the main problem, so I answered with the following plan for a few properties: <ul> <li>The length of the returned list should be equal to the input length.</li> <li>All elements in the returned list should be elements of the list of candidates.</li> </ul> In addition, I also suggested a way to make tests deterministic, but I'll get back to that later. </p> <p> In response to this plan, the user <a href="https://stackoverflow.com/users/3234959">chi</a> commented on my second suggestion: <blockquote> "I think this it is a consequence of the free theorem. If so, no need to test for that!" </blockquote> Sometimes, I find it difficult to shake my object-oriented TDD-influenced way of thinking, but <em>chi</em> is right. Here's why: </p> <h3 id="1b301d9910e3472c9039094e6e737d91"> Parametric polymorphism <a href="#1b301d9910e3472c9039094e6e737d91" title="permalink">#</a> </h3> <p> .NET, including C# and F#, has a platform feature called <em>generics</em>. Haskell has generics as well, although normally, that language feature is called <em>parametric polymorphism</em>. What I had in mind was a set of parametrically polymorphic functions with these types: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] <span style="color:#2b91af;">rndSelect</span>&nbsp;::&nbsp;<span style="color:blue;">Integral</span>&nbsp;i&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">IO</span>&nbsp;[a]</pre> </p> <p> Notice that both functions return lists of <code>a</code> values, where <code>a</code> is a type variable (in C#, you'd call it a <em>generic type argument</em>). It could be <code>Integer</code>, <code>String</code>, <code>Day</code>, or a custom domain type you'd added to the code base two minutes earlier. </p> <p> Given a completely unrestricted type variable, Haskell has no way of creating values. How could it, logically? </p> <p> In C#, you can write <code>default(T)</code>, which tends to mostly produce null references. Haskell doesn't have null, so with that option cut off, how would it be able to produce values of arbitrary types? It can't. </p> <p> When returning a list of <code>a</code> values, the only option open to a parametric polymorphic function is to pick values from its input arguments. For both <code>rndGenSelect</code> and <code>rndSelect</code>, there's only a single source of <code>a</code> values, so there's no reason to test that the functions return values from those lists of candidates. It's the only thing it can do. That's the <em>free theorem</em> for that function. </p> <p> It'd been an entirely different story if the function had had concrete types. If, for example, the function had had the type <code>RandomGen g =&gt; g -&gt; String -&gt; Int -&gt; String</code>, I could have written a function like this one: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect&#39;</span>&nbsp;::&nbsp;<span style="color:blue;">RandomGen</span>&nbsp;g&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">String</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">Int</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">String</span> rndGenSelect&#39;&nbsp;_&nbsp;_&nbsp;count&nbsp;=&nbsp;<span style="color:blue;">replicate</span>&nbsp;count&nbsp;<span style="color:#a31515;">&#39;s&#39;</span> </pre> </p> <p> Because the type of elements is known at compile-time, we can pick an arbitrary <code>Char</code> value (<code>'s'</code>). This is possible because we know the type, and therefore can come up with a strategy to hard-code known values of that type. When the type argument is unknown, this is no longer possible. To paraphrase <a href="http://thecleancoder.blogspot.dk/2010/11/craftsman-63-specifics-and-generics.html">Robert C. Martin</a>, <em>as the types get more generic, the tests become more redundant</em>. </p> <h3 id="f7624b9d821c40a5b8a26de9f6a74120"> Taming randomness <a href="#f7624b9d821c40a5b8a26de9f6a74120" title="permalink">#</a> </h3> <p> Before we look at automated testing, let's consider how to turn randomness into deterministic behaviour. This is (seemingly) always a problem with unit testing when the desired behaviour contains randomness, because tests should be deterministic. Once again, however, it turns out that <a href="http://blog.ploeh.dk/2015/05/07/functional-design-is-intrinsically-testable">functional design is intrinsically testable</a>. Since Haskell design favours <a href="https://en.wikipedia.org/wiki/Pure_function">pure functions</a>, the core of <code>System.Random</code> is deterministic. </p> <p> This is, in fact, not much different from C#, where <a href="https://msdn.microsoft.com/en-us/library/system.random">the Random class</a> encapsulates an algorithm that computes a series of random-looking values based on an initial seed value. If you give it the same seed, it'll produce the same sequence of random-looking numbers. Haskell works the same way. </p> <p> This led me to a design with a 'core' function that does all the work, and a 'wrapper' function that only adds one extra feature: randomness. </p> <p> Starting my design with types, I wanted a function with this type: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] </pre> </p> <p> This is the type that I've already discussed above. Because of the free theorem, we already know that the returned list can only contain values selected from the input list. In other words, there's no need to test for that. </p> <p> This function takes a <code>RandomGen</code> argument, which is a type class of pure functions. <code>RandomGen</code> itself is pure; the source of randomness comes from how it's produced. More on that later. This, however, should enable me to write deterministic tests. </p> <h3 id="47f98962da4c42beb96e32d2e1ec92ad"> Properties <a href="#47f98962da4c42beb96e32d2e1ec92ad" title="permalink">#</a> </h3> <p> Before we start adding deterministic tests, let's see how far we can get with property-based testing. First, designing with types, I need to implement the function so that it compiles. This is the simplest implementation I could think of: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] rndGenSelect&nbsp;_&nbsp;xs&nbsp;_&nbsp;=&nbsp;[<span style="color:blue;">head</span>&nbsp;xs] </pre> </p> <p> This implementation is both incorrect and unsafe, but it compiles. In TDD fashion, then, I found it appropriate to add a test - in this case a <a href="https://hackage.haskell.org/package/QuickCheck">QuickCheck</a> property: </p> <p> <pre><span style="color:#2b91af;">lenProp</span>&nbsp;::&nbsp;<span style="color:blue;">Integral</span>&nbsp;i&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;<span style="color:#2b91af;">Int</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">NonNegative</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">Bool</span> lenProp&nbsp;seed&nbsp;xs&nbsp;(NonNegative&nbsp;i)&nbsp;= &nbsp;&nbsp;i&nbsp;==&nbsp;genericLength&nbsp;(rndGenSelect&nbsp;(mkStdGen&nbsp;seed)&nbsp;xs&nbsp;i) </pre> </p> <p> This little piece of test code is the only surviving property from my original test plan. It states that for any non-negative count, the list returned from <code>rndGenSelect</code> should have the requested length. </p> <p> Writing this property, however, quickly forced me to deal with the case where the count is negative. It's easy to forget about edge cases when your function is nothing but a pie in the sky, but QuickCheck (and property-based testing in general) is really effective at grounding you in reality. Even with a language like Haskell, I still find the fast feedback loop from tests helpful. </p> <p> The original exercise specification doesn't mention what should happen if the count is negative, so after short deliberation, I decide to write another property: </p> <p> <pre><span style="color:#2b91af;">negLenProp</span>&nbsp;::&nbsp;<span style="color:blue;">Integral</span>&nbsp;i&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;<span style="color:#2b91af;">Int</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">Positive</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">Bool</span> negLenProp&nbsp;seed&nbsp;xs&nbsp;(Positive&nbsp;i)&nbsp;= &nbsp;&nbsp;0&nbsp;==&nbsp;genericLength&nbsp;(rndGenSelect&nbsp;(mkStdGen&nbsp;seed)&nbsp;xs&nbsp;(-i)) </pre> </p> <p> This property simply states that for all negative counts, the returned list should be empty. </p> <p> Both of these properties obviously fail, because of the incorrect implementation. </p> <p> The simplest implementation I could think of that passes both properties is this: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] rndGenSelect&nbsp;_&nbsp;xs&nbsp;count&nbsp;=&nbsp;genericReplicate&nbsp;count&nbsp;(<span style="color:blue;">head</span>&nbsp;xs) </pre> </p> <p> At this point, I don't see how TDD or property-based testing can help me move forward. The remaining work required is to add randomness to the mix. In this case, I'll need to use the <code>RandomGen</code> argument to produce random values, but since I don't know how its algorithm works, then even if I had a seed value known at compile-time, I wouldn't be able to predict which values it'd produce. </p> <h3 id="9e2a643290b14a53bf8fc82d8773bb08"> Selecting random indices <a href="#9e2a643290b14a53bf8fc82d8773bb08" title="permalink">#</a> </h3> <p> I admit that I don't know how to write the next test a priori. I do know, however, that if I implement what's missing, I have a deterministic function, and I can use it to write regression test. In other words, I'll reverse direction and write the code first, and then the test. What a novel idea. </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] rndGenSelect&nbsp;rnd&nbsp;xs&nbsp;count&nbsp;= &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;indices&nbsp;=&nbsp;genericTake&nbsp;count&nbsp;$&nbsp;randomRs&nbsp;(0,&nbsp;<span style="color:blue;">length</span>&nbsp;xs&nbsp;-&nbsp;1)&nbsp;rnd &nbsp;&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">fmap</span>&nbsp;(xs&nbsp;!!)&nbsp;indices </pre> </p> <p> This function first uses <code>randomRs</code> to produce an infinite list of values. These values are indices because they all fall between <code>0</code> and <code>length xs - 1</code>. In other words, they are indices into <code>xs</code>. </p> <p> While the list is infinite, it's lazily evaluated, so infinity itself isn't a problem. We only need <code>count</code> elements, though, so we can simply take the first <code>count</code> elements. </p> <p> Finally, the function maps over the list of indices, and for each index value, selects the element at that position. </p> <p> I could inline <code>indices</code> in the return expression, like this: </p> <p> <pre><span style="color:#2b91af;">rndGenSelect</span>&nbsp;::&nbsp;(<span style="color:blue;">RandomGen</span>&nbsp;g,&nbsp;<span style="color:blue;">Integral</span>&nbsp;i)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;g&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[a] rndGenSelect&nbsp;rnd&nbsp;xs&nbsp;count&nbsp;= &nbsp;&nbsp;<span style="color:blue;">fmap</span>&nbsp;(xs&nbsp;!!)&nbsp;$&nbsp;genericTake&nbsp;count&nbsp;$&nbsp;randomRs&nbsp;(0,&nbsp;<span style="color:blue;">length</span>&nbsp;xs&nbsp;-&nbsp;1)&nbsp;rnd </pre> </p> <p> I find that more obscure than the first alternative, though, but both versions pass the properties and do what they're supposed to do. </p> <h3 id="c2e15aa34c4e4cb5bc0f7ad11580b711"> Regression testing <a href="#c2e15aa34c4e4cb5bc0f7ad11580b711" title="permalink">#</a> </h3> <p> How do I know that my code works? Well, that's always difficult with code that contains randomness, but you can load the function into GHCi and perform some <a href="https://en.wikipedia.org/wiki/Sanity_check">sanity testing</a>: </p> <p> <pre>λ&gt; rndGenSelect (mkStdGen 42) "foo" 3 "ofo" λ&gt; rndGenSelect (mkStdGen 1337) "bar" 10 "rabbaarrra" λ&gt; rndGenSelect (mkStdGen (-197221)) ['a'..'z'] 5 "ntfnc"</pre> </p> <p> That looks, I suppose, random enough... What's more important is that this is completely repeatable. This means that I can write <a href="http://blog.ploeh.dk/2018/04/30/parametrised-unit-tests-in-haskell">parametrised tests</a> that protect against regressions: </p> <p> <pre><span style="color:#a31515;">&quot;rndGenSelect&nbsp;of&nbsp;chars&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;~:&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;(seed,&nbsp;xs,&nbsp;count,&nbsp;expected)&nbsp;&lt;- &nbsp;&nbsp;&nbsp;&nbsp;[ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;42,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;foo&quot;</span>,&nbsp;&nbsp;3,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;ofo&quot;</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;1337,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;bar&quot;</span>,&nbsp;10,&nbsp;<span style="color:#a31515;">&quot;rabbaarrra&quot;</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(-197221,&nbsp;[<span style="color:#a31515;">&#39;a&#39;</span>..<span style="color:#a31515;">&#39;z&#39;</span>],&nbsp;&nbsp;5,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;ntfnc&quot;</span>) &nbsp;&nbsp;&nbsp;&nbsp;] &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;rnd&nbsp;=&nbsp;mkStdGen&nbsp;seed &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;=&nbsp;rndGenSelect&nbsp;rnd&nbsp;xs&nbsp;count &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;expected&nbsp;~=?&nbsp;actual </pre> </p> <p> These tests don't drive the design, but they prevent regressions. If, at a later time, I, or someone else, inadvertently revert <code>rndGenSelect</code> to <code>genericReplicate count (head xs)</code>, these tests will fail. </p> <h3 id="2f404b7e4e9c4b22ace4b0e738c58233"> Humble function <a href="#2f404b7e4e9c4b22ace4b0e738c58233" title="permalink">#</a> </h3> <p> The original problem statement is to write a function without an explicit <code>RandomGen</code> argument. In the spirit of <a href="http://bit.ly/xunitpatterns">xUnit Test Patterns'</a> <em>Humble Object</em> pattern, we can now click all our pieces together to a function that does what is required: </p> <p> <pre><span style="color:#2b91af;">rndSelect</span>&nbsp;::&nbsp;<span style="color:blue;">Integral</span>&nbsp;i&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;[a]&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;i&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:#2b91af;">IO</span>&nbsp;[a] rndSelect&nbsp;xs&nbsp;count&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;rnd&nbsp;&lt;-&nbsp;newStdGen &nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;rndGenSelect&nbsp;rnd&nbsp;xs&nbsp;count </pre> </p> <p> The only thing of interest here is that the function is impure, because it uses <code>newStdGen</code> to produce a random <code>RandomGen</code> value. It then delegates all work to <code>rndGenSelect</code>, which is covered by tests. </p> <p> As you can see, this function does <em>not</em> exhibit repeatable behaviour: </p> <p> <pre>λ&gt; rndSelect "abcdefgh" 3 "add" λ&gt; rndSelect "abcdefgh" 3 "daf"</pre> </p> <p> This should, I think, address the original problem statement. </p> <p> All source code for this article is <a href="https://github.com/ploeh/HasProblem23">available on GitHub</a>. </p> <h3 id="db2d673115f24bd2b4f4cbedae738342"> Summary <a href="#db2d673115f24bd2b4f4cbedae738342" title="permalink">#</a> </h3> <p> The first time I encountered parametric polymorphism was when C# got generics in 2005. Back then it was mostly explained as a mechanism to avoid <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing">boxing</a>, although it also seriously reduced the amount of boilerplate code you'd have to write in order to have type-safe collections. In many years, I mostly understood C# generics as a language feature aimed at efficiency and programmer productivity. </p> <p> It wasn't until I started to program in F#, with its stronger type inference, that it began to dawn on me that parametric polymorphism could also be a design tool. Making a function more generic tightens its contract, so to speak. The more generic a function becomes, the less wriggle room does it have. This may sound like a disadvantage to a programmer, but it's a boon to a <em>code reader</em>. When you, as a reader, encounter a parametrically polymorphic function, you already know that there are things that function can't do. Such functions come with invariants, or 'theorems', for free. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Terse operators make business code more readable http://blog.ploeh.dk/2018/07/02/terse-operators-make-business-code-more-readable 2018-07-02T12:00:00+00:00 Mark Seemann <div id="post"> <p> <em>Sometimes, terse operators can make code more readable. An article for all, even people who don't read Haskell code.</em> </p> <p> The <a href="https://www.haskell.org">Haskell</a> programming language has a reputation for being terse to the point of being unreadable. That reputation isn't undeserved, but to counter, other languages exist that are verbose to the point of being unreadable. </p> <p> Particularly, <a href="http://blog.ploeh.dk/2015/08/03/idiomatic-or-idiosyncratic">idiomatic</a> Haskell code involves abstruse operators like <code>.</code>, <code>$</code>, <code>&lt;$&gt;</code>, <code>&gt;&gt;=</code>, <code>&lt;*&gt;</code>, <code>&lt;&gt;</code>, and so on. Not only do such operators look scary, but when I started writing Haskell code, it also bothered me that I didn't know how to pronounce these operators. I don't know how you read code, but my brain often tries to 'talk' about the code, silently, inside my head, and when it encounters something like <code>=&lt;&lt;</code>, it tends to stumble. </p> <p> At least, it used to. These days, my brain has accepted that in many cases, Haskell operators are a little like punctuation marks. When I read a piece of prose, my brain doesn't insist on 'saying' <em>comma</em>, <em>semicolon</em>, <em>question mark</em>, <em>period</em>, etcetera. Such symbols assist reading, and often adjust the meaning of a text, but aren't to be read explicitly as themselves. </p> <p> I'm beginning to realise that Haskell operators work like that; sometimes, they fade into the background and assist reading. </p> <p> As a word of caution, don't take this analogy literally. Each Haskell operator means something specific, and they aren't interchangeable. Additionally, Haskell enables you to add your own custom operators, and I'm not sure that e.g. <a href="https://hackage.haskell.org/package/lens/docs/Control-Lens.html">lens</a> operators like <code>.~</code> or <code>%~</code> make code more readable. </p> <h3 id="53a6bd351c814befaa7d32e57a563f5a"> A simple business code example <a href="#53a6bd351c814befaa7d32e57a563f5a" title="permalink">#</a> </h3> <p> Forgetting about the lens operators, though, consider a piece of business code like this: </p> <p> <pre><span style="color:#2b91af;">tryAccept</span>&nbsp;::&nbsp;<span style="color:#2b91af;">Int</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">Reservation</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">MaybeT</span>&nbsp;<span style="color:blue;">ReservationsProgram</span>&nbsp;<span style="color:#2b91af;">Int</span> tryAccept&nbsp;capacity&nbsp;reservation&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;guard&nbsp;=&lt;&lt;&nbsp;isReservationInFuture&nbsp;reservation &nbsp;&nbsp;reservations&nbsp;&lt;-&nbsp;readReservations&nbsp;$&nbsp;reservationDate&nbsp;reservation &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;reservedSeats&nbsp;=&nbsp;<span style="color:blue;">sum</span>&nbsp;$&nbsp;reservationQuantity&nbsp;&lt;$&gt;&nbsp;reservations &nbsp;&nbsp;guard&nbsp;$&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;&lt;=&nbsp;capacity &nbsp;&nbsp;create&nbsp;$&nbsp;reservation&nbsp;{&nbsp;reservationIsAccepted&nbsp;=&nbsp;True&nbsp;}</pre> </p> <p> Please read on, even if you don't read Haskell code. I'm not going to walk you through the details of how the operators work. That's not the point of this article. The point is how the operators enable you to focus on the overall picture of what's going on. </p> <p> To establish a bit of context, this function determines whether or not to accept a restaurant reservation. Even if you've never read Haskell code before, see if you can get a <em>sense</em> of what's going on. </p> <p> First, there's a <code>guard</code> which seems to involve whether or not the reservation is in the future. Second, there seems to be some calculations involving reservations, reserved seats, culminating in another <code>guard</code>. Third, the function seems to <code>create</code> a reservation by setting <code>reservationIsAccepted</code> to <code>True</code>. </p> <p> Granted, it probably helps if you know that both <code>=</code> and <code>&lt;-</code> bind the left-hand symbol to the expression on the right side. Additionally, after all this talk about special Haskell operators, it may not be immediately apparent that <code>+</code> is the perfectly normal addition operator, and <code>&lt;=</code> is the well-known <em>less-than-or-equal</em> relational operator. What if we keep those operators, and mask the rest with a white rectangle symbol (▯)? </p> <p> <pre><span style="color:#2b91af;">tryAccept</span>&nbsp;::&nbsp;<span style="color:#2b91af;">Int</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">Reservation</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:blue;">MaybeT</span>&nbsp;<span style="color:blue;">ReservationsProgram</span>&nbsp;<span style="color:#2b91af;">Int</span> tryAccept&nbsp;capacity&nbsp;reservation&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;guard&nbsp;▯&nbsp;isReservationInFuture&nbsp;reservation &nbsp;&nbsp;reservations&nbsp;&lt;-&nbsp;readReservations&nbsp;▯&nbsp;reservationDate&nbsp;reservation &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;reservedSeats&nbsp;=&nbsp;<span style="color:blue;">sum</span>&nbsp;▯&nbsp;reservationQuantity&nbsp;▯&nbsp;reservations &nbsp;&nbsp;guard&nbsp;▯&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;&lt;=&nbsp;capacity &nbsp;&nbsp;create&nbsp;▯&nbsp;reservation&nbsp;{&nbsp;reservationIsAccepted&nbsp;=&nbsp;True&nbsp;}</pre> </p> <p> Finally, you also ought to know that while Haskell code is read from top to bottom, you tend to read each expression from right to left. Armed with this knowledge, and by masking the operators, the business logic begins to stand out. </p> <p> First, it examines whether the <code>reservation</code> is in the future, and it does a <code>guard</code> of that. Again, I don't wish to make any claims that the code is magically self-documenting, because if you don't know what <code>guard</code> does, you don't know if this expression guards <em>against</em> the reservation being in the future, or if, conversely, it ensures that the reservation is in the future. It does the latter. </p> <p> Second, it conjures up some <code>reservations</code> from somewhere, by first getting the <code>reservationDate</code> from <code>reservation</code>, and then passing that value to <code>readReservations</code> (expressions are read from right to left). </p> <p> Moving on, it then calculates <code>reservedSeats</code> by starting with <code>reservations</code>, somehow extracting the <code>reservationQuantity</code> from those, and taking the <code>sum</code>. Since we've masked the operators, you can't tell exactly what's going on, but the gist is, hopefully, clear. </p> <p> The middle block of code concludes with another <code>guard</code>, this time ensuring that the <code>reservedSeats</code> plus the <code>reservationQuantity</code> is less than or equal to the <code>capacity</code>. </p> <p> Finally, the function sets <code>reservationIsAccepted</code> to <code>True</code> and calls <code>create</code>. </p> <p> What I find compelling about this is that the terseness of the Haskell operators enables you, a code reader, to scan the code to first understand the big picture. </p> <h3 id="16ce35c687e04ad1be79942884c27ccd"> Guards <a href="#16ce35c687e04ad1be79942884c27ccd" title="permalink">#</a> </h3> <p> Additionally, some common motifs begin to stand out. For example, there are two <code>guard</code> expressions. Because the operators are terse, the similarities stand out better. Let's juxtapose them: </p> <p> <pre>&nbsp;&nbsp;guard&nbsp;▯&nbsp;isReservationInFuture&nbsp;reservation &nbsp;&nbsp;guard&nbsp;▯&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;&lt;=&nbsp;capacity</pre> </p> <p> It seems clear that the same sort of thing is going on in both cases. There's a guard ensuring that a Boolean condition is satisfied. If you, however, reconsider the actual code, you'll see that the white rectangle hides two different operators: </p> <p> <pre>&nbsp;&nbsp;guard&nbsp;=&lt;&lt;&nbsp;isReservationInFuture&nbsp;reservation &nbsp;&nbsp;guard&nbsp;$&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;&lt;=&nbsp;capacity</pre> </p> <p> The reason for this is that it has to, because otherwise it wouldn't compile. <code>isReservationInFuture reservation</code> has the type <code>MaybeT ReservationsProgram Bool</code>. There's a Boolean value hidden in there, but it's buried inside a container. Using <code>=&lt;&lt;</code> enables you to pull out the Boolean value and pass it to <code>guard</code>. </p> <p> In the second <code>guard</code> expression, <code>reservedSeats + reservationQuantity&nbsp;reservation &lt;= capacity</code> is a 'naked' Boolean expression, so in this case you can use the <code>$</code> operator to pass it to <code>guard</code>. </p> <p> Haskellers may wonder why I chose <code>=&lt;&lt;</code> instead of the more common <code>&gt;&gt;=</code> operator in the first of the two <code>guard</code> expressions. I could have, but then the expression would have been this: </p> <p> <pre>&nbsp;&nbsp;isReservationInFuture&nbsp;reservation&nbsp;&gt;&gt;=&nbsp;guard</pre> </p> <p> The resulting behaviour is the same, but I think this obscures how the two <code>guard</code> expressions are variations on the same motif. </p> <p> The use of operators enables you to express code in such a way that motifs stand out. In contrast, I tried writing the same business functionality in <a href="http://fsharp.org">F#</a>, but it didn't come out as readable (in my opinion): </p> <p> <pre><span style="color:green;">//&nbsp;int&nbsp;-&gt;&nbsp;Reservation&nbsp;-&gt;&nbsp;ReservationsProgram&lt;int&nbsp;option&gt;</span> <span style="color:blue;">let</span>&nbsp;tryAccept&nbsp;capacity&nbsp;reservation&nbsp;=&nbsp;reservationsOption&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">do!</span>&nbsp;ReservationsOption.bind&nbsp;guard&nbsp;&lt;|&nbsp;isReservationInFuture&nbsp;reservation &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let!</span>&nbsp;reservations&nbsp;=&nbsp;readReservations&nbsp;reservation.Date &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;reservedSeats&nbsp;=&nbsp;List.sumBy&nbsp;(<span style="color:blue;">fun</span>&nbsp;r&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;r.Quantity)&nbsp;reservations &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">do!</span>&nbsp;guard&nbsp;(reservedSeats&nbsp;+&nbsp;reservation.Quantity&nbsp;&lt;=&nbsp;capacity) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return!</span>&nbsp;create&nbsp;{&nbsp;reservation&nbsp;<span style="color:blue;">with</span>&nbsp;IsAccepted&nbsp;=&nbsp;<span style="color:blue;">true</span>&nbsp;}&nbsp;}</pre> </p> <p> While you can also define custom operators in F#, it's rarely a good idea, for various reasons that, at its core, are related to how F# isn't Haskell. The lack of 'glue' operators in F#, though, obliged me to instead use the more verbose <code>ReservationsOption.bind</code>. This adds noise to the degree that the <code>guard</code> function disappears in the middle of the expression. The motif is fainter. </p> <h3 id="e476da4f87144f1d8b3c4f0766aab85e"> Piping <a href="#e476da4f87144f1d8b3c4f0766aab85e" title="permalink">#</a> </h3> <p> Another motif in Haskell code is <em>piping</em>. This is known from F# as well, where piping is normally done from left to right using the <code>|&gt;</code> operator. You can, as the above example shows, also use the right-to-left pipe operator <code>&lt;|</code>. In Haskell, expressions are idiomatically composed from right to left, often with the <code>$</code> operator, or, when using <a href="https://en.wikipedia.org/wiki/Tacit_programming">point-free</a> style, with the <code>.</code> operator. </p> <p> Once you realise that expressions compose from right to left, a masked expression like <code>sum ▯ reservationQuantity ▯ reservations</code> begins to look like a pipeline: start with <code>reservations</code>, somehow pipe them to <code>reservationQuantity</code>, and finally pipe the result of doing that to <code>sum</code>. That's actually not quite what happens, but I think that this compellingly communicates the overall idea: start with some reservations, consider their quantities, and calculate the sum of those. </p> <p> Another way to write that expression would be: </p> <p> <pre>&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;reservedSeats&nbsp;=&nbsp;<span style="color:blue;">sum</span>&nbsp;(<span style="color:blue;">fmap</span>&nbsp;reservationQuantity&nbsp;reservations)</pre> </p> <p> This implements the same behaviour as <code>sum $ reservationQuantity &lt;$&gt; reservations</code>, but once you get used to it, I like the operator-based alternative better. The operators fade into the background, enabling the flow of data to stand out better. </p> <h3 id="c78436b5007d4f569b5d619feb090caf"> Conclusion <a href="#c78436b5007d4f569b5d619feb090caf" title="permalink">#</a> </h3> <p> Haskell operators constitute the glue that enables you to compose expressions together. Often, you need to vary how expressions are composed together, because the types are slightly different. Picking an appropriate operator that composes particular expressions enables you to perform the composition with a high signal-to-noise ratio. </p> <p> Once you get used to reading Haskell code, the operators can fade into the background in well-factored code, just like punctuation marks assist you when you read prose. As always, this is no silver bullet. I've seen plenty of examples of obscure Haskell code as well, and copious use of operators is a fast way to obfuscate code. </p> <p> Use; punctuation? marks with. taste! </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Visitor as a sum type http://blog.ploeh.dk/2018/06/25/visitor-as-a-sum-type 2018-06-25T14:31:00+00:00 Mark Seemann <div id="post"> <p> <em>The Visitor design pattern is isomorphic to sum types.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions">a series of articles about specific design patterns and their category theory counterparts</a>. In it, you'll see how the <a href="https://en.wikipedia.org/wiki/Visitor_pattern">Visitor design pattern</a> is equivalent to a <a href="https://en.wikipedia.org/wiki/Tagged_union">sum type</a>. </p> <h3 id="ddc4643ff60949c382a9b631fe427cdd"> Sum types <a href="#ddc4643ff60949c382a9b631fe427cdd" title="permalink">#</a> </h3> <p> I think that the most important advantage of a statically typed programming language is that it gives you <a href="http://blog.ploeh.dk/2011/04/29/Feedbackmechanismsandtradeoffs">immediate feedback</a> on your design and implementation work. Granted, that your code compiles may not be enough to instil confidence that you've done the right thing, but it's obvious that when your code doesn't compile, you still have work to do. </p> <p> A static type system enables you to catch some programming errors at compile time. It prevents you from making obvious mistakes like trying to divide a <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">GUID</a> by a date. Some type systems don't offer much more help than that, while others are more articulate; I think that <a href="http://blog.ploeh.dk/2016/02/10/types-properties-software">type systems inhabit a continuous spectrum of capabilities</a>, although that, too, is a simplification. </p> <p> An often-touted advantage of programming languages like <a href="http://fsharp.org">F#</a>, <a href="https://ocaml.org">OCaml</a>, and <a href="https://www.haskell.org">Haskell</a> is that they, in the words of <a href="https://twitter.com/yminsky">Yaron Minsky</a>, enable you to <em>make illegal states unrepresentable</em>. The way these languages differ from languages like C# and Java is that they have <a href="https://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data types</a>. </p> <p> In short, algebraic data types distinguishes between <a href="https://en.wikipedia.org/wiki/Product_type">product types</a> and sum types. All statically typed language I've seen have product types, which you can think of as combinations of data. Objects with more than a single class fields would be product types. </p> <p> Sum types (also known as <em>discriminated unions</em>), on the other hand, are types that express mutually exclusive alternatives. Object-oriented programmers might mistake such a statement for sub-classing, but the difference is that object-oriented sub-classing creates a potentially infinite hierarchy of subtypes, while a sum type is statically constrained to a finite number of mutually exclusive cases. This is often useful. </p> <p> In this article, you'll see that a sum type is isomorphic to a corresponding Visitor. </p> <h3 id="dac9a78ee087418193fd776ceeade06b"> Church-encoded payment types <a href="#dac9a78ee087418193fd776ceeade06b" title="permalink">#</a> </h3> <p> In a previous article, you saw how to <a href="http://blog.ploeh.dk/2018/06/18/church-encoded-payment-types">Church-encode a domain-specific sum type</a>. That article, again, demonstrated how to rewrite <a href="http://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-types">a domain-specific F# discriminated union</a> as a C# API. The F# type was this <code>PaymentType</code> sum type: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;<span style="color:teal;">PaymentType</span>&nbsp;= |&nbsp;<span style="color:navy;">Individual</span>&nbsp;<span style="color:blue;">of</span>&nbsp;<span style="color:teal;">PaymentService</span> |&nbsp;<span style="color:navy;">Parent</span>&nbsp;<span style="color:blue;">of</span>&nbsp;<span style="color:teal;">PaymentService</span> |&nbsp;<span style="color:navy;">Child</span>&nbsp;<span style="color:blue;">of</span>&nbsp;originalTransactionKey&nbsp;:&nbsp;<span style="color:teal;">string</span>&nbsp;*&nbsp;paymentService&nbsp;:&nbsp;<span style="color:teal;">PaymentService</span></pre> </p> <p> Using Church-encoding in C#, you can arrive at this interface that models the same business problem: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child); }</pre> </p> <p> In order to use the API, the compiler obligates you to handle all three mutually exclusive cases defined by the three arguments to the <code>Match</code> method. Refer to the previous article for more details and code examples. All <a href="https://github.com/ploeh/ChurchEncoding">the C# code is also available on GitHub</a>. </p> <p> While the C# code works, I think it'd be a fair criticism to say that it doesn't feel object-oriented. Particularly the use of function delegates (<code>Func&lt;PaymentService, T&gt;</code>, etcetera) seems off. These days, C# is a multi-paradigmatic language, and function delegates have been around since 2007, so it's a perfectly fine C# design. Still, if we're trying to understand how object-oriented programming relates to fundamental programming abstractions, it behoves us to consider a more classic form of object-orientation. </p> <h3 id="19be9752ec8a44e18995db6c96c99bfe"> Introduce Parameter Object <a href="#19be9752ec8a44e18995db6c96c99bfe" title="permalink">#</a> </h3> <p> Through a series of refactorings you can transform the Church-encoded <code>IPaymentType</code> interface to a Visitor. The first step is to use <a href="http://amzn.to/YPdQDf">Refactoring</a>'s <em>Introduce Parameter Object</em> to turn the three method arguments of <code>Match</code> into a single object: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;PaymentTypeParameters( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Individual&nbsp;=&nbsp;individual; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Parent&nbsp;=&nbsp;parent; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Child&nbsp;=&nbsp;child; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;Individual&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;Parent&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;Child&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> The modified <code>IPaymentType</code> interface then looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">PaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;parameters); }</pre> </p> <p> Clearly, this change means that you must also adjust each implementation of <code>IPaymentType</code> accordingly. Here's the <code>Match</code> method of <code>Individual</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">PaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;parameters) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;parameters.Individual(paymentService); }</pre> </p> <p> The two other implementations (<code>Parent</code> and <code>Child</code>) change in the same way; the modifications are trivial, so I'm not going to show them here, but all the code is <a href="https://github.com/ploeh/ChurchEncoding/commit/64fa2638ffbdb81a077ac1dc3fbce697b3cba35b">available as a single commit</a>. </p> <p> Likewise, client code that uses the API needs adjustment, like the <code>ToJson</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;ToJson(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span>&nbsp;payment) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;payment.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentTypeParameters</span>&lt;<span style="color:#2b91af;">PaymentJsonModel</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;individual&nbsp;:&nbsp;ps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;ps.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;ps.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;parent&nbsp;:&nbsp;ps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;ps.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;ps.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;child&nbsp;:&nbsp;cps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;cps.PaymentService.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;cps.PaymentService.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">string</span>&gt;(cps.OriginalTransactionKey) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;})); }</pre> </p> <p> From <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">argument list isomorphisms</a> we know that an argument list is isomorphic to a Parameter Object, so this step should come as no surprise. We also know that the reverse translation (from Parameter Object to argument list) is possible. </p> <h3 id="496f81b27ad64feaaf0705eab578d9e8"> Add Run prefix <a href="#496f81b27ad64feaaf0705eab578d9e8" title="permalink">#</a> </h3> <p> I think it looks a little strange that the functions comprising <code>PaymentTypeParameters&lt;T&gt;</code> are named <code>Individual</code>, <code>Parent</code>, and <code>Child</code>. Functions <em>do</em> something, so they ought to be named with verbs. This turns out only to be an intermediary step, but I'll add the prefix <code>Run</code> to all three: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;PaymentTypeParameters( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RunIndividual&nbsp;=&nbsp;individual; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RunParent&nbsp;=&nbsp;parent; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RunChild&nbsp;=&nbsp;child; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;RunIndividual&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;RunParent&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;RunChild&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> This doesn't change the structure of the code in any way, but sets it up for the next step. </p> <h3 id="690e226135a8414fbb122ffe834a5e87"> Refactor to interface <a href="#690e226135a8414fbb122ffe834a5e87" title="permalink">#</a> </h3> <p> The definition of <code>PaymentTypeParameters&lt;T&gt;</code> still doesn't look object-oriented. While it's formally an object, it's an object that composes three function delegates. We've managed to move the function delegates around, but we haven't managed to get rid of them. From <a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">object isomorphisms</a>, however, we know that tuples of functions are isomorphic to objects, and that's essentially what we have here. In this particular case, there's no implementation code in <code>PaymentTypeParameters&lt;T&gt;</code> itself - it's nothing but a group of three functions. You can refactor that class to an interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;RunIndividual(<span style="color:#2b91af;">PaymentService</span>&nbsp;individual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;RunParent(<span style="color:#2b91af;">PaymentService</span>&nbsp;parent); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;RunChild(<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;child); }</pre> </p> <p> The implementations of <code>Individual</code>, <code>Parent</code>, and <code>Child</code> don't change; only the signature of <code>Match</code> changes slightly: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">IPaymentTypeParameters</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;parameters); }</pre> </p> <p> Since this change removes the function delegates, it requires client code to change: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;ToJson(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span>&nbsp;payment) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;payment.Match(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentTypeToJsonParameters</span>()); } <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentTypeToJsonParameters</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IPaymentTypeParameters</span>&lt;<span style="color:#2b91af;">PaymentJsonModel</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;RunIndividual(<span style="color:#2b91af;">PaymentService</span>&nbsp;individual) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;individual.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;individual.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;RunParent(<span style="color:#2b91af;">PaymentService</span>&nbsp;parent) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;parent.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;parent.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;RunChild(<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;child.PaymentService.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;child.PaymentService.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">string</span>&gt;(child.OriginalTransactionKey) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>ToJson</code> method now has to delegate to a <code>private</code> class that implements <code>IPaymentTypeParameters&lt;PaymentJsonModel&gt;</code>. In Java and F# you'd be able to pass an object expression, but in C# you have to create an explicit class for the purpose. The implementations of the three methods of the interface still correspond to the three functions the previous incarnations of the code used. </p> <h3 id="ca0c6f3576c74786b738f04904d79fb8"> Rename to Visitor <a href="#ca0c6f3576c74786b738f04904d79fb8" title="permalink">#</a> </h3> <p> At this point, the Visitor pattern's structure is already in place. The only remaining step is to rename the various parts of the API so that this becomes clear. You can start by renaming the <code>IPaymentTypeParameters&lt;T&gt;</code> interface to <code>IPaymentTypeVisitor&lt;T&gt;</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentTypeVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;VisitIndividual(<span style="color:#2b91af;">PaymentService</span>&nbsp;individual); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;VisitParent(<span style="color:#2b91af;">PaymentService</span>&nbsp;parent); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;VisitChild(<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;child); }</pre> </p> <p> Notice that I've also renamed the methods from <code>RunIndividual</code>, <code>RunParent</code>, and <code>RunChild</code> to <code>VisitIndividual</code>, <code>VisitParent</code>, and <code>VisitChild</code>. </p> <p> Likewise, you can rename the <code>Match</code> method to <code>Accept</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Accept&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">IPaymentTypeVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor); }</pre> </p> <p> In <a href="http://amzn.to/XBYukB">Design Patterns</a>, the Visitor design pattern is only described in such a way that both <code>Accept</code> and <code>Visit</code> methods have <code>void</code> return types, but from <a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">unit isomorphisms</a> we know that this is equivalent to returning <em>unit</em>. Thus, setting <code>T</code> in the above API to a suitable <em>unit</em> type (like the one defined in F#), you arrive at the canonical Visitor pattern. The generic version here is simply a generalisation. </p> <p> For the sake of completeness, client code now looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;ToJson(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span>&nbsp;payment) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;payment.Accept(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentTypeToJsonVisitor</span>()); } <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentTypeToJsonVisitor</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IPaymentTypeVisitor</span>&lt;<span style="color:#2b91af;">PaymentJsonModel</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;VisitIndividual(<span style="color:#2b91af;">PaymentService</span>&nbsp;individual) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;individual.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;individual.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;VisitParent(<span style="color:#2b91af;">PaymentService</span>&nbsp;parent) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;parent.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;parent.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;VisitChild(<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;child.PaymentService.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;child.PaymentService.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">string</span>&gt;(child.OriginalTransactionKey) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> You can refactor all the <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">other Church encoding examples I've shown you</a> to Visitor implementations. It doesn't always make the code more readable, but it's possible. </p> <h3 id="38f9e2c752e64c748d1799c2e32f37c1"> From Visitor to sum types <a href="#38f9e2c752e64c748d1799c2e32f37c1" title="permalink">#</a> </h3> <p> In this article, I've shown how to refactor from a Church-encoded sum type to a Visitor, using the following refactoring steps: <ol> <li>Introduce Parameter Object</li> <li>(Rename Method (by adding a <code>Run</code> prefix))</li> <li>Refactor to interface</li> <li>Rename to Visitor terminology</li> </ol> All those steps are, I believe, isomorphic, in that they have reverse translations. Thus, since (according to <a href="http://amzn.to/13tGJ0f">Conceptual Mathematics</a>) isomorphisms are transitive, the translation from sum type to Visitor must have a reverse translation as well. This also seems to me to be intuitively correct, as it's clear to me how to go the other way. Starting with a Visitor: <ol> <li>Refactor the Visitor interface to a Parameter Object that composes functions</li> <li>Refactor the Parameter Object to an argument list</li> <li>Rename types and members as desired</li> </ol> You can, I think, read this article from the bottom towards the top to get an impression of what such a series of refactorings would look like, so I'm not going to explicitly provide an example. </p> <h3 id="b5ac92e65f5d498289a2f99e2754ec00"> Summary <a href="#b5ac92e65f5d498289a2f99e2754ec00" title="permalink">#</a> </h3> <p> Algebraic data types enable you to <em>make illegal states unrepresentable</em>. Most programming languages have product types, so it's the lack of sum types that seems to make the difference between languages like C# and Java on the one side, and languages like F#, OCaml, or Haskell on the other side. </p> <p> You can, however, achieve the same objective with object-oriented design. The Visitor design pattern is equivalent to sum types, so everything you can express with a sum type in, say, F#, you can express with a Visitor in C#. </p> <p> That's not to say that these two representations are equal in readability or maintainability. F# and Haskell sum types are declarative types that usually only take up a few lines of code. Visitor, on the other hand, is a small object hierarchy; it's a more verbose way to express the idea that a type is defined by mutually exclusive and heterogeneous cases. I know which of these alternatives I prefer, but if I were caught in an object-oriented code base, it's nice to know that it's still possible to model a domain with algebraic data types. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church-encoded payment types http://blog.ploeh.dk/2018/06/18/church-encoded-payment-types 2018-06-18T12:04:00+00:00 Mark Seemann <div id="post"> <p> <em>How to translate a domain-specific sum type into a Church-encoded C# API. An article for object-oriented developers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">a series of articles about Church encoding</a>. In the previous articles, you've seen <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">how to implement Boolean logic without Boolean primitives</a>, as well as <a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">how to model natural numbers</a>, <a href="http://blog.ploeh.dk/2018/06/04/church-encoded-maybe">how to implement a Maybe container</a>, and <a href="http://blog.ploeh.dk/2018/06/11/church-encoded-either">how to implement an Either container</a>. Common to all four examples is that they're based on <a href="https://en.wikipedia.org/wiki/Tagged_union">sum types</a> with exactly two mutually exclusive cases. </p> <p> <img src="/content/binary/binary-sum-types-and-matching-methods.png" alt="Three binary sum types, and their corresponding match methods."> </p> <p> You may already have noticed that all three translate to <code>Match</code> methods that take two arguments. The translation is so mechanical that you could automate it. Each case in a sum type becomes an argument in a <code>Match</code> method. In this article, you'll see an example of a domain-specific sum type with three cases, translated to Church-encoding. </p> <h3 id="62f77838e7724b8e8b7b3e5361ae13a7"> A payment type model in F# <a href="#62f77838e7724b8e8b7b3e5361ae13a7" title="permalink">#</a> </h3> <p> In <a href="http://blog.ploeh.dk/2016/11/28/easy-domain-modelling-with-types">a previous article</a> I described a particular business problem that was elegantly addressed with a discriminated union (sum type) in F#: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;<span style="color:teal;">PaymentService</span>&nbsp;=&nbsp;{&nbsp;Name&nbsp;:&nbsp;<span style="color:teal;">string</span>;&nbsp;Action&nbsp;:&nbsp;<span style="color:teal;">string</span>&nbsp;} <span style="color:blue;">type</span>&nbsp;<span style="color:teal;">PaymentType</span>&nbsp;= |&nbsp;<span style="color:navy;">Individual</span>&nbsp;<span style="color:blue;">of</span>&nbsp;<span style="color:teal;">PaymentService</span> |&nbsp;<span style="color:navy;">Parent</span>&nbsp;<span style="color:blue;">of</span>&nbsp;<span style="color:teal;">PaymentService</span> |&nbsp;<span style="color:navy;">Child</span>&nbsp;<span style="color:blue;">of</span>&nbsp;originalTransactionKey&nbsp;:&nbsp;<span style="color:teal;">string</span>&nbsp;*&nbsp;paymentService&nbsp;:&nbsp;<span style="color:teal;">PaymentService</span></pre> </p> <p> In short, this model enables you to model various payments against a third-party payment service. An <em>individual</em> payment is, as the name implies, a single payment. A <em>parent</em> payment can be used to authorise a series of recurring, automated payments, for example to pay for a subscription. A <em>child</em> payment is one of those recurring payments; it must have a parent payment to authorise it, as automation means that no user interaction takes place. </p> <p> One task that is easily addressed with the above <code>PaymentType</code> discriminated union is that you can translate the data to JSON in a type-safe manner. The compiler will tell you whether or not you've handled all three cases. </p> <h3 id="bd590f5f56f7442ca2eddc89ffe07fea"> Auxiliary C# classes <a href="#bd590f5f56f7442ca2eddc89ffe07fea" title="permalink">#</a> </h3> <p> You can Church-encode <code>PaymentType</code> just like Boolean values, natural numbers, Maybe, and Either. Before you do that, however, you need to define the input types involved in each case. These are normal classes, although I prefer to make them immutable: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentService</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;PaymentService(<span style="color:blue;">string</span>&nbsp;name,&nbsp;<span style="color:blue;">string</span>&nbsp;action) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Name&nbsp;=&nbsp;name; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Action&nbsp;=&nbsp;action; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Name&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Action&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChildPaymentService</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ChildPaymentService( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;originalTransactionKey, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">PaymentService</span>&nbsp;paymentService) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.OriginalTransactionKey&nbsp;=&nbsp;originalTransactionKey; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.PaymentService&nbsp;=&nbsp;paymentService; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;OriginalTransactionKey&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>&nbsp;PaymentService&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> These are straightforward translations of the F# <code>PaymentService</code> record type, and the tuple associated with the <code>Child</code> case. In a real code base, I'd override <code>Equals</code> for both classes in order to turn them into proper <a href="https://en.wikipedia.org/wiki/Value_object">Value Objects</a>, but in order to keep the size of the code down, I omitted doing that here. </p> <h3 id="447c7cd04d0447ad99a034972134722b"> Church-encoded payment type <a href="#447c7cd04d0447ad99a034972134722b" title="permalink">#</a> </h3> <p> You can now translate the <code>PaymentType</code> F# discriminated union to a Church-encoded API in C#, starting with the interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child); }</pre> </p> <p> Since there's three cases in the sum type, that turns into a <code>Match</code> method with three arguments, each corresponding to one of the cases. As was also the case for the previous articles' <code>INaturalNumber</code>, <code>IMaybe&lt;T&gt;</code>, and <code>IEither&lt;L, R&gt;</code> interfaces, the data associated with each case is modelled as a function from the data to the generic return type <code>T</code>. </p> <p> Again, following the recipe implied by the previous examples, you should now add a concrete implementation of the <code>IPaymentType</code> interface for each case. It's natural to start with the first argument to the <code>Match</code> method, <em>individual:</em> </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Individual</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>&nbsp;paymentService; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Individual(<span style="color:#2b91af;">PaymentService</span>&nbsp;paymentService) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.paymentService&nbsp;=&nbsp;paymentService; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;individual(paymentService); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Individual</code> class <a href="https://en.wikipedia.org/wiki/Adapter_pattern">adapts</a> a <code>PaymentService</code> value, which it passes as the argument to the <code>individual</code> function argument when <code>Match</code> is called. As you've seen in the previous articles, a particular implementation uses only one of the method arguments, so the two other arguments, <code>parent</code> and <code>child</code>, are simply ignored. </p> <p> The <em>parent</em> implementation is almost identical: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Parent</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>&nbsp;paymentService; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Parent(<span style="color:#2b91af;">PaymentService</span>&nbsp;paymentService) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.paymentService&nbsp;=&nbsp;paymentService; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;parent(paymentService); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Parent</code> class also adapts a <code>PaymentService</code> value that it passes to a function when <code>Match</code> is called. The only difference is that it calls the <code>parent</code> function instead of the <code>individual</code> function argument. </p> <p> The third case is handled by the following <code>Child</code> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Child</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IPaymentType</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;childPaymentService; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Child(<span style="color:#2b91af;">ChildPaymentService</span>&nbsp;childPaymentService) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.childPaymentService&nbsp;=&nbsp;childPaymentService; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;individual, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">PaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;parent, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">ChildPaymentService</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;child) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;child(childPaymentService); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> While the two other classes both adapt a <code>PaymentService</code> value, a <code>Child</code> object instead composes a <code>ChildPaymentService</code> value. When <code>Match</code> is called, it calls the <code>child</code> function argument with the composed value. </p> <h3 id="fbacd6c79ee04992a16bf6d81ecb2e3e"> Using the IPaymentType API <a href="#fbacd6c79ee04992a16bf6d81ecb2e3e" title="permalink">#</a> </h3> <p> One important feature that I originally had to implement was to translate a <em>payment type</em> value into a JSON document. For the purposes of this example, imagine that you can model the desired JSON document using this <a href="https://en.wikipedia.org/wiki/Data_transfer_object">Data Transfer Object</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Name&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Action&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;StartRecurrent&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;TransactionKey&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} }</pre> </p> <p> This is a mutable object because most .NET serialisation APIs require that the class in question has a parameterless constructor and writeable properties. Notice, however, that in order to demonstrate that all this code still doesn't rely on any primitive Boolean operators and such, the class' properties are defined as <code>IChurchBoolean</code> and <code>IMaybe&lt;string&gt;</code> values, as well as regular <code>string</code> values. </p> <p> Writing a method that translates any <code>IPaymentType</code> object into a <code>PaymentJsonModel</code> object is now straightforward: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span>&nbsp;ToJson(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IPaymentType</span>&nbsp;payment) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;payment.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;individual&nbsp;:&nbsp;ps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;ps.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;ps.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;parent&nbsp;:&nbsp;ps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;ps.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;ps.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:blue;">string</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;child&nbsp;:&nbsp;cps&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentJsonModel</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;cps.PaymentService.Name, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Action&nbsp;=&nbsp;cps.PaymentService.Action, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;StartRecurrent&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TransactionKey&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">string</span>&gt;(cps.OriginalTransactionKey) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}); }</pre> </p> <p> Because the <code>Match</code> method takes three arguments, you have to supply a 'handler' function for each of them, and they all have to have the same return type. In this case they all return a new <code>PaymentJsonModel</code> object, so that requirement is fulfilled. All three lambda expressions simply copy over <code>Name</code> and <code>Action</code>, but they differ in the values they assign to <code>StartRecurrent</code> and <code>TransactionKey</code>. </p> <h3 id="465851b6143f4e75b1732bcfccdfcb28"> Tests <a href="#465851b6143f4e75b1732bcfccdfcb28" title="permalink">#</a> </h3> <p> In order to show you that it all works, here's a few examples I wrote as <a href="https://xunit.github.io">xUnit.net</a> tests: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;IndividualToJsonReturnsCorrectResult() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Individual</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Pay&quot;</span>)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.ToJson(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;actual.Name); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Pay&quot;</span>,&nbsp;actual.Action); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(actual.StartRecurrent.ToBool()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(actual.TransactionKey.IsNothing().ToBool()); } [<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;ParentToJsonReturnsCorrectResult() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Parent</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Pay&quot;</span>)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.ToJson(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;actual.Name); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Pay&quot;</span>,&nbsp;actual.Action); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(actual.StartRecurrent.ToBool()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(actual.TransactionKey.IsNothing().ToBool()); } [<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;ChildToJsonReturnsCorrectResult() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Child</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChildPaymentService</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;12345&quot;</span>, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">PaymentService</span>(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Pay&quot;</span>))); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.ToJson(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;MasterCard&quot;</span>,&nbsp;actual.Name); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;Pay&quot;</span>,&nbsp;actual.Action); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(actual.StartRecurrent.ToBool()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#a31515;">&quot;12345&quot;</span>,&nbsp;actual.TransactionKey.Match(<span style="color:#a31515;">&quot;&quot;</span>,&nbsp;x&nbsp;=&gt;&nbsp;x)); }</pre> </p> <p> All three tests pass. </p> <h3 id="eceac90915cb40aab728fae7a36599d4"> Summary <a href="#eceac90915cb40aab728fae7a36599d4" title="permalink">#</a> </h3> <p> The major advantage of sum types in statically typed languages is that you can <em>make illegal states unrepresentable</em> (a maxim attributed to <a href="https://twitter.com/yminsky">Yaron Minsky</a>). Specifically, in the business example of payment types shown here, I need to be able to express that only three out of four combinations of <em>start recurrent</em> and <em>original transaction key</em> is legal. Specifically, I needed to express that the combination of <em>start recurrent = true</em> and the presence of a <em>transaction key</em> is illegal. Making such an illegal state unrepresentable is easy with a sum type, but as this article has shown, you can achieve the same goal in C#. </p> <p> With the API shown here, there's only three possible states (<code>Individual</code>, <code>Child</code>, and <code>Parent</code>). Notice that all three classes hide their data as <code>private</code> class fields, so the only way to extract that data is to call <code>Match</code>. The compiler will make sure that you handle all three cases, because you must supply a function for all three method arguments. </p> <p> The code shown in this article is <a href="https://github.com/ploeh/ChurchEncoding/tree/a015b6f2ce77ca4fbc2fa50c73e03c2bf9686b0c">available on GitHub</a>. </p> <p> This article concludes the little series on how to use Church-encoding in C# to create sum types. You may, however, think that it doesn't really feel object-oriented, with its heavy reliance on function arguments (e.g. <code>Func&lt;PaymentService, T&gt;</code>). It turns out, though, that with only a few refactorings, you'll come to the realisation that what you've seen here is <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">isomorphic</a> to a classic design pattern. <a href="http://blog.ploeh.dk/2018/06/25/visitor-as-a-sum-type">Read on!</a> </p> <p> <strong>Next: </strong> <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions">Some design patterns as universal abstractions</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church-encoded Either http://blog.ploeh.dk/2018/06/11/church-encoded-either 2018-06-11T15:43:00+00:00 Mark Seemann <div id="post"> <p> <em>Programming languages don't have to have a built-in notion of error handling. You can implement sane error handling from first principles. An introduction for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">a series of articles about Church encoding</a>. In this series, you'll learn how to re-create various programming language features from first principles. In previous articles, you learned <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">how to implement Boolean logic without Boolean primitives</a>, <a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">how to model natural numbers</a>, as well as <a href="http://blog.ploeh.dk/2018/06/04/church-encoded-maybe">how to implement Maybe</a> (a <a href="http://blog.ploeh.dk/2015/11/13/null-has-no-type-but-maybe-has">type-safe alternative to null</a>). Through these examples, you'll learn how to model <a href="https://en.wikipedia.org/wiki/Tagged_union">sum types</a> without explicit language support. </p> <p> <h3 id="6fd3652e6b9d462781a7d5191e32f6f0"> Error handling without exceptions <a href="#6fd3652e6b9d462781a7d5191e32f6f0" title="permalink">#</a> </h3> </p> <p> In a previous article, I've discussed how <a href="http://blog.ploeh.dk/2015/04/13/less-is-more-language-features">a language doesn't need to have built-in exceptions</a> in order to support composable and type-safe error handling. In fact, exceptions are noting but <a href="http://wiki.c2.com/?DontUseExceptionsForFlowControl">glorified GOTO statements</a>. A better approach is to use the <em>Either</em> abstraction, which enables you to model values that are either one or another thing. </p> <p> In <a href="https://fsharp.org">F#</a>, this type is known as <a href="https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/results">Result&lt;'T, 'TError&gt;</a>, while in <a href="https://www.haskell.org">Haskell</a> it's called <a href="https://hackage.haskell.org/package/base/docs/Data-Either.html">Either</a>. It enables you to model an outcome that is either something (like a success) or something else (such as an error). </p> <p> <a href="https://fsharpforfunandprofit.com">Scott Wlaschin</a> has already brilliantly described <a href="https://fsharpforfunandprofit.com/posts/recipe-part2">how this works in F#</a>, but the <code>Either</code> type can be used for error handling in Haskell in exactly the same way. When we use the terminology related to <em>either</em>, we distinguish between <em>left</em> and <em>right</em>. Typically, <em>right</em> is used to indicate success, via the pun that 'right' is 'correct'. </p> <p> <h3 id="72621c98299f4840b2ec880d254112a2"> Lambda calculus Either <a href="#72621c98299f4840b2ec880d254112a2" title="permalink">#</a> </h3> </p> <p> Church encoding is based on the <a href="https://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a>, which defines a universal model of computation based entirely on functions (lambda expressions) and recursion. As far as I can tell, you can define <em>Either</em> in lambda calculus as an expression that takes two arguments, and where there's two fundamental 'implementations' of the contract: </p> <p> <pre> left = λa.λl.λr.l a right = λb.λl.λr.r b</pre> </p> <p> (I admit that I'm going out on a limb here, since I haven't found any source that puts either in the above form, so I'd appreciate feedback if I did it incorrectly.) </p> <p> The contract is that, similar to <em>Maybe</em>, the <code>l</code> function argument represents the <em>left</em> case, whereas the <code>r</code> argument represents the <em>right</em> case. Contrary to <em>Maybe</em>, both <em>l</em> and <em>r</em> are used as functions. (Everything in lambda calculus is a function, but we don't always use the arguments as the function that they are.) </p> <p> The <code>left</code> function is a function that takes three arguments (<code>a</code>, <code>l</code>, and <code>r</code>) and always returns <code>l a</code>. Recall that in lambda calculus, everything is a function, which includes <code>l</code> (and <code>r</code>). In other words, <code>left</code> unconditionally calls <code>l</code> with <code>a</code>, and that's the return value. </p> <p> The <code>right</code> function works like the <code>left</code> function, with the only difference that it always returns <code>r b</code>. </p> <p> The idea, as usual, is that you can partially apply <code>left</code> and <code>right</code>, by, for instance calling <code>left three</code> (where <code>three</code> is the lambda calculus representation of the number 3, as described in <a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">the article on Church-encoded natural numbers</a>). Such a partially applied function is a function that still takes the two arguments <code>l</code> and <code>r</code>. </p> <p> The same is true if you partially apply <code>right</code> with a value, like <code>right one</code>. </p> <p> In both cases, you have a function of the form <code>λl.λr.[...]</code>. If you've been given such a function by an external source, you may not know if it's a <code>left</code> or a <code>right</code> expression, and that's the point. You must supply handlers (<code>l</code> and <code>r</code>) that cover all possible cases. </p> <p> In the lambda calculus, expressions are always curried, so instead of viewing <code>left</code> and <code>right</code> as functions with three arguments, you can view them as functions that take a single element (<code>a</code> or <code>b</code>) and return functions that takes two arguments. This agrees with Haskell's <code>Left</code> and <code>Right</code> data constructors: </p> <p> <pre>Prelude&gt; :t Left Left :: a -&gt; Either a b Prelude&gt; :t Right Right :: b -&gt; Either a b</pre> </p> <p> Haskell tells us that <code>Left</code> is a function that takes an <code>a</code> value and returns an <code>Either a b</code> value. Similarly, <code>Right</code> is a function that takes a <code>b</code> value as input, and returns an <code>Either a b</code> </p> <p> <h3 id="a680dfb8fbb1483391de0ac3fedcdcd6"> Church-encoded Either in C# <a href="#a680dfb8fbb1483391de0ac3fedcdcd6" title="permalink">#</a> </h3> </p> <p> Both lambda calculus and Haskell relies on currying and partial application to make the contract fit. In C#, as you've <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">previously</a> seen, you can instead define an interface and rely on class fields for the 'extra' function arguments. Since Church-encoded Either is represented by a function that takes two arguments, we'll once again define an interface with a single method that takes two arguments: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IEither</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">R</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onLeft,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">R</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onRight); }</pre> </p> <p> The <code>Match</code> method takes two functions as arguments, one that handles the <em>left</em> case, and one that handles the <em>right</em> case. They correspond to the <code>l</code> and <code>r</code> variables in the above lambda expressions. The intent, as with other Church-encoded discriminated unions, is that when client code is given an <code>IEither&lt;L, R&gt;</code> object, it can only interact with that object by telling the <code>Match</code> method how to deal with both cases. Only one of the functions will be called, but at compile-time, you don't know which one. Both functions, however, must return a value of the generic type <code>T</code>, and that's how you can translate an <code>IEither&lt;L, R&gt;</code> object to a <code>T</code> value. </p> <p> Following the normal procedure for Church encoding, you must also supply two implementations of the <code>IEither&lt;L, R&gt;</code> interface: one for each case. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Left</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">R</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IEither</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">R</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">L</span>&nbsp;left; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Left(<span style="color:#2b91af;">L</span>&nbsp;left) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.left&nbsp;=&nbsp;left; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onLeft,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">R</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onRight) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;onLeft(left); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Left&lt;L, R&gt;</code> class is an <a href="https://en.wikipedia.org/wiki/Adapter_pattern">Adapter</a> of a value of the generic type <code>L</code> , making it appear as an <code>IEither&lt;L, R&gt;</code> object. </p> <p> It always calls the <code>onLeft</code> method argument with the adapted value <code>left</code>, while it ignores the <code>onRight</code> method argument. Since <code>onLeft</code> returns a <code>T</code> value, you can return the value produced by the function call. </p> <p> The <em>right</em> case is implemented in a similar fashion: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Right</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">R</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IEither</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">R</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">R</span>&nbsp;right; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Right(<span style="color:#2b91af;">R</span>&nbsp;right) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.right&nbsp;=&nbsp;right; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">L</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onLeft,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">R</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;onRight) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;onRight(right); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Right&lt;L, R&gt;</code> class is the mirror image of <code>Left&lt;L, R&gt;</code>. Instead of adapting an <code>L</code> value, it adapts an <code>R</code> value. It implements <code>Match</code> by always calling <code>onRight</code> with the <code>right</code> value, which, again, produces a <code>T</code> value that can be immediately returned. </p> <p> Notice that for both implementations, the adapted values <code>left</code> and <code>right</code> are <code>private</code> class fields not exposed as public members. The only way you, as a caller, can potentially extract these values is by calling <code>Match</code>, and that forces you to explicitly deal with both cases. </p> <p> Here's an example of using the API: </p> <p> <pre>&gt; <span style="color:#2b91af;">IEither</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;e&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Right</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;(42); &gt; e.Match(s =&gt; s.Length % 2 == 0, i =&gt; i % 2 == 0) true</pre> </p> <p> I've deliberately declared <code>e</code> as a an <code>IEither&lt;string, int&gt;</code> in order to highlight the scenario where, as a client developer, you're often given a value of such a type, and you don't know if it's a <em>left</em> or a <em>right</em> value. Had I, instead, used the <code>var</code> keyword, the compiler would have detected that <code>e</code> is, really, a <code>Right&lt;string, int&gt;</code> variable. You may consider this choice artificial, but the point I'm trying to get across is that, when writing client code, you're often given a polymorphic value, and you don't know the concrete type of the value. According to the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Liskov Substitution Principle</a>, your client code must be able to deal with any subtype without changing the correctness of the system. In the case of an Either value, the way you deal with all subtypes is by supplying handlers for both cases to the <code>Match</code> method. </p> <p> In the above example, the return value is <code>true</code> because <code>42</code> is an even number. If, instead, the <code>e</code> object is a <em>left</em> case containing the string <code>"foo"</code>, the return value is <code>false</code> because the length of <code>"foo"</code> is <em>3</em> - an odd number: </p> <p> <pre>&gt; <span style="color:#2b91af;">IEither</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;e&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Left</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;(<span style="color:#a31515;">&quot;foo&quot;</span>); &gt; e.Match(s =&gt; s.Length % 2 == 0, i =&gt; i % 2 == 0) false</pre> </p> <p> Notice that the <code>e.Match</code> method call is the same in both examples; the <code>onLeft</code> and <code>onRight</code> functions are the same in both cases. The results differ because the input values represent different cases. </p> <p> If you've been following the overall series on Church encoding, you may think that it's cheating to use C#'s built-in <code>string</code> and <code>int</code> data types, but nothing prevents us from sticking to the data types we've built from scratch: </p> <p> <pre>&gt; <span style="color:#2b91af;">IEither</span>&lt;<span style="color:#2b91af;">IChurchBoolean</span>,&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&gt;&nbsp;e; &gt; e&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Right</span>&lt;<span style="color:#2b91af;">IChurchBoolean</span>,&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&gt;(<span style="color:#2b91af;">NaturalNumber</span>.Seven); &gt; e.Match(b&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchNot</span>(b),&nbsp;n&nbsp;=&gt;&nbsp;n.IsEven()) ChurchFalse { } &gt; e&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Left</span>&lt;<span style="color:#2b91af;">IChurchBoolean</span>,&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>()); &gt; e.Match(b&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchNot</span>(b),&nbsp;n&nbsp;=&gt;&nbsp;n.IsEven()) ChurchNot(ChurchFalse)</pre> </p> <p> For both the <em>left</em> and the <em>right</em> case, the <code>Match</code> inverts the Boolean expression if it's a <em>left</em> case, and evaluates if the number is even if it's a <em>right</em> case. In the first example, the return value is a <code>ChurchFalse</code> object because <em>7</em> is odd. In the second example, the return value is a <code>ChurchNot</code> object containing a <code>ChurchFalse</code> object (in other words, <em>true</em>), because the negation of <em>false</em> is <em>true</em>. </p> <p> <h3 id="f09ad4ad69ba47b6b9f13b0fcd99d6fe"> Either instead of exceptions <a href="#f09ad4ad69ba47b6b9f13b0fcd99d6fe" title="permalink">#</a> </h3> </p> <p> You can use Either to signal the success or failure of an operation. By convention, the <em>right</em> case is used to signal success, so, by elimination, <em>left</em> means failure. You can signal errors in numerous ways, e.g. by using <code>enum</code> values, but another common strategy is to simply use string values. </p> <p> Consider the following example. You receive a collection of values, where each element represents a vote for that element. For example, the list <em>Sandra, Zoey, Sandra</em> indicates two votes for <em>Sandra</em>, and one for <em>Zoey</em>. You need to write a method that returns the winner of a vote, but at least two distinct errors are possible: the input collection is empty, or there's a tie. </p> <p> You can model the error cases with an <code>enum</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">enum</span>&nbsp;<span style="color:#2b91af;">VoteError</span> { &nbsp;&nbsp;&nbsp;&nbsp;Empty&nbsp;=&nbsp;0, &nbsp;&nbsp;&nbsp;&nbsp;Tie }</pre> </p> <p> This enables you to write a method to find the winners, with an explicit Either return type: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IEither</span>&lt;<span style="color:#2b91af;">VoteError</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;FindWinner&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;votes) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;countedVotes&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;v&nbsp;<span style="color:blue;">in</span>&nbsp;votes &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">group</span>&nbsp;v&nbsp;<span style="color:blue;">by</span>&nbsp;v&nbsp;<span style="color:blue;">into</span>&nbsp;g &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;count&nbsp;=&nbsp;g.Count() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">orderby</span>&nbsp;count&nbsp;<span style="color:blue;">descending</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;<span style="color:blue;">new</span>&nbsp;{&nbsp;Vote&nbsp;=&nbsp;g.Key,&nbsp;Count&nbsp;=&nbsp;count&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;c&nbsp;=&nbsp;countedVotes.Take(2).Count(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(c&nbsp;==&nbsp;0) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Left</span>&lt;<span style="color:#2b91af;">VoteError</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">VoteError</span>.Empty); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x0&nbsp;=&nbsp;countedVotes.ElementAt(0); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(c&nbsp;==&nbsp;1) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Right</span>&lt;<span style="color:#2b91af;">VoteError</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;(x0.Vote); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x1&nbsp;=&nbsp;countedVotes.ElementAt(1); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(Equals(x0.Count,&nbsp;x1.Count)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Left</span>&lt;<span style="color:#2b91af;">VoteError</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">VoteError</span>.Tie); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Right</span>&lt;<span style="color:#2b91af;">VoteError</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;(x0.Vote); }</pre> </p> <p> Notice that the return type of the <code>FindWinner</code> method is <code>IEither&lt;VoteError, T&gt;</code>; either you get a <code>VoteError</code> value, or you get a <code>T</code> value, but any client code doesn't know which it'll be, so it must handle both cases. </p> <p> The method uses a C# query expression to group, count, and order the votes. If there's no elements, the return value is a <em>left</em> value containing <code>VoteError.Empty</code>. If there's only a single vote group (e.g. if the votes where all for <em>Sandra</em>), that value is returned in a <em>right</em> case. Otherwise, if the two highest ranked votes have the same count, a <em>left</em> value is returned containing <code>VoteError.Tie</code>. Finally, in all other cases, the highest voted element is returned in a <em>right</em> case. </p> <p> Here's some examples in <em>C# Interactive:</em> </p> <p> <pre>&gt; FindWinner&lt;<span style="color:blue;">int</span>&gt;() Left&lt;VoteError, int&gt;(Empty) &gt; FindWinner(1, 2, 3, 1, 4, 2) Left&lt;VoteError, int&gt;(Tie) &gt; FindWinner(<span style="color:#a31515;">&quot;Sandra&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Zoey&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Sandra&quot;</span>) Right&lt;VoteError, string&gt;("Sandra")</pre> </p> <p> Instead of throwing two different types of exceptions on invalid input, the <code>FindWinner</code> method handles invalid input as <em>left</em> cases, and valid input as the <em>right</em> case. You can do that consistently, and thereby eliminate the need for exceptions. Errors are, instead, reported as <em>left</em> values. </p> <p> <h3 id="fb2ac51484e14b738c2e4af5278912e3"> Summary <a href="#fb2ac51484e14b738c2e4af5278912e3" title="permalink">#</a> </h3> </p> <p> In this article, you saw how it's possible to define the <em>Either</em> container from first principles, using nothing but functions (and, for the C# examples, interfaces and classes in order to make the code easier to understand for object-oriented developers). </p> <p> The code shown in this article is <a href="https://github.com/ploeh/ChurchEncoding/tree/49b0646c38d15648e9145052d3a04954f54c29f8">available on GitHub</a>. </p> <p> <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Like Maybe</a>, you can also make Either a functor. This'll enable you to compose various error-producing functions in a sane manner. </p> <p> Church-encoding enables you to model sum types as functions. So far in this article series, you've seen how to model Boolean values, natural numbers, Maybe, and Either. Common to all four examples is that the data type in question consists of two mutually exclusive cases. This is the reason they're all modelled as methods that take two arguments. What happens if, instead of two, you have <em>three</em> mutually exclusive cases? Read on. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/06/18/church-encoded-payment-types">Church-encoded payment types</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church-encoded Maybe http://blog.ploeh.dk/2018/06/04/church-encoded-maybe 2018-06-04T10:08:00+00:00 Mark Seemann <div id="post"> <p> <em>Programming languages don't have to have a built-in notion of null values. Missing or optional values can be created from first principles. An introduction for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">a series of articles about Church encoding</a>. In this series, you'll learn how to re-create various programming language features from first principles. In previous articles, you learned <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">how to implement Boolean logic without Boolean primitives</a>, as well as <a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">how to model natural numbers</a>. Through these examples, you'll learn how to model <a href="https://en.wikipedia.org/wiki/Tagged_union">sum types</a> without explicit language support. </p> <h3 id="2e26f3d3d84a43b790f7ee5e89dedbff"> The billion-dollar mistake <a href="#2e26f3d3d84a43b790f7ee5e89dedbff" title="permalink">#</a> </h3> <p> All mainstream programming languages have a built-in notion of <em>null</em>: a value that isn't there. There's nothing wrong with the concept; you often run into situations where you need to return a value, but in certain cases, you'll have nothing to return. Division by zero would be one example. Attempting to retrieve the first element from an empty collection would be another. </p> <p> Unfortunately, for fifty years, we've been immersed in environments where null references have been the dominant way to model the absence of data. This, despite the fact that even <a href="https://en.wikipedia.org/wiki/Tony_Hoare">Sir Antony Hoare</a>, the inventor of null references, has publicly called it his <em>billion-dollar mistake</em>. </p> <p> You can, however, model the potential absence of data in saner ways. <a href="https://www.haskell.org">Haskell</a>, for example, has no built-in null support, but it does include a built-in <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a> type. In Haskell (as well as in <a href="http://fsharp.org">F#</a>, where it's called <code>option</code>), <code>Maybe</code> is defined as a sum type: </p> <p> <pre><span style="color:blue;">data</span>&nbsp;Maybe&nbsp;a&nbsp;=&nbsp;Nothing&nbsp;|&nbsp;Just&nbsp;a&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Eq</span>,&nbsp;<span style="color:#2b91af;">Ord</span>)</pre> </p> <p> If you're not familiar with Haskell syntax, this is a type declaration that states that the <a href="https://en.wikipedia.org/wiki/Parametric_polymorphism">parametrically polymorphic</a> (AKA <em>generic</em>) data type <code>Maybe</code> is inhabited by <code>Just</code> values that contain other values, plus the constant <code>Nothing</code>. </p> <p> This article series, however, examines how to implement sum types with Church encoding. </p> <h3 id="b2a73bd4fc25450a8ba2e5e90f3319dc"> Lambda calculus maybe <a href="#b2a73bd4fc25450a8ba2e5e90f3319dc" title="permalink">#</a> </h3> <p> Church encoding is based on the <a href="https://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a>, which defines a universal model of computation based entirely on functions (lambda expressions) and recursion. In lambda calculus, the contract of <em>Maybe</em> is defined as an expression that takes two arguments. <a href="http://programmable.computer/posts/church_encoding.html">There's two fundamental 'implementations' of the contract</a>: </p> <p> <pre>nothing = λn.λj.n just = λx.λn.λj.j x</pre> </p> <p> The contract is that the first function argument (<code>n</code>) represents the <em>nothing</em> case, whereas the second argument (<code>j</code>) represents the <code>just</code> case. </p> <p> The <code>nothing</code> function is a lambda expression that takes two arguments (<code>n</code> and <code>j</code>), and always returns the first, left-most argument (<code>n</code>). </p> <p> The <code>just</code> function is a lambda expression that takes three arguments (<code>x</code>, <code>n</code>, and <code>j</code>), and always returns <code>j x</code>. Recall that in the lambda calculus, everything is a function, including <code>j</code>, so <code>j x</code> means that the function <code>j</code> is called with the argument <code>x</code>. </p> <p> A few paragraphs above, I wrote that the contract of <em>maybe</em> is modelled as an expression that takes two arguments, yet <code>just</code> takes three arguments. How does that fit? </p> <p> In the lambda calculus, expressions are always curried, so instead of viewing <code>just</code> as a function with three arguments, you can view it as a function that takes a single element (<code>x</code>) and returns a function that takes two arguments. This agrees with Haskell's <code>Just</code> data constructor: </p> <p> <pre>Prelude&gt; :t Just Just :: a -&gt; Maybe a</pre> </p> <p> Haskell tells us that <code>Just</code> is a function that takes an <code>a</code> value (corresponding to <code>x</code> in the above <code>just</code> lambda expression) and returns a <code>Maybe a</code> value. </p> <h3 id="01738cd9f37e4067947379b2aaf1735c"> Church-encoded Maybe in C# <a href="#01738cd9f37e4067947379b2aaf1735c" title="permalink">#</a> </h3> <p> Both lambda calculus and Haskell rely on currying and partial application to make the contract fit. In C#, as you've <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">previously</a> seen, you can instead define an interface and rely on class fields for the 'extra' function arguments. Since Church-encoded Maybe is represented by a function that takes two arguments, we'll once again define an interface with a single method that takes two arguments: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">TResult</span>&nbsp;Match&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">TResult</span>&nbsp;nothing,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;just); }</pre> </p> <p> In the first article, about Church-encoded Boolean values, you saw how two mutually exclusive values could be modelled as a method that takes two arguments. Boolean values are simply constants (<em>true</em> and <em>false</em>), where the next example (natural numbers) included a case where one case (<em>successor</em>) contained data. In that example, however, the data was statically typed as another <code>INaturalNumber</code> value. In the current <code>IMaybe&lt;T&gt;</code> example, the data contained in the <em>just</em> case is generic (it's of the type <code>T</code>). </p> <p> Notice that there's two levels of generics in play. <code>IMaybe&lt;T&gt;</code> itself is a container of the generic type <code>T</code>, whereas <code>Match</code> enables you to convert the container into the rank-2 polymorphic type <code>TResult</code>. </p> <p> Once more, the contract of <code>IMaybe&lt;T&gt;</code> is that the first, left-hand argument represents the <em>nothing</em> case, whereas the second, right-hand argument represents the <em>just</em> case. The <em>nothing</em> implementation, then, is similar to the previous <code>ChurchTrue</code> and <code>Zero</code> classes: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">TResult</span>&nbsp;Match&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">TResult</span>&nbsp;nothing,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;just) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;nothing; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Again, the implementation unconditionally returns <code>nothing</code> while ignoring <code>just</code>. You may, though, have noticed that, as is appropriate for Maybe, <code>Nothing&lt;T&gt;</code> has a distinct type. In other words, <code>Nothing&lt;string&gt;</code> doesn't have the same type as <code>Nothing&lt;int&gt;</code>. This is not only 'by design', but is a fundamental result of how we define <em>Maybe</em>. The code simply wouldn't compile if you tried to remove the type argument from the class. This is in contrast to <a href="http://blog.ploeh.dk/2015/11/13/null-has-no-type-but-maybe-has">C# null, which has no type</a>. </p> <p> You implement the <em>just</em> case like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Just(<span style="color:#2b91af;">T</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.value&nbsp;=&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">TResult</span>&nbsp;Match&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">TResult</span>&nbsp;nothing,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;just) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;just(value); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> According to the contract, <code>Just&lt;T&gt;</code> ignores <code>nothing</code> and works exclusively with the <code>just</code> function argument. Notice that the <code>value</code> class field is <code>private</code> and not exposed as a public member. The only way you, as a caller, can potentially extract the value is by calling <code>Match</code>. </p> <p> Here are some examples of using the API: </p> <p> <pre>&gt; <span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;().Match(nothing:&nbsp;<span style="color:#a31515;">&quot;empty&quot;</span>,&nbsp;just:&nbsp;g&nbsp;=&gt;&nbsp;g.ToString()) "empty" &gt; <span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">int</span>&gt;(42).Match(nothing:&nbsp;<span style="color:#a31515;">&quot;empty&quot;</span>,&nbsp;just:&nbsp;i&nbsp;=&gt;&nbsp;i.ToString()) "42" &gt; <span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">int</span>&gt;(1337).Match(nothing:&nbsp;0,&nbsp;just:&nbsp;i&nbsp;=&gt;&nbsp;i) 1337</pre> </p> <p> Notice that the third example shows how to extract the value contained in a <code>Nothing&lt;int&gt;</code> object without changing the output type. All you have to do is to supply a 'fall-back' value that can be used in case the value is <em>nothing</em>. </p> <h3 id="8af13110cd88473c97cc1cee28dd7ee9"> Maybe predicates <a href="#8af13110cd88473c97cc1cee28dd7ee9" title="permalink">#</a> </h3> <p> You can easily implement the standard Maybe predicates <code>IsNothing</code> and <code>IsJust</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;IsNothing&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;m) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;m.Match&lt;<span style="color:#2b91af;">IChurchBoolean</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing&nbsp;:&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(),&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just&nbsp;:&nbsp;_&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>()); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;IsJust&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;m) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;m.Match&lt;<span style="color:#2b91af;">IChurchBoolean</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing&nbsp;:&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just&nbsp;:&nbsp;_&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>()); }</pre> </p> <p> Here, I arbitrarily chose to implement <code>IsJust</code> 'from scratch', but I could also have implemented it by negating the result of calling <code>IsNothing</code>. Once again, notice that the predicates are expressed in terms of Church-encoded Boolean values, instead of the built-in <code>bool</code> primitives. </p> <h3 id="76561f015e4d4da0a590ba247eb4500d"> Functor <a href="#76561f015e4d4da0a590ba247eb4500d" title="permalink">#</a> </h3> <p> From Haskell (and F#) we know that Maybe is a <a href="http://blog.ploeh.dk/2018/03/22/functors">functor</a>. In C#, you turn a container into a functor by implementing an appropriate <code>Select</code> method. You can do this with <code>IMaybe&lt;T&gt;</code> as well: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;Select&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;source, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;selector) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;source.Match&lt;<span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nothing:&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Nothing</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just:&nbsp;x&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;(selector(x))); }</pre> </p> <p> Notice that this method turns an <code>IMaybe&lt;T&gt;</code> object into an <code>IMaybe&lt;TResult&gt;</code> object, using nothing but the <code>Match</code> method. This is possible because <code>Match</code> has a generic return type; thus, among other types of values, you can make it return <code>IMaybe&lt;TResult&gt;</code>. </p> <p> When <code>source</code> is a <code>Nothing&lt;T&gt;</code> object, <code>Match</code> returns the object in the <em>nothing</em> case, which here becomes a new <code>Nothing&lt;TResult&gt;</code> object. </p> <p> When <code>source</code> is a <code>Just&lt;T&gt;</code> object, <code>Match</code> invokes <code>selector</code> with the value contained in the <em>just</em> object, packages the result in a new <code>Just&lt;TResult&gt;</code> object, and returns it. </p> <p> Because the <code>Select</code> method has the correct signature, you can use it with query syntax, as well as with normal method call syntax: </p> <p> <pre><span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">int</span>&gt;(42); <span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;actual&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;i&nbsp;<span style="color:blue;">in</span>&nbsp;m &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;i.ToString();</pre> </p> <p> This example simply creates a <em>just</em> value containing the number <code>42</code>, and then maps it to a string. Another way to write the same expression would be with method call syntax: </p> <p> <pre><span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Just</span>&lt;<span style="color:blue;">int</span>&gt;(42); <span style="color:#2b91af;">IMaybe</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;actual&nbsp;=&nbsp;m.Select(i&nbsp;=&gt;&nbsp;i.ToString());</pre> </p> <p> In both cases, the result is a <em>just</em> case containing the string <code>"42"</code>. </p> <h3 id="4bdd2b27f1724e3198b95d86642c8a6c"> Summary <a href="#4bdd2b27f1724e3198b95d86642c8a6c" title="permalink">#</a> </h3> <p> In this article, you saw how it's possible to define the <em>Maybe</em> container from first principles, using nothing but functions (and, for the C# examples, interfaces and classes in order to make the code easier to understand for object-oriented developers). </p> <p> The code shown in this article is <a href="https://github.com/ploeh/ChurchEncoding/tree/8d1e7501f486351e748646c915f0bd334332e386">available on GitHub</a>. </p> <p> Church-encoding enables you to model sum types as functions. So far in this article series, you've seen how to model Boolean values, natural numbers, and Maybe. Common to all three examples is that the data type in question consists of two mutually exclusive cases. There's at least one more interesting variation on that pattern. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/06/11/church-encoded-either">Church-encoded Either</a>. </p> </div> <div id="comments"> <hr> <h2 id="comments-header">Comments</h2> <div class="comment" id="219468451d9a4af99be169a73af898bd"> <div class="comment-author"><a href="https://github.com/adleatherwood">Anthony Leatherwood</a></div> <div class="comment-content"> It's probably not your favorite thing to do anymore, but I thank you so much for continuing to provide C# examples for these concepts. It's invaluable for programmers wishing to adopt these concepts into the OOP languages they work with for a living. It's also a tremendous aid in briding the gap of understanding between OOP and FP. </div> <div class="comment-date">2018-06-04 17:57 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church-encoded natural numbers http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers 2018-05-28T08:24:00+00:00 Mark Seemann <div id="post"> <p> <em>Natural numbers don't have to be built into programming languages. An introduction for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">a series of articles about Church encoding</a>. The previous article, about <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">Church-encoding of Boolean values</a>, concluded with the question: <em>how do you determine whether an integer is even or odd?</em> </p> <p> That sounds easy, but turns out to be more complicated that you might think at first glance. </p> <h3 id="47669f1d5f3c48968e13474ec60a86a0"> Built-in options <a href="#47669f1d5f3c48968e13474ec60a86a0" title="permalink">#</a> </h3> <p> How would you normally check whether a number is even? In some languages, like <a href="https://www.haskell.org">Haskell</a>, it's built into the base library: </p> <p> <pre>Prelude&gt; even 1337 False Prelude&gt; even 42 True</pre> </p> <p> In C#, surprisingly, I don't think it's built-in, but it's easy to implement a method to answer the question: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsEven(<span style="color:blue;">this</span>&nbsp;<span style="color:blue;">int</span>&nbsp;i) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;i&nbsp;%&nbsp;2&nbsp;==&nbsp;0; }</pre> </p> <p> You could implement an <code>IsOdd</code> method either by using the <code>!=</code> operator instead of <code>==</code>, but otherwise copy the implementation of <code>IsEven</code>; or, alternatively, call <code>IsEven</code> and negate the result. </p> <p> This works fine in normal C# code, but in this article, the agenda is different. We're investigating how programming with the <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">previous article's</a> <code>IChurchBoolean</code> API would look. The above built-in options use Boolean language primitives, so that's not really instructive. </p> <h3 id="313b328dd4f2495b852ef2a7aae6b130"> Boolean conversions <a href="#313b328dd4f2495b852ef2a7aae6b130" title="permalink">#</a> </h3> <p> It's easy to convert between Church-encoded Boolean values and built-in Boolean values. For reasons I'll explain shortly, I still don't think that's instructive in this particular context, but for good measure I'll cover how to do it. </p> <p> A method like the above <code>IsEven</code> returns <code>bool</code>. If you, instead, want an <code>IChurchBoolean</code>, you can use this simple conversion method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;ToChurchBoolean(<span style="color:blue;">this</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;b) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(b) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(); }</pre> </p> <p> Alternatively, you can also use the ternary operator, but an ugly cast is necessary to make the C# compiler happy: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;ToChurchBoolean(<span style="color:blue;">this</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;b) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;b&nbsp;?&nbsp;(<span style="color:#2b91af;">IChurchBoolean</span>)<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>()&nbsp;:&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(); }</pre> </p> <p> Regardless of which implementation you choose, you'd be able to interact with the result as an <code>IChurchBoolean</code> values, as this small interactive session demonstrates: </p> <p> <pre>&gt; 42.IsEven().ToChurchBoolean().Match(<span style="color:#a31515;">&quot;Even&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Odd&quot;</span>) "Even" &gt; 1337.IsEven().ToChurchBoolean().Match(<span style="color:#a31515;">&quot;Even&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;Odd&quot;</span>) "Odd"</pre> </p> <p> Still, converting from <code>bool</code> to <code>IChurchBoolean</code> doesn't address the underlying question: <em>is it possible to write programs without built-in Boolean primitives?</em> </p> <p> The conversion function <code>ToChurchBoolean</code> uses built-in Boolean values and functions, so it doesn't show whether or not it would be possible to make do without those. </p> <p> Before we abandon that line of inquiry, however, I think it's only fair to share a conversion method that goes the other way: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;ToBool(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;b) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;b.Match(<span style="color:blue;">true</span>,&nbsp;<span style="color:blue;">false</span>); }</pre> </p> <p> This function enables you to convert an <code>IChurchBoolean</code> value into a primitive C# <code>bool</code>, because when <code>b</code> represents <em>true</em>, the first argument (i.e. <code>true</code>) is returned, and when <code>b</code> represents <em>false</em>, the second argument (i.e. <code>false</code>) is returned. </p> <h3 id="5a59bcde604b4444b7dba56a6ed1989f"> Peano numbers <a href="#5a59bcde604b4444b7dba56a6ed1989f" title="permalink">#</a> </h3> <p> If we can't use built-in primitives or operators that return them (e.g. <code>==</code>), we may not be able to move forward with built-in numbers, either. What we <em>can</em> do, however, is to follow the <a href="https://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a> to implement <a href="https://en.wikipedia.org/wiki/Natural_number">natural numbers</a> using Church encoding. This will enable us to determine if a natural number is even or odd. </p> <p> Lambda calculus models natural numbers according to <a href="https://en.wikipedia.org/wiki/Peano_axioms">Peano's model</a>. In short, a natural number is either zero (or one, depending on the specific interpretation), or a successor to another natural number. As an example, using the <code>Successor</code> class that I'll develop later in this article, the number three can be represented as <code>new Successor(new Successor(new Successor(new Zero())))</code> - it's the number after the number after the number after zero. </p> <p> Like Church-encoded Boolean values, a Church-encoded natural number is a function that takes two arguments, corresponding to zero, and a successor function: </p> <p> <pre>zero = λf.λx.x one = λf.λx.f x two = λf.λx.f (f x) three = λf.λx.f (f (f x)) ...</pre> </p> <p> Each of these functions takes an initial value <code>x</code>, as well as a function <code>f</code>. In the lambda calculus, neither <code>x</code> nor <code>f</code> have any implied interpretation; it's the number of applications of <code>f</code> that defines the number. </p> <p> In most translations into programming languages that I've encountered, however, <code>x</code> is usually interpreted as zero, and <code>f</code> as the <a href="https://en.wikipedia.org/wiki/Successor_function">successor function</a>. In Haskell, for example, <a href="https://wiki.haskell.org/Peano_numbers">a common way to model Peano numbers</a> is to use a <a href="https://en.wikipedia.org/wiki/Tagged_union">sum type</a>: </p> <p> <pre><span style="color:blue;">data</span>&nbsp;Peano&nbsp;=&nbsp;Zero&nbsp;|&nbsp;Succ&nbsp;Peano&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Eq</span>,&nbsp;<span style="color:#2b91af;">Show</span>) </pre> </p> <p> Basically, this means that a value of the <code>Peano</code> type can either be the atom <code>Zero</code>, or a <code>Succ</code> value. Notice that <code>Succ</code> contains another <code>Peano</code> value; the data type is recursive. </p> <p> You can write Haskell values like these: </p> <p> <pre>*Peano&gt; zero = Zero *Peano&gt; one = Succ Zero *Peano&gt; two = Succ (Succ Zero) *Peano&gt; three = Succ (Succ (Succ Zero))</pre> </p> <p> Alternatively, you can also define the numbers based on previous definitions: </p> <p> <pre>*Peano&gt; zero = Zero *Peano&gt; one = Succ zero *Peano&gt; two = Succ one *Peano&gt; three = Succ two</pre> </p> <p> This variation of Peano numbers uses an explicit sum type, but as the lambda calculus representation suggests, you can also use Church encoding to represent the two cases. </p> <h3 id="144967cc5ba04aac979242c5032b7a96"> Church-encoded natural numbers <a href="#144967cc5ba04aac979242c5032b7a96" title="permalink">#</a> </h3> <p> If you recall Church-encoded Boolean values, you may remember that they are functions that take two values: a value to be used in case of <em>true</em>, and a value to be used in the case of <em>false</em>. You can do something similar with natural numbers. <code>Zero</code> is like <em>true</em> and <em>false</em>, in the sense that it's nothing but a label without any associated data. <code>Succ</code>, on the other hand, contains another <code>Peano</code> value. The way to do that is to turn the <em>successor</em> case into a function. Doing that, you'll arrive at an interface like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;zero,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">INaturalNumber</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;succ); }</pre> </p> <p> The first argument, on the left-hand side, is the case to use when an object represents <em>zero</em>. The second argument, on the right-hand side, is a function that will ultimately produce the value associated with a <em>successor</em>. The implied contract here is that the <code>INaturalNumber</code> passed as input to <code>succ</code> is the <em>predecessor</em> to 'the current value'. This may seem counter-intuitive, but hopefully becomes clearer when you see the <code>Successor</code> class below. The crucial insight is that a successor value has no intrinsic value; it's entirely defined by how many predecessors it has. </p> <p> The <em>zero</em> implementation is similar to how Church-encoding implements <em>true</em>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Zero</span>&nbsp;:&nbsp;<span style="color:#2b91af;">INaturalNumber</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;zero,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">INaturalNumber</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;succ) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;zero; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that the <code>Zero</code> class implements <code>INaturalNumber</code> by always returning <code>zero</code>, and consequently always ignoring <code>succ</code>. </p> <p> Another class, <code>Successor</code>, handles the right-hand side of the <code>Match</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Successor</span>&nbsp;:&nbsp;<span style="color:#2b91af;">INaturalNumber</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;predecessor; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Successor(<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.predecessor&nbsp;=&nbsp;n; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;zero,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">INaturalNumber</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;&nbsp;succ) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;succ(predecessor); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that <code>Successor</code> composes its <code>predecessor</code> via Constructor Injection, and unconditionally calls <code>succ</code> with its <code>predecessor</code> when <code>Match</code> is invoked. </p> <h3 id="8ea8a3a6f4b245a3b7375da29ec4c93c"> Working with natural numbers <a href="#8ea8a3a6f4b245a3b7375da29ec4c93c" title="permalink">#</a> </h3> <p> What can you do with this <code>INaturalNumber</code> API, then? </p> <p> Initially, you can define some numbers, like the above Haskell examples: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NaturalNumber</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;Zero&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Zero</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;&nbsp;One&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Zero); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;&nbsp;Two&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(One); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;Three&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Two); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;Four&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Three); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;Five&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Four); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;&nbsp;Six&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Five); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;Seven&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Six); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;Eight&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Seven); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;&nbsp;Nine&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(Eight); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;memmbers&nbsp;go&nbsp;here...</span> }</pre> </p> <p> Here, I arbitrarily chose to define the numbers from zero to nine, but you could go on for as long as you care. </p> <p> You can also convert these Church-encoded numbers to primitive <code>int</code> values, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Count(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;n.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p&nbsp;=&gt;&nbsp;1&nbsp;+&nbsp;p.Count()); }</pre> </p> <p> Here are some examples from a C# Interactive session: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.Zero.Count() 0 &gt; <span style="color:#2b91af;">NaturalNumber</span>.One.Count() 1 &gt; <span style="color:#2b91af;">NaturalNumber</span>.Seven.Count() 7</pre> </p> <p> The implementation of <code>Count</code> is recursive. When <code>n</code> is a <code>Zero</code> instance, it'll return the first argument (<code>0</code>), but when it's a <code>Successor</code>, it'll invoke the lambda expression <code>p =&gt; 1 + p.Count()</code>. Notice that this lambda expression recursively calls <code>Count</code> on <code>p</code>, which is the <code>Successor</code>'s <code>predecessor</code>. It'll keep doing that until it reaches a <code>Zero</code> instance. </p> <p> Recursion is a central part of the lambda calculus; you can't do anything useful without it. If you're a C# or Java programmer, you may be concerned, because recursion tends to be problematic in such languages. Deeply recursive functions will sooner or later crash because of a stack overflow. </p> <p> You shouldn't, however, be concerned. First, I'm not trying to convince you to write all your future C# or Java code using Church-encoded numbers and Boolean values. The point of this article series is to investigate the fundamentals of computations, and to gain a better understanding of sum types. As such, the code examples presented here are only demonstrations of the underlying principles. Lambda calculus itself serves the same purpose: it's a universal model of computation; it wasn't intended to be a practical programming language - in fact, there were no programmable computers in 1936. </p> <p> Furthermore, the problem with recursion causing stack overflow isn't universal. Languages like <a href="http://fsharp.org">F#</a> and Haskell support <a href="https://en.wikipedia.org/wiki/Tail_call">tail recursion</a>, thereby enabling recursive functions to run to arbitrary depths. </p> <h3 id="a13730f3e8c54cd98beb1801b07a4707"> Pattern matching <a href="#a13730f3e8c54cd98beb1801b07a4707" title="permalink">#</a> </h3> <p> In the previous article, I hinted that there's a reason I decided to name the interface method <code>Match</code>. This is because it looks a lot like <a href="https://en.wikipedia.org/wiki/Pattern_matching">pattern matching</a>. In F#, you could write <code>count</code> like this: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;Peano&nbsp;=&nbsp;Zero&nbsp;|&nbsp;Succ&nbsp;<span style="color:blue;">of</span>&nbsp;Peano <span style="color:green;">//&nbsp;Peano&nbsp;-&gt;&nbsp;int</span> <span style="color:blue;">let</span>&nbsp;<span style="color:blue;">rec</span>&nbsp;count&nbsp;n&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;n&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;0 &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;p&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;1&nbsp;+&nbsp;count&nbsp;p</pre> </p> <p> This implementation, by the way, isn't tail-recursive, but you can <a href="http://blog.ploeh.dk/2015/12/22/tail-recurse">easily refactor to a tail-recursive implementation</a> like this: </p> <p> <pre><span style="color:green;">//&nbsp;Peano&nbsp;-&gt;&nbsp;int</span> <span style="color:blue;">let</span>&nbsp;count&nbsp;n&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;<span style="color:blue;">rec</span>&nbsp;countImp&nbsp;acc&nbsp;n&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;n&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;acc &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;p&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;countImp&nbsp;(1&nbsp;+&nbsp;acc)&nbsp;p &nbsp;&nbsp;&nbsp;&nbsp;countImp&nbsp;0&nbsp;n</pre> </p> <p> Both variations use the <code>match</code> keyword to handle both the <code>Zero</code> and the <code>Succ</code> case for any <code>Peano</code> value <code>n</code>. That's already close to the above C# code, but using the optional C# language feature of <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments">named arguments</a>, you can rewrite the implementation of <code>Count</code> to this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Count(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;n.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;zero:&nbsp;0, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;succ:&nbsp;p&nbsp;=&gt;&nbsp;1&nbsp;+&nbsp;p.Count()); }</pre> </p> <p> This starts to look like pattern matching of sum types in F#. The argument names aren't required, but using them makes it clearer which cases the <code>Match</code> method handles. </p> <h3 id="f4beca2d1da24362b4c43cf1f6528616"> Addition <a href="#f4beca2d1da24362b4c43cf1f6528616" title="permalink">#</a> </h3> <p> You can now start to add features and capabilities to the natural numbers API. An obvious next step is to implement addition: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;Add(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;zero:&nbsp;y, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;succ:&nbsp;p&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Successor</span>(p.Add(y))); }</pre> </p> <p> Again, the implementation is recursive. When <code>x</code> is <code>zero</code>, you simply return <code>y</code>, because <em>zero + y</em> is <em>y</em>. When <code>x</code> is a <code>Successor</code>, you recursively add <code>y</code> to its <code>predecessor</code>, and put the result in a new <code>Successor</code>. You can think of the predecessor <code>p</code> as one less than the successor. By recursively subtracting one from any <code>Successor</code> object, you'll eventually match the <code>zero</code> case, which will then return <code>y</code>. When the stack unrolls, each stack puts the previous result into a new <code>Successor</code>. This happens exactly the correct number of times corresponding to the value of <code>x</code>, because that's the size of the stack when <code>Add</code> hits <code>zero</code>. </p> <p> Here are some examples: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.One.Add(<span style="color:#2b91af;">NaturalNumber</span>.Two).Count() 3 &gt; <span style="color:#2b91af;">NaturalNumber</span>.Four.Add(<span style="color:#2b91af;">NaturalNumber</span>.Three).Count() 7 &gt; <span style="color:#2b91af;">NaturalNumber</span>.Seven.Add(<span style="color:#2b91af;">NaturalNumber</span>.Six).Count() 13</pre> </p> <p> You can also implement multiplication, but that's a bit more complicated, and not relevant to the topic of this article (which is how to determine if a number is even or odd). </p> <h3 id="ceb31f7122ea4b258b26d038f0d247bf"> Testing for zero <a href="#ceb31f7122ea4b258b26d038f0d247bf" title="permalink">#</a> </h3> <p> In addition to basic arithmetic, you can also define functions that tell you something about a natural number. We'll start gently with a function that tells us whether or not a number is zero: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;IsZero(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;n.Match&lt;<span style="color:#2b91af;">IChurchBoolean</span>&gt;( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;zero:&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;succ:&nbsp;_&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>()); }</pre> </p> <p> The <code>IsZero</code> method simply returns a <code>ChurchTrue</code> object when <code>n</code> is a <code>Zero</code> instance, and a <code>ChurchFalse</code> object for all other numbers. </p> <p> You can see that this works in this C# Interactive session: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.Two.IsZero() ChurchFalse { } &gt; <span style="color:#2b91af;">NaturalNumber</span>.Zero.IsZero() ChurchTrue { } &gt; <span style="color:#2b91af;">NaturalNumber</span>.Three.IsZero() ChurchFalse { }</pre> </p> <p> You can also <code>Match</code> on the returned Boolean value to return e.g. a string: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.Nine.IsZero().Match(trueCase:&nbsp;<span style="color:#a31515;">&quot;Zero&quot;</span>,&nbsp;falseCase:&nbsp;<span style="color:#a31515;">&quot;Not&nbsp;zero&quot;</span>) "Not zero" &gt; <span style="color:#2b91af;">NaturalNumber</span>.Zero.IsZero().Match(trueCase:&nbsp;<span style="color:#a31515;">&quot;Zero&quot;</span>,&nbsp;falseCase:&nbsp;<span style="color:#a31515;">&quot;Not&nbsp;zero&quot;</span>) "Zero"</pre> </p> <p> This already demonstrates that you can implement predicates and branching logic from first principles, without resorting to built-in Boolean primitives or operators. </p> <h3 id="c131713ecba247f98cc1b93e0fb8451b"> Detecting even numbers <a href="#c131713ecba247f98cc1b93e0fb8451b" title="permalink">#</a> </h3> <p> Testing whether a natural number is even or uneven requires a bit more work. It's probably easiest to understand if we first consider an F# implementation: </p> <p> <pre><span style="color:green;">//&nbsp;Peano&nbsp;-&gt;&nbsp;ChurchBoolean</span> <span style="color:blue;">let</span>&nbsp;<span style="color:blue;">rec</span>&nbsp;isEven&nbsp;n&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;n&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;ChurchTrue &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;ChurchFalse &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;(Succ&nbsp;p)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;isEven&nbsp;p</pre> </p> <p> Zero is even, so when <code>n</code> matches <code>Zero</code>, <code>isEven</code> returns <code>ChurchTrue</code>. Conversely, when the input is <code>Succ Zero</code> (i.e. <em>one</em>), the return value is <code>ChurchFalse</code> because <em>one</em> is odd. </p> <p> The <em>zero</em> and <em>one</em> cases serve as exit cases for the recursive algorithm. Since we've handled <code>Zero</code> and <code>Succ Zero</code> (that is, <em>zero</em> and <em>one</em>), we know that any other case must be at least twice nested. This means that the <code>Succ (Succ p)</code> pattern matches all other cases. You can think of <code>p</code> as <em>n - 2</em>. </p> <p> The algorithm proceeds to recursively call <code>isEven</code> with <code>p</code> (i.e. <em>n - 2</em>). Sooner or later, these recursive function calls will match either the <code>Zero</code> or the <code>Succ Zero</code> case, and exit with the appropriate return value. </p> <p> C# doesn't have as sophisticated pattern matching features as F#, so we're going to have to figure out how implement this algorithm without relying on a nested pattern like <code>Succ (Succ p)</code>. As an initial step, we can rewrite the function in F#, using two matches instead of one: </p> <p> <pre><span style="color:green;">//&nbsp;Peano&nbsp;-&gt;&nbsp;ChurchBoolean</span> <span style="color:blue;">let</span>&nbsp;<span style="color:blue;">rec</span>&nbsp;isEven&nbsp;n&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;n&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;ChurchTrue &nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;p1&nbsp;<span style="color:blue;">-&gt;</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">match</span>&nbsp;p1&nbsp;<span style="color:blue;">with</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Zero&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;ChurchFalse &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Succ&nbsp;p2&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;isEven&nbsp;p2</pre> </p> <p> This isn't as elegant as the previous implementation, but on the other hand, it's straightforward to translate to C#: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;IsEven(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;n.Match( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;zero:&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(),&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;0&nbsp;is&nbsp;even,&nbsp;so&nbsp;true</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;succ:&nbsp;p1&nbsp;=&gt;&nbsp;p1.Match(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Match&nbsp;previous</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;zero:&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(),&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;If&nbsp;0&nbsp;then&nbsp;successor&nbsp;was&nbsp;1</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;succ:&nbsp;p2&nbsp;=&gt;&nbsp;p2.IsEven()));&nbsp;<span style="color:green;">//&nbsp;Eval&nbsp;previous&#39;&nbsp;previous</span> }</pre> </p> <p> Like in the F# example, when <code>n</code> is a <code>Zero</code> object, it'll return the value associated with the <code>zero</code> case. Since zero is even, it returns a <code>ChurchTrue</code> object. </p> <p> In all other cases, a <code>Match</code> on the predecessor <code>p1</code> is required. If that nested match is <code>zero</code>, then we know that <code>n</code> must have been <em>one</em>, since the the predecessor turned out to be <em>zero</em>. In that case, then, return a <code>ChurchFalse</code> object, because <em>one</em> isn't even. </p> <p> The nested <code>Match</code> considers the predecessor <code>p1</code>. In the <code>succ</code> case of the nested <code>Match</code>, then, we can consider <code>p2</code>; that is, the predecessor to the predecessor to <code>n</code> - in other words: <em>n - 2</em>. The function recursively calls itself with <em>n - 2</em>, and it'll keep doing so until it matches either the <em>zero</em> or the <em>one</em> case. </p> <p> The implementation works: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.Two.IsEven() ChurchTrue { } &gt; <span style="color:#2b91af;">NaturalNumber</span>.Three.IsEven() ChurchFalse { }</pre> </p> <p> <code>IsEven</code> is implemented from first principles. The only language features we need are lambda expressions and recursion, although in order to make these examples slightly more <a href="http://blog.ploeh.dk/2015/08/03/idiomatic-or-idiosyncratic">idiomatic</a>, I've also used interfaces and classes. </p> <h3 id="d4be671469fb4f529db9afd3e2626dd1"> Detecting odd numbers <a href="#d4be671469fb4f529db9afd3e2626dd1" title="permalink">#</a> </h3> <p> You could implement a corresponding <code>IsOdd</code> method similarly to <code>IsEven</code>, but it's easier to use the Boolean operators already in place from the previous article: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;IsOdd(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">INaturalNumber</span>&nbsp;n) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchNot</span>(n.IsEven()); }</pre> </p> <p> <code>IsOdd</code> is simply the Boolean negation of <code>IsEven</code>. Like <code>IsEven</code> it also works correctly: </p> <p> <pre>&gt; <span style="color:#2b91af;">NaturalNumber</span>.Six.IsOdd().Match(trueCase:&nbsp;<span style="color:#a31515;">&quot;Odd&quot;</span>,&nbsp;falseCase:&nbsp;<span style="color:#a31515;">&quot;Even&quot;</span>) "Even" &gt; <span style="color:#2b91af;">NaturalNumber</span>.Seven.IsOdd().Match(trueCase:&nbsp;<span style="color:#a31515;">&quot;Odd&quot;</span>,&nbsp;falseCase:&nbsp;<span style="color:#a31515;">&quot;Even&quot;</span>) "Odd"</pre> </p> <p> You can implement other operators (like multiplication) and predicates from the building blocks shown here, but I'm not going to cover that here (see <a href="https://github.com/ploeh/ChurchEncoding/tree/a8512fe004dc7da41fa17b069a6c245c31b97d7c">the accompanying GitHub repository for more code</a>). I hope that this article gave you a sense of how a programming language can be designed from the low-level building blocks defined by the lambda calculus. </p> <h3 id="b4be8911648f4dcab6191fd50c03581a"> Summary <a href="#b4be8911648f4dcab6191fd50c03581a" title="permalink">#</a> </h3> <p> <a href="https://en.wikipedia.org/wiki/Giuseppe_Peano">Giuseppe Peano</a> described natural numbers as an initial number (zero) and successors to that number. Church formulated Peano numbers in the lambda calculus. Using Church encoding, you can translate this representation to various programming languages, including, as you've seen in this article, C#. </p> <p> In the previous article, you saw how to model Boolean values as a set of functions with two arguments. In this article, you saw how to model natural numbers with another set of functions that take two arguments. In the next article, you'll see another data type modelled as a set of functions with two arguments. It looks like a patterns is starting to appear. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/06/04/church-encoded-maybe">Church-encoded Maybe</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church-encoded Boolean values http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values 2018-05-24T04:49:00+00:00 Mark Seemann <div id="post"> <p> <em>Boolean values, and logical branching, don't have to be built into programming languages. An introduction for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">a series of articles about Church encoding</a>. </p> <p> Years ago, the so-called <a href="http://www.antiifcampaign.com">Anti-IF Campaign</a> made the rounds on various social media (back then, IIRC, mostly known as 'the blogosphere'). The purpose of the campaign was never to eradicate every single use of <code>if</code> statements or expressions in source code, but rather to educate people about alternatives to the <a href="http://wiki.c2.com/?ArrowAntiPattern">Arrow anti-pattern</a>. </p> <p> One easy way to deal with arrow code is to <a href="https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html">Replace Nested Conditionals with Guard Clauses</a>, but that's not always possible. Another way is to encapsulate some <code>if</code> blocks in helper methods. Yet another way would be to use polymorphic dispatch, but how does that even work? Don't you, deep down, need at least a few <code>if</code> keywords here and there? </p> <p> It turns out that the answer, surprisingly, is <em>no</em>. </p> <h3 id="3215aad4142e466393c8a533e4bda305"> Untyped Boolean functions <a href="#3215aad4142e466393c8a533e4bda305" title="permalink">#</a> </h3> <p> <code>if/then/else</code> expressions are based on Boolean values (<em>true</em> and <em>false</em>): if some Boolean value is true, then something happens; otherwise, something else happens. Most programming languages, including C, C++, Java, C#, and JavaScript, have a <a href="https://en.wikipedia.org/wiki/%3F:">ternary operator</a>, which in C# looks like this: </p> <p> <pre>isEven&nbsp;?&nbsp;<span style="color:#a31515;">&quot;Probably&nbsp;not&nbsp;a&nbsp;prime.&quot;</span>&nbsp;:&nbsp;<span style="color:#a31515;">&quot;Could&nbsp;be&nbsp;a&nbsp;prime.&quot;</span>;</pre> </p> <p> You can think of an expression like that as a function that takes a Boolean value and two potential return values: one for the <em>true</em> case, and one for the <em>false</em> case. </p> <p> In <a href="https://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a>, the only primitive building blocks are functions. There's no built-in Boolean values, but you can define them with functions. Boolean values are functions that take two arguments. By conventions, the first argument (the one to the left) represents the <em>true</em> case, whereas the second argument (to the right) signifies the <em>false</em> case - just like the ternary operator. In the lambda calculus, functions are curried, but we know from <a href="http://blog.ploeh.dk/2018/02/05/uncurry-isomorphisms">uncurry isomorphisms</a> that we can also represent a two-argument function as a function that takes a two-tuple (a <em>pair</em>) as a single argument. Furthermore, we know from <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">function isomorphisms</a> that we can represent a function as an instance method. Therefore, we can declare a Boolean value in C# to be an object that implements this interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase); }</pre> </p> <p> You'll notice that I've chosen to call the method <code>Match</code>, for reasons that should hopefully become clear as we go along. </p> <p> The intent with such a Church-encoded Boolean is that any object that represents <em>true</em> should return the left argument (<code>trueCase</code>), whereas an object that represents <em>false</em> should return the right argument (<code>falseCase</code>). </p> <p> In other words, <em>true</em> is an interface implementation: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;trueCase; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that this implementation always returns <code>trueCase</code> while ignoring <code>falseCase</code>. No explicit <code>if</code> statement is required. </p> <p> Likewise, <em>false</em> is implemented the same way: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;falseCase; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> So far, this doesn't offer much capability, but it does already give you the ability to choose between two values, as this little C# Interactive session demonstrates: </p> <p> <pre>&gt; var b = new ChurchTrue(); &gt; b.Match("foo", "bar") "foo" &gt; var b = new ChurchFalse(); &gt; b.Match("foo", "bar") "bar"</pre> </p> <p> When 'the Boolean value' is a <code>ChurchTrue</code> instance, then the left argument is returned; otherwise, when <code>b</code> is a <code>ChurchFalse</code> object, the return value is the right-hand value - just like the ternary operator. </p> <h3 id="1ebf901dbc234074a98b809ebeb570b1"> Boolean And <a href="#1ebf901dbc234074a98b809ebeb570b1" title="permalink">#</a> </h3> <p> You can now define the standard Boolean operators <em>and</em>, <em>or</em>, and <em>not</em>. Starting with <em>and:</em> </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChurchAnd</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ChurchAnd(<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.x&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x.Match(y.Match(trueCase,&nbsp;falseCase),&nbsp;falseCase); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>ChurchAnd</code> class is an implementation of <code>IChurchBoolean</code> that composes two other <code>IChurchBoolean</code> values, <code>x</code> and <code>y</code>. You can use it like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;b&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchAnd</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(),&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>()); </pre> </p> <p> In this case, <code>b</code> represents <em>false</em>, because it'll always return the right-hand argument when <code>Match</code> is invoked. </p> <p> Notice that the implementation of <code>ChurchAnd.Match</code> first matches on <code>x</code>. Only if <code>x</code> itself is <em>true</em> can the expression passed as the first argument be returned; otherwise, <code>falseCase</code> will be returned. Thus, if <code>x</code> is <em>true</em>, the expression <code>y.Match(trueCase, falseCase)</code> will be returned, and only if that as well evaluates to <em>true</em> is the final result <em>true</em>. The <code>trueCase</code> value is only returned if <code>y</code> represents <em>true</em>, as well as <code>x</code>. </p> <p> In the lambda calculus, Boolean <em>and</em> is defined like this: </p> <p> <pre>and = λx.λy.λt.λf.x (y t f) f</pre> </p> <p> The way to read this is that Boolean <em>and</em> is a function that takes four arguments: <ul> <li><code>x</code>, a Boolean value</li> <li><code>y</code>, another Boolean value</li> <li><code>t</code>, the value to return if the expression is <em>true</em>; the <code>trueCase</code> argument in the above C# implementation.</li> <li><code>f</code>, the value to return if the expression is <em>false</em>; the <code>falseCase</code> argument in the above C# implementation.</li> </ul> Recall that in the lambda calculus, Boolean values are functions that take two arguments, so <code>x</code> and <code>y</code> are functions. <code>and</code> calls <code>x</code> with two arguments. Since Boolean <em>and</em> requires both <code>x</code> and <code>y</code> to be <em>true</em>, it passes <code>f</code> as the second argument to <code>x</code>, because if <code>x</code> represents <em>false</em>, it'll return its right-hand argument. Only if <code>x</code> represents <em>true</em> does it make sense to investigate the Boolean value of <code>y</code>, which is also a function that takes two arguments. Only if <code>y</code> also represents <em>true</em> will <code>t</code> be returned. </p> <p> This is exactly the same implementation as the above C# code. </p> <p> Wait a minute, though, didn't I write that Boolean values are functions that take two arguments? And isn't <code>and</code> a function that takes four arguments? </p> <p> Yes, indeed. That's how currying works. You can view <code>and</code> as a function that takes four arguments, but you can also view it as a function that takes two arguments (<code>x</code> and <code>y</code>) and returns another function that takes two arguments. This becomes clearer with partial application. When translating to C#, the 'contract' (that a Boolean value is a function that takes two arguments) is modelled as the interface <code>IChurchBoolean</code>, while the 'extra arguments' <code>x</code> and <code>y</code> become class fields, injected via the class' constructor. </p> <h3 id="33ba3de3f9bd46fabbc0b44935578c15"> Boolean Or <a href="#33ba3de3f9bd46fabbc0b44935578c15" title="permalink">#</a> </h3> <p> In the lambda calculus, Boolean <em>or</em> is defined like this: </p> <p> <pre>or = λx.λy.λt.λf.x t (y t f)</pre> </p> <p> Translated to C#, this becomes: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChurchOr</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ChurchOr(<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.x&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x.Match(trueCase,&nbsp;y.Match(trueCase,&nbsp;falseCase)); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> You can see that this is another direct translation. Boolean <em>or</em> only requires (at least) one of the Boolean values to be <em>true</em>, so if <code>x</code> is <em>true</em>, you can immediately return <code>trueCase</code>. Otherwise, in the case where <code>x</code> is <em>false</em>, there's still a chance that the entire expression could be <em>true</em>, so you'll have to evaluate <code>y</code> as well. When <code>y</code> represents <em>true</em>, you can still return <code>trueCase</code>. Only when <code>y</code> is also <em>false</em> should you return <code>falseCase</code>. </p> <p> You can use <code>ChurchOr</code> like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;b&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchOr</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>(),&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>()); </pre> </p> <p> Here, <code>b</code> is <em>true</em> because <em>true or false</em> is <em>true</em>. </p> <h3 id="3238c67454fe4463946b9625c447571a"> Boolean Not <a href="#3238c67454fe4463946b9625c447571a" title="permalink">#</a> </h3> <p> Finally, you can also define Boolean negation. In lambda calculus it's: </p> <p> <pre>not = λx.λt.λf.x f t</pre> </p> <p> Notice how this simply swaps the arguments passed to <code>x</code>. In C#, this translates to: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ChurchNot</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;b; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;ChurchNot(<span style="color:#2b91af;">IChurchBoolean</span>&nbsp;b) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.b&nbsp;=&nbsp;b; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">object</span>&nbsp;Match(<span style="color:blue;">object</span>&nbsp;trueCase,&nbsp;<span style="color:blue;">object</span>&nbsp;falseCase) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;b.Match(falseCase,&nbsp;trueCase); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> You can combine all the Boolean operators like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;b&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchOr</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchFalse</span>(),&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchNot</span>(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ChurchTrue</span>())); </pre> </p> <p> Here, <code>b</code> is <em>false</em> because <em>false or (not true)</em> is <em>false</em>. </p> <h3 id="5a06c7f9d7b04b31a8f4ca6ab9b28ca4"> Typed Boolean functions <a href="#5a06c7f9d7b04b31a8f4ca6ab9b28ca4" title="permalink">#</a> </h3> <p> So far, the <code>IChurchBoolean</code> interface has been untyped, in the sense that it took <code>object</code> arguments and had an <code>object</code> return type. You can, however, easily make the interface strongly typed, using generics: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IChurchBoolean</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Match&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;trueCase,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;falseCase); }</pre> </p> <p> This doesn't really change the rest of the code you've seen in this article. The method signatures chance, but the implementations remain as shown. You can see the change in <a href="https://github.com/ploeh/ChurchEncoding/commit/2cba6d7625b08054caf6f42cc30898ced704848f">this commit</a>. </p> <h3 id="9821112728f64424b39990eb26ede2b8"> Semigroups and monoids <a href="#9821112728f64424b39990eb26ede2b8" title="permalink">#</a> </h3> <p> The strongly typed signature accentuates that the <code>Match</code> method is a binary operation; it takes two values of the type <code>T</code> and returns a single <code>T</code> value. Is it a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>, then? </p> <p> It's not a single monoid, but rather a collection of <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroups</a>, some of which are monoids as well. The implementation of <code>ChurchTrue</code> corresponds to the <em>first</em> semigroup, and <code>ChurchFalse</code> to the <em>last</em> semigroup. You can make this explict in <a href="https://www.haskell.org">Haskell</a>: </p> <p> <pre><span style="color:blue;">import</span>&nbsp;Data.Semigroup <span style="color:#2b91af;">churchTrue</span>&nbsp;::&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a churchTrue&nbsp;t&nbsp;f&nbsp;=&nbsp;getFirst&nbsp;(First&nbsp;t&nbsp;&lt;&gt;&nbsp;First&nbsp;f)</pre> </p> <p> If you compare this implementation of <code>churchTrue</code> to the <a href="http://programmable.computer/posts/church_encoding.html">Travis Whitaker's <code>true</code> function</a>, his is much simpler. I'm not suggesting that using <code>First</code> is better; I'm only trying to illustrate the connection. </p> <p> If you aren't familiar with how things are done in Haskell, <code>&lt;&gt;</code> is the 'generic semigroup binary operator'. What it does depends on the type of expressions surrounding it. By wrapping both <code>t</code> and <code>f</code> in <code>First</code> containers, the <code>&lt;&gt;</code> operator becomes the operator that always returns the first argument (i.e. <code>First t</code>). Since the result is a <code>First</code> value, you have to unwrap it again by applying <code>getFirst</code>. </p> <p> Likewise, you can define <em>false:</em> </p> <p> <pre><span style="color:#2b91af;">churchFalse</span>&nbsp;::&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a churchFalse&nbsp;t&nbsp;f&nbsp;=&nbsp;getLast&nbsp;(Last&nbsp;t&nbsp;&lt;&gt;&nbsp;Last&nbsp;f)</pre> </p> <p> This still uses the <code>&lt;&gt;</code> operator, but now with the <code>Last</code> container, which gives it all the behaviour of the <em>last</em> semigroup. </p> <p> The <em>any</em> and <em>all</em> monoids are implemented as compositions of these two fundamental semigroups. In the C# code in this article, they're implemented by <code>ChurchAnd</code> and <code>ChurchOr</code>, although in neither case have I defined an explicit identity value. This is, however, possible, so let's continue with the Haskell code to see what that would look like. First, you can define the 'naked' operations: </p> <p> <pre>churchAnd&nbsp;x&nbsp;y&nbsp;t&nbsp;f&nbsp;=&nbsp;x&nbsp;(y&nbsp;t&nbsp;f)&nbsp;f churchOr&nbsp;x&nbsp;y&nbsp;t&nbsp;f&nbsp;=&nbsp;x&nbsp;t&nbsp;(y&nbsp;t&nbsp;f)</pre> </p> <p> I have here omitted the type signatures on purpose, as I believe they might confuse rather than help. In both cases, the logic is the same as in the above <code>ChurchAnd</code> and <code>ChurchOr</code> classes, although, as you can see, Haskell code is much terser. </p> <p> These two functions already work as desired, but we can easily turn both into their respective monoids. First, the <em>all</em> monoid: </p> <p> <pre><span style="color:blue;">newtype</span>&nbsp;ChurchAll&nbsp;=&nbsp;ChurchAll&nbsp;{&nbsp;runAll&nbsp;::&nbsp;forall&nbsp;a.&nbsp;a&nbsp;-&gt;&nbsp;a&nbsp;-&gt;&nbsp;a&nbsp;} <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Semigroup</span>&nbsp;<span style="color:blue;">ChurchAll</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;&nbsp;&nbsp;ChurchAll&nbsp;x&nbsp;&lt;&gt;&nbsp;ChurchAll&nbsp;y&nbsp;=&nbsp;ChurchAll&nbsp;(churchAnd&nbsp;x&nbsp;y) <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Monoid</span>&nbsp;<span style="color:blue;">ChurchAll</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;&nbsp;&nbsp;mempty&nbsp;=&nbsp;ChurchAll&nbsp;churchTrue &nbsp;&nbsp;&nbsp;&nbsp;mappend&nbsp;=&nbsp;<span style="color:#2b91af;">(&lt;&gt;)</span></pre> </p> <p> In order for this code to compile, you must enable the <em>RankNTypes</em> language extension, which I did by adding the <code>{-# LANGUAGE RankNTypes #-}</code> pragma to the top of my code file. The <code>forall a</code> declaration corresponds to the <code>&lt;T&gt;</code> type annotation on the C# <code>Match</code> method. You can think of this as that the type argument is scoped to the function instead of the type. </p> <p> The <code>Semigroup</code> instance simply delegates its behaviour to <code>churchAnd</code>, and the <code>Monoid</code> instance returns <code>churchTrue</code> as the identity (<code>mempty</code>). </p> <p> Similarly, you can implement the <em>any</em> monoid: </p> <p> <pre><span style="color:blue;">newtype</span>&nbsp;ChurchAny&nbsp;=&nbsp;ChurchAny&nbsp;{&nbsp;runAny&nbsp;::&nbsp;forall&nbsp;a.&nbsp;a&nbsp;-&gt;&nbsp;a&nbsp;-&gt;&nbsp;a&nbsp;} <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Semigroup</span>&nbsp;<span style="color:blue;">ChurchAny</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;&nbsp;&nbsp;ChurchAny&nbsp;x&nbsp;&lt;&gt;&nbsp;ChurchAny&nbsp;y&nbsp;=&nbsp;ChurchAny&nbsp;(churchOr&nbsp;x&nbsp;y) <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Monoid</span>&nbsp;<span style="color:blue;">ChurchAny</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;&nbsp;&nbsp;mempty&nbsp;=&nbsp;ChurchAny&nbsp;churchFalse &nbsp;&nbsp;&nbsp;&nbsp;mappend&nbsp;=&nbsp;<span style="color:#2b91af;">(&lt;&gt;)</span></pre> </p> <p> As is also the case with <code>ChurchAll</code>, the <code>ChurchAny</code> instance of <code>Semigroup</code> simply delegates to a 'naked' function (in this case <code>churchOr</code>), and the <code>Monoid</code> instance again delegates <code>mappend</code> to <code>&lt;&gt;</code> and returns <code>churchFalse</code> as the identity. </p> <p> The following brief GHCi session demonstrates that it all works as intended: </p> <p> <pre>λ&gt; runAny (ChurchAny churchTrue &lt;&gt; ChurchAny churchFalse) "foo" "bar" "foo" λ&gt; runAny (ChurchAny churchFalse &lt;&gt; ChurchAny churchFalse) "foo" "bar" "bar" λ&gt; runAll (ChurchAll churchFalse &lt;&gt; ChurchAll churchTrue) "foo" "bar" "bar" λ&gt; runAll (ChurchAll churchTrue &lt;&gt; ChurchAll churchTrue) "foo" "bar" "foo"</pre> </p> <p> Recall that a Church-encoded Boolean is a function that takes two values - in all the four above examples <code>"foo"</code> and <code>"bar"</code>. When the expression represents <em>true</em> it returns the left-hand value (<code>"foo"</code>); otherwise, it returns the right-hand value (<code>"bar"</code>). </p> <p> In summary, the Church-encoded Boolean values <em>true</em> and <em>false</em> correspond to the <em>first</em> and <em>last</em> semigroups. You can compose the well-known monoids over Boolean values using these two basic building blocks. </p> <h3 id="b0ac2fd3255c4c61af0f6ddb4f95b365"> Summary <a href="#b0ac2fd3255c4c61af0f6ddb4f95b365" title="permalink">#</a> </h3> <p> You'd normally think of Boolean values as language primitives. <em>True</em> and <em>false</em> are built into most languages, as well as common operators like <em>and</em>, <em>or</em>, and <em>not</em>. While this is convenient, it doesn't <em>have</em> to be like this. Even in languages that already have built-in support for Boolean values, like Haskell or C#, you can define Church-encoded Boolean values from first principles. </p> <p> In the lambda calculus, a Boolean value is function that takes two arguments and returns the left-hand argument when <em>true</em>, and the right-hand argument when <em>false</em>. </p> <p> At this point, it may seem like you can't do much with the <code>IChurchBoolean</code> API. How could you, for instance, determine whether an integer is even or odd? </p> <p> This innocuous-looking question is harder to answer than you may think, so that's worthy of its own article. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">Church-encoded natural numbers</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Church encoding http://blog.ploeh.dk/2018/05/22/church-encoding 2018-05-22T06:28:00+00:00 Mark Seemann <div id="post"> <p> <em>Church encoding is a unified way to model data and functions. An introduction for object-oriented developers.</em> </p> <p> This article series is part of <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">an even larger series of articles about the relationship between design patterns and category theory.</a> </p> <p> When asked why I like functional programming so much, I often emphasise the <a href="http://blog.ploeh.dk/2016/02/10/types-properties-software-designing-with-types">superior modelling ability</a> that I get from <a href="https://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data types</a>. Particularly, languages like <a href="http://fsharp.org">F#</a> and <a href="https://www.haskell.org">Haskell</a> have <a href="https://en.wikipedia.org/wiki/Tagged_union">sum types</a> in addition to the <a href="https://en.wikipedia.org/wiki/Product_type">product types</a> that most statically typed languages seem to have. </p> <p> In short, a <em>sum type</em> gives you the ability to declare, as part of the type system, that a particular data type must be exactly one of a <em>finite</em> list of mutually exclusive options. This differs from common object-oriented sub-typing because class inheritance or interface implementation offers conceptually infinite extensibility. Sometimes, unconstrained extensibility is exactly what you need, but in other cases, the ability to define a closed set of cases can be an effective modelling tool. If you need an easy-to-read introduction to algebraic data types, I recommend <a href="http://tomasp.net">Tomas Petricek</a>'s fine article <a href="http://tomasp.net/blog/types-and-math.aspx">Power of mathematics: Reasoning about functional types</a>. </p> <p> Interestingly, <a href="https://www.typescriptlang.org/docs/handbook/advanced-types.html">TypeScript has sum types</a>, so they don't have to belong exclusively in the realm of functional programming. In this article series, you'll see an alternative way to represent sum types in C# using <em>Church encoding</em>. </p> <h3 id="981c0967cd414784968a1ceded3f9f45"> Lambda calculus <a href="#981c0967cd414784968a1ceded3f9f45" title="permalink">#</a> </h3> <p> In the 1930s, several mathematicians were investigating the foundations of mathematics. One of them, <a href="https://en.wikipedia.org/wiki/Alonzo_Church">Alonzo Church</a>, developed <a href="https://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a> as a universal model of computation. In a sense, you can think of lambda calculus as a sort of hypothetical programming language, although it was never designed to be a practical programming language. Even so, you can learn a lot from it. </p> <p> In the untyped lambda calculus, the only primitive data type is a function. There are no primitive numbers, Boolean values, branching instructions, loops, or anything else you'd normally consider as parts of a programming language. Instead, there's only functions, written as <em>lambda expressions:</em> </p> <p> <pre>λf.λx.f x</pre> </p> <p> This looks opaque and mathematical, but most modern programmers should be familiar with lambda (λ) expressions. The above expression is an anonymous function that takes a single argument: <code>f</code>. The body of the function is the return value; here, another lambda expression: <code>λx.f x</code>. This lambda expression also takes a single argument: <code>x</code>. </p> <p> In the untyped lambda calculus, everything is a function, so that includes <code>f</code> and <code>x</code>. The return value of the entire expression is <code>f x</code>, which means that the function <code>f</code> is applied to the value (in fact: function) <code>x</code>. The entire expression is therefore a <a href="https://en.wikipedia.org/wiki/Higher-order_function">higher-order function</a>. </p> <p> In C#, the corresponding lambda expression would be: </p> <p> <pre>f =&gt; x =&gt; f(x)</pre> </p> <p> This is a lambda expression that returns another lambda expression, which again returns the result of calling the function <code>f</code> with the value <code>x</code>. </p> <p> In F#, it would be: </p> <p> <pre>fun f -&gt; fun x -&gt; f x</pre> </p> <p> and in Haskell, it would be: </p> <p> <pre>\f -&gt; \x -&gt; f x</pre> </p> <p> In both Haskell and F#, functions are already curried, so you can shorten that Haskell lambda expression to: </p> <p> <pre>\f x -&gt; f x</pre> </p> <p> and the F# lambda expression to: </p> <p> <pre>fun f x -&gt; f x</pre> </p> <p> This looks more like a function that takes two arguments, so alternatively, via <a href="http://blog.ploeh.dk/2018/02/05/uncurry-isomorphisms">uncurry isomorphisms</a>, you can also write the C# representation like this: </p> <p> <pre>(f, x) =&gt; f(x)</pre> </p> <p> Those six lambda expressions, however, are statically typed, even though they're generic (or, as Haskellers would put it, <a href="https://en.wikipedia.org/wiki/Parametric_polymorphism">parametric polymorphic</a>). This means that they're not entirely equal to <code>λf.λx.f x</code>, but it should give you a sense of what a lambda expression is. </p> <p> It turns out that using nothing but lambda expressions, one can express any computation; lambda calculus is Turing-complete. </p> <h3 id="a921177fdc9e485389b476ab7f599aa7"> Church encoding <a href="#a921177fdc9e485389b476ab7f599aa7" title="permalink">#</a> </h3> <p> Since languages like C#, F#, Haskell, and others, include lambda expressions, you can reproduce as much of the lambda calculus as you'd like. In this article series, I'll mainly use it to show you how to represent sum types in C#. Later, you'll see how it relates to design patterns. </p> <p> <ul> <li><a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">Church-encoded Boolean values</a></li> <li><a href="http://blog.ploeh.dk/2018/05/28/church-encoded-natural-numbers">Church-encoded natural numbers</a></li> <li><a href="http://blog.ploeh.dk/2018/06/04/church-encoded-maybe">Church-encoded Maybe</a></li> <li><a href="http://blog.ploeh.dk/2018/06/11/church-encoded-either">Church-encoded Either</a></li> <li><a href="http://blog.ploeh.dk/2018/06/18/church-encoded-payment-types">Church-encoded payment types</a></li> </ul> </p> <p> These articles give you examples in C#. For Haskell examples, I found <a href="http://programmable.computer">Travis Whitaker</a>'s article <a href="http://programmable.computer/posts/church_encoding.html">Scrap Your Constructors: Church Encoding Algebraic Types</a> useful. </p> <p> All C# code for these articles is <a href="https://github.com/ploeh/ChurchEncoding">available on GitHub</a>. </p> <h3 id="36ea9ca3c38842ed906e2b02d175d116"> Summary <a href="#36ea9ca3c38842ed906e2b02d175d116" title="permalink">#</a> </h3> <p> You can use lambda expressions to define all sorts of data types and computations. Because lambda calculus is a universal model of computation, you can learn about fundamental representations of computation. Particularly, lambda calculus offers a model of logical branching, which again teaches us how to model sum types. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/05/24/church-encoded-boolean-values">Church-encoded Boolean values</a>. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="e42f37bb7e4440609b922f07211c591c"> <div class="comment-author"><a href="http://github.com/jamesfoster">James Foster</a></div> <div class="comment-content">Hey Mark, Just watched your Humane Code series so far on <a href="https://cleancoders.com">cleancoders.com</a>. Really enjoying it. Looking forward to the next episode with much anticipation!<br> <br> James</div> <div class="comment-date">2018-05-24 12:42 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Composite as a monoid - a business rules example http://blog.ploeh.dk/2018/05/17/composite-as-a-monoid---a-business-rules-example 2018-05-17T06:45:00+00:00 Mark Seemann <div id="post"> <p> <em>Composites are monoids. An example in C#, F#, and Haskell.</em> </p> <p> Towards the end of the first decade of the third millennium, I'd been writing object-oriented code for about ten years, and I'd started to notice some patterns in my code. I'd read <a href="http://amzn.to/XBYukB">Design Patterns</a> 6-7 years earlier, but I noticed that I tended to use only a small subset of the patterns from the book - particularly <a href="https://en.wikipedia.org/wiki/Composite_pattern">Composite</a>, <a href="https://en.wikipedia.org/wiki/Decorator_pattern">Decorator</a>, <a href="https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern">Chain of Responsibility</a>, and a few others. </p> <p> In particular, I noticed that modelling seemed to be easier, and the code better structured, when I could apply the Composite design pattern. It was also clear, however, that I couldn't always use the Composite pattern, so I started to speculate on what could be the distinguishing factors. In 2010, I made <a href="http://blog.ploeh.dk/2010/12/03/Towardsbetterabstractions">a first attempt at identifying when a Composite is possible</a>, and when it isn't. Unfortunately, while it was a fine attempt (which I'll return to later), it didn't lead anywhere. Ultimately, I gave up on the subject and moved on to other things. </p> <h3 id="84b7af9ddccf4ea7a113f356039d582d"> A revelation <a href="#84b7af9ddccf4ea7a113f356039d582d" title="permalink">#</a> </h3> <p> One of my interests in the next decade became functional programming. One day in late 2016 I came across <a href="https://codereview.stackexchange.com/q/149559/3878">this Code Review question</a> by <a href="https://bizmonger.wordpress.com">Scott Nimrod</a>. It was an solution to <a href="http://codekata.com/kata/kata16-business-rules">the Business Rules kata</a>, which, briefly told, is about implementing changing business rules in a sustainable manner. </p> <p> In my answer to the question, I gave an outline (repeated below) of how I would address the problem in <a href="http://fsharp.org">F#</a>. As a comment to my answer, Scott wrote: </p> <p> "Feels like the Decorator Pattern..." </p> <p> I responded, </p> <p> "Not really; it's the Composite pattern..." </p> <p> A few days later, as I was doing something else, it suddenly dawned on me that not only was a few lines of F# code equivalent to the Composite design pattern, but those lines of code were also manifestations of fundamental abstractions from <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a>. Originally, I thought Composite was a combination of applicative functors and <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>, but as I investigated, I discovered that <a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">Composites are simply monoids</a>. </p> <p> This article shows a concrete example of that discovery, starting with my original F# code, subsequently translating it to C# to demonstrate that it's a Composite, and concluding with a translation to <a href="https://www.haskell.org">Haskell</a> in order to demonstrate that it all fits with the formalisation of <code>Monoid</code> there. </p> <h3 id="b2833023b804484db532f3626bad6b0c"> Original F# solution outline <a href="#b2833023b804484db532f3626bad6b0c" title="permalink">#</a> </h3> <p> The kata is about modelling volatile business rules in a sustainable manner. Particularly, you must implement various business rules associated with payments for products and services. Making a rough outline of a model, I started by introducing some types in F#: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;Membership&nbsp;=&nbsp;Basic&nbsp;|&nbsp;Gold <span style="color:blue;">type</span>&nbsp;Good&nbsp;= |&nbsp;PhysicalProduct&nbsp;<span style="color:blue;">of</span>&nbsp;string |&nbsp;Book&nbsp;<span style="color:blue;">of</span>&nbsp;string |&nbsp;Video&nbsp;<span style="color:blue;">of</span>&nbsp;string |&nbsp;Membership&nbsp;<span style="color:blue;">of</span>&nbsp;Membership |&nbsp;Upgrade <span style="color:blue;">type</span>&nbsp;Command&nbsp;= |&nbsp;Slip&nbsp;<span style="color:blue;">of</span>&nbsp;string&nbsp;*&nbsp;(Good&nbsp;list) |&nbsp;Activate&nbsp;<span style="color:blue;">of</span>&nbsp;Membership |&nbsp;Upgrade |&nbsp;PayAgent</pre> </p> <p> This basically states that there's a closed hierarchy of goods, and a closed hierarchy of business commands, as well as a <code>Membership</code> enumeration. A <em>good</em> can be a physical product with a name, a book with a name, a membership or upgrade, and so on. A <em>command</em> can be a packing slip, a membership activation, and so on. </p> <p> Since I was only interested in a rough outline of a solution, I only sketched four business rules, all implemented as functions. The first creates a packing slip for certain goods: </p> <p> <pre><span style="color:green;">//&nbsp;Good&nbsp;-&gt;&nbsp;Command&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;slipForShipping&nbsp;=&nbsp;<span style="color:blue;">function</span> |&nbsp;PhysicalProduct&nbsp;name&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Slip&nbsp;(<span style="color:#a31515;">&quot;Shipping&quot;</span>,&nbsp;[PhysicalProduct&nbsp;name])] |&nbsp;Book&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Slip&nbsp;(<span style="color:#a31515;">&quot;Shipping&quot;</span>,&nbsp;[Book&nbsp;name])] |&nbsp;Video&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Slip&nbsp;(<span style="color:#a31515;">&quot;Shipping&quot;</span>,&nbsp;[Video&nbsp;name])] |&nbsp;_&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[]</pre> </p> <p> This function takes a <code>Good</code> value as input and returns a list of <code>Command</code> values as output. If the <code>Good</code> is a <code>PhysicalProduct</code>, <code>Book</code>, or <code>Video</code>, it returns a packing slip command; otherwise, it returns an empty list of commands. </p> <p> The next business rule is a similar function: </p> <p> <pre><span style="color:green;">//&nbsp;Good&nbsp;-&gt;&nbsp;Command&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;slipForRoyalty&nbsp;=&nbsp;<span style="color:blue;">function</span> |&nbsp;Book&nbsp;name&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Slip&nbsp;(<span style="color:#a31515;">&quot;Royalty&quot;</span>,&nbsp;[Book&nbsp;name])] |&nbsp;_&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[]</pre> </p> <p> This business rule generates a royalty slip for any <code>Book</code>, but does nothing for any other <code>Good</code>. </p> <p> The third business rule activates a membership: </p> <p> <pre><span style="color:green;">//&nbsp;Good&nbsp;-&gt;&nbsp;Command&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;activate&nbsp;=&nbsp;<span style="color:blue;">function</span>&nbsp;|&nbsp;Membership&nbsp;x&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Activate&nbsp;x]&nbsp;|&nbsp;_&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[]</pre> </p> <p> If the <code>Good</code> is a <code>Membership</code>, the <code>activate</code> function returns a list containing a single <code>Activate</code> command; otherwise, it returns an empty list. </p> <p> Finally, the last rule upgrades a membership: </p> <p> <pre><span style="color:green;">//&nbsp;Good&nbsp;-&gt;&nbsp;Command&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;upgrade&nbsp;=&nbsp;<span style="color:blue;">function</span>&nbsp;|&nbsp;Good.Upgrade&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[Upgrade]&nbsp;|&nbsp;_&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[]</pre> </p> <p> Similar to the previous functions, this one looks at the type of <code>Good</code>, and returns an <code>Upgrade</code> command when the input is an <code>Upgrade</code> good, and an empty list otherwise. </p> <p> Notice that all four functions share the same type: <code>Good -&gt; Command list</code>. I designed them like that on purpose, because this enables you to compose a list of business rules to a function that looks like a single rule: </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;list)&nbsp;list&nbsp;-&gt;&nbsp;&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;handle&nbsp;rules&nbsp;good&nbsp;=&nbsp;List.collect&nbsp;(<span style="color:blue;">fun</span>&nbsp;r&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;r&nbsp;good)&nbsp;rules</pre> </p> <p> This <code>handle</code> function takes a list of business rules (<code>rules</code>) and returns a new function with the type <code>Good -&gt; Command list</code> (or, actually, a function with the type <code>'a -&gt; 'b list</code> - once again I've fallen into the trap of <a href="http://blog.ploeh.dk/2015/08/17/when-x-y-and-z-are-great-variable-names">using too descriptive names</a>). Notice that this is the same type as the individual rules. </p> <p> You can now compose the four specific business rules: </p> <p> <pre><span style="color:green;">//&nbsp;Good&nbsp;-&gt;&nbsp;Command&nbsp;list</span> <span style="color:blue;">let</span>&nbsp;handleAll&nbsp;=&nbsp;handle&nbsp;[slipForShipping;&nbsp;slipForRoyalty;&nbsp;activate;&nbsp;upgrade]</pre> </p> <p> This function also has the type <code>Good -&gt; Command list</code> although it's a composition of four rules. </p> <p> You can use it like this <em>F# Interactive</em> example: </p> <p> <pre>&gt; handleAll (Book "The Annotated Turing");; val it : Command list = [Slip ("Shipping",[Book "The Annotated Turing"]); Slip ("Royalty",[Book "The Annotated Turing"])]</pre> </p> <p> (Yes, I like <a href="http://amzn.to/2n9MFGh">The Annotated Turing</a> - read <a href="https://www.goodreads.com/review/show/1731926050">my review on Goodreads</a>.) </p> <p> Notice that while each of the business rules produces only zero or one <code>Command</code> values, in this example <code>handleAll</code> returns two <code>Command</code> values. </p> <p> This design, where a composition looks like the things it composes, sounds familiar. </p> <h3 id="3d1128189a4a4e6ebbb5b1358e85a11f"> Business rules in C# <a href="#3d1128189a4a4e6ebbb5b1358e85a11f" title="permalink">#</a> </h3> <p> You can translate the above F# model to an object-oriented model in C#. Translating <a href="https://en.wikipedia.org/wiki/Tagged_union">discriminated unions</a> like <code>Good</code> and <code>Command</code> to C# always involves compromises. In order to keep the example as simple as possible, I decided to translate each of those to a <a href="https://en.wikipedia.org/wiki/Marker_interface_pattern">marker interface</a>, although I loathe that 'pattern': </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IGood</span>&nbsp;{&nbsp;}</pre> </p> <p> While the interface doesn't afford any behaviour, various classes can still implement it, like, for example, <code>Book</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Book</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IGood</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Book(<span style="color:blue;">string</span>&nbsp;name) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;=&nbsp;name; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">string</span>&nbsp;Name&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> Other <code>IGood</code> 'implementations' looks similar, and there's a comparable class hierarchy for <code>ICommand</code>, which is another marker interface. </p> <p> The above F# code used a shared function type of <code>Good -&gt; Command list</code> as a polymorphic type for a business rule. You can <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">translate that to a C# interface</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IRule</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICommand</span>&gt;&nbsp;Handle(<span style="color:#2b91af;">IGood</span>&nbsp;good); }</pre> </p> <p> The above <code>slipForShipping</code> function becomes a class that implements the <code>IRule</code> interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">SlipForShippingRule</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IRule</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICommand</span>&gt;&nbsp;Handle(<span style="color:#2b91af;">IGood</span>&nbsp;good) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(good&nbsp;<span style="color:blue;">is</span>&nbsp;<span style="color:#2b91af;">PhysicalProduct</span>&nbsp;|| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;good&nbsp;<span style="color:blue;">is</span>&nbsp;<span style="color:#2b91af;">Book</span>&nbsp;|| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;good&nbsp;<span style="color:blue;">is</span>&nbsp;<span style="color:#2b91af;">Video</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">SlipCommand</span>(<span style="color:#a31515;">&quot;Shipping&quot;</span>,&nbsp;good)&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ICommand</span>[0]; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Instead of pattern matching on a discriminated union, the <code>Handle</code> method examines the subtype of <code>good</code> and only returns a <code>SlipCommand</code> if the <code>good</code> is either a <code>PhysicalProduct</code>, a <code>Book</code>, or a <code>Video</code>. </p> <p> The other implementations are similar, so I'm not going to show all of them, but here's one more: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">ActivateRule</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IRule</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICommand</span>&gt;&nbsp;Handle(<span style="color:#2b91af;">IGood</span>&nbsp;good) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;good&nbsp;<span style="color:blue;">as</span>&nbsp;<span style="color:#2b91af;">MembershipGood</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(m&nbsp;!=&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ActivateCommand</span>(m.Membership)&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ICommand</span>[0]; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Since 'all' members of <code>IRule</code> return <a href="http://blog.ploeh.dk/2017/10/10/strings-lists-and-sequences-as-a-monoid">collections, which form monoids over concatenation</a>, the interface itself gives rise to a monoid. This means that you can create a Composite: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">CompositeRule</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IRule</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IRule</span>[]&nbsp;rules; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;CompositeRule(<span style="color:blue;">params</span>&nbsp;<span style="color:#2b91af;">IRule</span>[]&nbsp;rules) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.rules&nbsp;=&nbsp;rules; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICommand</span>&gt;&nbsp;Handle(<span style="color:#2b91af;">IGood</span>&nbsp;good) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;commands&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">List</span>&lt;<span style="color:#2b91af;">ICommand</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;rule&nbsp;<span style="color:blue;">in</span>&nbsp;rules) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;commands.AddRange(rule.Handle(good)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;commands; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice how the implementation of <code>Handle</code> follows the <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">template for monoid accumulation</a>. It starts with the <em>identity</em>, which, for the collection concatenation monoid is the empty collection. It then loops through all the composed <code>rules</code> and updates the accumulator <code>commands</code> in each iteration. Here, I used <code>AddRange</code>, which mutates <code>commands</code> instead of returning a new value, but the result is the same. Finally, the method returns the accumulator. </p> <p> You can now compose all the business rules and use the composition as though it was a single object: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;rule&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CompositeRule</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">SlipForShippingRule</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">SlipForRoyaltyRule</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ActivateRule</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">UpgradeRule</span>()); <span style="color:blue;">var</span>&nbsp;book&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Book</span>(<span style="color:#a31515;">&quot;The&nbsp;Annotated&nbsp;Turing&quot;</span>); <span style="color:blue;">var</span>&nbsp;commands&nbsp;=&nbsp;rule.Handle(book);</pre> </p> <p> When the method returns, <code>commands</code> contains two <code>SlipCommand</code> objects - a packing slip, and a royalty slip. </p> <h3 id="e890108dc2534b97a57a843f60e5a01f"> Business rules in Haskell <a href="#e890108dc2534b97a57a843f60e5a01f" title="permalink">#</a> </h3> <p> You can also port the F# code to Haskell, which is usually easy as long as the F# is written in a 'functional style'. Since Haskell has an explicit notion of monoids, you'll be able to see how the two above solutions are monoidal. </p> <p> The data types are easy to translate to Haskell - you only have to adjust the syntax a bit: </p> <p> <pre><span style="color:blue;">data</span>&nbsp;Membership&nbsp;=&nbsp;Basic&nbsp;|&nbsp;Gold&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Show</span>,&nbsp;<span style="color:#2b91af;">Eq</span>,&nbsp;<span style="color:#2b91af;">Enum</span>,&nbsp;<span style="color:#2b91af;">Bounded</span>) <span style="color:blue;">data</span>&nbsp;Good&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;PhysicalProduct&nbsp;String &nbsp;&nbsp;|&nbsp;Book&nbsp;String &nbsp;&nbsp;|&nbsp;Video&nbsp;String &nbsp;&nbsp;|&nbsp;Membership&nbsp;Membership &nbsp;&nbsp;|&nbsp;UpgradeGood &nbsp;&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Show</span>,&nbsp;<span style="color:#2b91af;">Eq</span>) <span style="color:blue;">data</span>&nbsp;Command&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;Slip&nbsp;String&nbsp;[Good] &nbsp;&nbsp;|&nbsp;Activate&nbsp;Membership &nbsp;&nbsp;|&nbsp;Upgrade &nbsp;&nbsp;|&nbsp;PayAgent &nbsp;&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Show</span>,&nbsp;<span style="color:#2b91af;">Eq</span>)</pre> </p> <p> The business rule functions are also easy to translate: </p> <p> <pre><span style="color:#2b91af;">slipForShipping</span>&nbsp;::&nbsp;<span style="color:blue;">Good</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[<span style="color:blue;">Command</span>] slipForShipping&nbsp;pp@(PhysicalProduct&nbsp;_)&nbsp;=&nbsp;[Slip&nbsp;<span style="color:#a31515;">&quot;Shipping&quot;</span>&nbsp;[pp]] slipForShipping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b@(Book&nbsp;_)&nbsp;=&nbsp;[Slip&nbsp;<span style="color:#a31515;">&quot;Shipping&quot;</span>&nbsp;&nbsp;[b]] slipForShipping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;v@(Video&nbsp;_)&nbsp;=&nbsp;[Slip&nbsp;<span style="color:#a31515;">&quot;Shipping&quot;</span>&nbsp;&nbsp;[v]] slipForShipping&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_&nbsp;&nbsp;=&nbsp;<span style="color:blue;">[]</span> <span style="color:#2b91af;">slipForRoyalty</span>&nbsp;::&nbsp;<span style="color:blue;">Good</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[<span style="color:blue;">Command</span>] slipForRoyalty&nbsp;b@(Book&nbsp;_)&nbsp;=&nbsp;[Slip&nbsp;<span style="color:#a31515;">&quot;Royalty&quot;</span>&nbsp;[b]] slipForRoyalty&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_&nbsp;&nbsp;=&nbsp;<span style="color:blue;">[]</span> <span style="color:#2b91af;">activate</span>&nbsp;::&nbsp;<span style="color:blue;">Good</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[<span style="color:blue;">Command</span>] activate&nbsp;(Membership&nbsp;m)&nbsp;=&nbsp;[Activate&nbsp;m] activate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_&nbsp;&nbsp;=&nbsp;<span style="color:blue;">[]</span> <span style="color:#2b91af;">upgrade</span>&nbsp;::&nbsp;<span style="color:blue;">Good</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[<span style="color:blue;">Command</span>] upgrade&nbsp;(UpgradeGood)&nbsp;=&nbsp;[Upgrade] upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_&nbsp;&nbsp;=&nbsp;<span style="color:blue;">[]</span></pre> </p> <p> Notice that all four business rules share the same type: <code>Good -&gt; [Command]</code>. This is conceptually the same type as in the F# code; instead of writing <code>Command list</code>, which is the F# syntax, the Haskell syntax for a list of <code>Command</code> values is <code>[Command]</code>. </p> <p> All those functions <a href="http://blog.ploeh.dk/2017/11/06/function-monoids">are monoids because their return types form a monoid</a>, so in Haskell, you can compose them without further ado: </p> <p> <pre><span style="color:#2b91af;">handleAll</span>&nbsp;::&nbsp;<span style="color:blue;">Good</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;[<span style="color:blue;">Command</span>] handleAll&nbsp;=&nbsp;mconcat&nbsp;[slipForShipping,&nbsp;slipForRoyalty,&nbsp;activate,&nbsp;upgrade]</pre> </p> <p> <code>mconcat</code> is a built-in function that aggregates any list of monoidal values to a single value: </p> <p> <pre>mconcat :: Monoid a =&gt; [a] -&gt; a</pre> </p> <p> Since all four functions are monoids, this just works out of the box. A Composite is just a monoid. Here's an example of using <code>handleAll</code> from GHCi: </p> <p> <pre>*BusinessRules&gt; handleAll $ Book "The Annotated Turing" [Slip "Shipping" [Book "The Annotated Turing"],Slip "Royalty" [Book "The Annotated Turing"]]</pre> </p> <p> The result is as you'd come to expect. </p> <p> Notice that not only don't you have to write a <code>CompositeRule</code> class, you don't even have to write a <code>handle</code> helper function. Haskell already understands monoids, so composition happens automatically. </p> <p> If you prefer, you could even skip the <code>handle</code> function too: </p> <p> <pre>*BusinessRules&gt; mconcat [slipForShipping, slipForRoyalty, activate, upgrade] $ Book "Blindsight" [Slip "Shipping" [Book "Blindsight"],Slip "Royalty" [Book "Blindsight"]]</pre> </p> <p> (Yes, you should also read <a href="http://amzn.to/1OSKj6Z">Blindsight</a>.) </p> <p> It's not that composition as such is built into Haskell, but rather that the language is designed around a powerful ability to model abstractions, and one of the built-in abstractions just happens to be monoids. You could argue, however, that many of Haskell's fundamental abstractions are built from category theory, and one of the fundamental characteristics of a category is how morphisms compose. </p> <h3 id="2b8ab9b2722940d093de8f7b4db7868d"> Summary <a href="#2b8ab9b2722940d093de8f7b4db7868d" title="permalink">#</a> </h3> <p> Composite are monoids. This article shows an example, starting with a solution in F#. You can translate the F# code to object-oriented C# and model the composition of business rules as a Composite. You can also translate the F# code 'the other way', to the strictly functional language Haskell, and thereby demonstrate that the solution is based on a monoid. </p> <p> <em>This article is a repost of <a href="https://blog.ndcconferences.com/composite-as-a-monoid-a-business-rules-example">a guest post on the NDC blog</a>, reproduced here with kind permission.</em> </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Project Arbitraries with view patterns http://blog.ploeh.dk/2018/05/14/project-arbitraries-with-view-patterns 2018-05-14T08:07:00+00:00 Mark Seemann <div id="post"> <p> <em>Write expressive property-based test with QuickCheck and view patterns.</em> </p> <p> Recently, I was writing some <a href="https://hackage.haskell.org/package/QuickCheck/docs/Test-QuickCheck.html">QuickCheck</a>-based tests of some business logic, and since the business logic in question involved a custom domain type called <code>Reservation</code>, I had to write an <code>Arbitrary</code> instance for it. Being a dutiful <a href="https://www.haskell.org">Haskell</a> programmer, I wrapped it in a <code>newtype</code> in order to prevent warnings about orphaned instances: </p> <p> <pre><span style="color:blue;">newtype</span>&nbsp;ArbReservation&nbsp;=&nbsp;ArbReservation&nbsp;{&nbsp;getReservation&nbsp;::&nbsp;Reservation&nbsp;}&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#2b91af;">Show</span>,&nbsp;<span style="color:#2b91af;">Eq</span>) <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Arbitrary</span>&nbsp;<span style="color:blue;">ArbReservation</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;arbitrary&nbsp;=&nbsp;<span style="color:blue;">do</span> &nbsp;&nbsp;&nbsp;&nbsp;(d,&nbsp;e,&nbsp;n,&nbsp;Positive&nbsp;q,&nbsp;b)&nbsp;&lt;-&nbsp;arbitrary &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;$&nbsp;ArbReservation&nbsp;$&nbsp;Reservation&nbsp;d&nbsp;e&nbsp;n&nbsp;q&nbsp;b </pre> </p> <p> This is all fine as long as you just need one <code>Reservation</code> in a test, because in that case, you can simply pattern-match it out of <code>ArbReservation</code>: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;tryAccept&nbsp;reservation&nbsp;in&nbsp;the&nbsp;past&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;(Positive&nbsp;capacity)&nbsp;(ArbReservation&nbsp;reservation) &nbsp;&nbsp;-&gt; &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;stub&nbsp;(IsReservationInFuture&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;False &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(ReadReservations&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;<span style="color:blue;">[]</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(Create&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;actual&nbsp;=&nbsp;iter&nbsp;stub&nbsp;$&nbsp;runMaybeT&nbsp;$&nbsp;tryAccept&nbsp;capacity&nbsp;reservation &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;<span style="color:blue;">in</span>&nbsp;&nbsp;isNothing&nbsp;actual </pre> </p> <p> Here, <code>reservation</code> is a <code>Reservation</code> value because it was pattern-matched out of <code>ArbReservation reservation</code>. That's just like <code>capacity</code> is an <code>Int</code>, because it was pattern-matched out of <code>Positive capacity</code>. </p> <p> Incidentally, in the spirit of <a href="http://blog.ploeh.dk/2018/05/07/inlined-hunit-test-lists">the previous article</a>, I'm here using in-lined properties implemented as lambda expressions. The lambda expressions use non-idiomatic formatting in order to make the tests more readable (and to prevent horizontal scrolling), but the gist of the matter is that the entire expression has the type <code>Positive Int -&gt; ArbReservation -&gt; Bool</code>. This is a <code>Testable</code> property because all the input types have <code>Arbitrary</code> instances. </p> <h3 id="e8b8ac40cade45db95315ebb8fa19ebc"> Discommodity creeps in <a href="#e8b8ac40cade45db95315ebb8fa19ebc" title="permalink">#</a> </h3> <p> That's fine for that test case, but for the next, I needed not only a single <code>Reservation</code> value, but also a list of <code>Reservation</code> values. Again, with QuickCheck, you can't write a property with a type like <code>Positive Int -&gt; [Reservation] -&gt; ArbReservation -&gt; Bool</code>, because there's no <code>Arbitrary</code> instance for <code>[Reservation]</code>. Instead, you'll need a property with the type <code>Positive Int -&gt; [ArbReservation] -&gt; ArbReservation -&gt; Bool</code>. </p> <p> One way to do that is to write the property like this: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;tryAccept&nbsp;reservation&nbsp;when&nbsp;capacity&nbsp;is&nbsp;insufficient&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;(Positive&nbsp;i) &nbsp;&nbsp;reservations &nbsp;&nbsp;(ArbReservation&nbsp;reservation) &nbsp;&nbsp;-&gt; &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;stub&nbsp;(IsReservationInFuture&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;True &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(ReadReservations&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;$&nbsp;getReservation&nbsp;&lt;$&gt;&nbsp;reservations &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(Create&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reservedSeats&nbsp;=&nbsp;<span style="color:blue;">sum</span>&nbsp;$&nbsp;reservationQuantity&nbsp;&lt;$&gt;&nbsp;getReservation&nbsp;&lt;$&gt;&nbsp;reservations &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capacity&nbsp;=&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;-&nbsp;i &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;actual&nbsp;=&nbsp;iter&nbsp;stub&nbsp;$&nbsp;runMaybeT&nbsp;$&nbsp;tryAccept&nbsp;capacity&nbsp;reservation &nbsp;&nbsp;<span style="color:blue;">in</span>&nbsp;&nbsp;isNothing&nbsp;actual </pre> </p> <p> Here, <code>reservations</code> has type type <code>[ArbReservation]</code>, so every time the test needs to operate on the values, it first has to pull the <code>Reservation</code> values out of it using <code>getReservation &lt;$&gt; reservations</code>. That seems unnecessarily verbose and repetitive, so it'd be nice if a better option was available. </p> <h3 id="49c9bc081e7b41598fa7bb9052b747d0"> View pattern <a href="#49c9bc081e7b41598fa7bb9052b747d0" title="permalink">#</a> </h3> <p> Had I been writing <a href="http://fsharp.org">F#</a> code, I'd immediately be reaching for an <a href="https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/active-patterns">active pattern</a>, but this is Haskell. If there's one thing, though, I've learned about Haskell so far, it's that, if F# can do something, there's a very good chance Haskell can do it too - only, it may be called something else. </p> <p> With a vague sense that I'd seen something similar in some Haskell code somewhere, I went looking, and about fifteen minutes later I'd found what I was looking for: a little language extension called <em>view patterns</em>. Just add the language extension to the top of the file where you want to use it: </p> <p> <pre>{-#&nbsp;<span style="color:gray;">LANGUAGE</span>&nbsp;ViewPatterns&nbsp;#-}</pre> </p> <p> You can now change the property to pattern-match <code>reservations</code> out of a function call, so to speak: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;tryAccept&nbsp;reservation&nbsp;when&nbsp;capacity&nbsp;is&nbsp;insufficient&quot;</span>&nbsp;$&nbsp;\ &nbsp;&nbsp;(Positive&nbsp;i) &nbsp;&nbsp;(<span style="color:blue;">fmap</span>&nbsp;getReservation&nbsp;-&gt;&nbsp;reservations) &nbsp;&nbsp;(ArbReservation&nbsp;reservation) &nbsp;&nbsp;-&gt; &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;stub&nbsp;(IsReservationInFuture&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;True &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(ReadReservations&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;reservations &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;stub&nbsp;(Create&nbsp;_&nbsp;next)&nbsp;=&nbsp;next&nbsp;0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reservedSeats&nbsp;=&nbsp;<span style="color:blue;">sum</span>&nbsp;$&nbsp;reservationQuantity&nbsp;&lt;$&gt;&nbsp;reservations &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capacity&nbsp;=&nbsp;reservedSeats&nbsp;+&nbsp;reservationQuantity&nbsp;reservation&nbsp;-&nbsp;i &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;actual&nbsp;=&nbsp;iter&nbsp;stub&nbsp;$&nbsp;runMaybeT&nbsp;$&nbsp;tryAccept&nbsp;capacity&nbsp;reservation &nbsp;&nbsp;<span style="color:blue;">in</span>&nbsp;&nbsp;isNothing&nbsp;actual </pre> </p> <p> The function <code>getReservation</code> has the type <code>ArbReservation -&gt; Reservation</code>, so <code>fmap getReservation</code> is a partially applied function with the type <code>[ArbReservation] -&gt; [Reservation]</code>. In order to be able to call the overall lambda expression, the caller must supply an <code>[ArbReservation]</code> value to the view pattern, which means that the type of that argument must be <code>[ArbReservation]</code>. The view pattern then immediately unpacks the result of the function and gives you <code>reservations</code>, which is the return value of calling <code>fmap getReservation</code> with the input value(s). Thus, <code>reservations</code> has the type <code>[Reservation]</code>. </p> <p> The type of the entire property is now <code>Positive Int -&gt; [ArbReservation] -&gt; ArbReservation -&gt; Bool</code>. </p> <p> This removes some noise from the body of the property, so I find that this is a useful trick in this particular situation. </p> <h3 id="02cafa3f94eb4fe19e1ad19f7448d258"> Summary <a href="#02cafa3f94eb4fe19e1ad19f7448d258" title="permalink">#</a> </h3> <p> You can use the <em>view patterns</em> GHC language extension when you need to write a function that takes an argument of a particular type, but you never care about the original input, but instead immediately wish to project it to a different value. </p> <p> I haven't had much use for it before, but it seems to be useful in the context of QuickCheck properties. </p> </div> <div id="comments"> <hr> <h2 id="comments-header">Comments</h2> <div class="comment" id="81bcbcc0ff9142018fce53c744264ee2"> <div class="comment-author"><a href="https://benjamin.pizza/">Benjamin Hodgson</a></div> <div class="comment-content"> <p> I've seen folks wrap up the view pattern in a <a href="https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html#pattern-synonyms">pattern synonym</a>: </p> <p> <pre><code> pattern ArbReservations :: [Reservation] -> [ArbReservation] pattern ArbReservations rs <- (coerce -> rs) where ArbReservations rs = coerce rs foo :: [ArbReservation] -> IO () foo (ArbReservations rs) = traverse print rs </code></pre> </p> <p> (<code>coerce</code> is usually more efficient than <code>fmap</code>.) </p> <p> OTOH I don't think orphan instances of <code>Arbitrary</code> are very harmful. It's unlikely that they'll get accidentally imported or overlap, because <code>Arbitrary</code> is purely used for testing. So in this specific case I'd probably just stick with an orphan instance and turn off the warning for that file. </p> </div> <div class="comment-date">2018-05-26 10:55 UTC</div> </div> <div class="comment" id="85761f5529fd4806a4e4202ed4b319c5"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Benjamin, thank you for the <em>pattern synonyms</em> tip; I'll have to try that next time. </p> <p> Regarding orphaned instances, your point is something I've been considering myself, but I'm still at the point of my Haskell journey where I'm trying to understand the subtleties of the ecosystem, so I wasn't sure whether or not it'd be a good idea to allow orphaned <code>Arbitrary</code> instances. </p> <p> When you suggest turning off the warning for a file, do you mean adding an <code>{-# OPTIONS_GHC -fno-warn-orphans #-}</code> pragma, or did you have some other method in mind? </p> </div> <div class="comment-date">2018-05-27 7:54 UTC</div> </div> <div class="comment" id="dc078779dfd04a8a8411322269516ae0"> <div class="comment-author"><a href="https://benjamin.pizza/">Benjamin Hodgson</a></div> <div class="comment-content"> <p> Yep I meant <code>OPTIONS_GHC</code>. </p> <p> Orphan instances are problematic because of the possibility that they'll be imported unintentionally or overlap with another orphan instance. If you import two modules which both define orphan instances for the same type then there's no way for GHC to know which one you meant when you attempt to use them. Since instances aren't named you can't even specify it manually, and the compiler can't check for this scenario ahead of time because of separate compilation. (Non-orphans are guaranteed unique by the fact that you can't import the parent type/class without importing the instance.) </p> <p> In the case of <code>Arbitrary</code> these problems typically don't apply because the class is intended to be used for testing. <code>Arbitrary</code> instances are usually internal to your test project and not exported, so the potential for damage is small. </p> </div> <div class="comment-date">2018-05-27 14:08 UTC</div> </div> <div class="comment" id="295d2df911f1465eb14118085f47b3b1"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Benjamin, thank you for elaborating. That all makes sense to me. </p> </div> <div class="comment-date">2018-05-27 16:06 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Inlined HUnit test lists http://blog.ploeh.dk/2018/05/07/inlined-hunit-test-lists 2018-05-07T12:41:00+00:00 Mark Seemann <div id="post"> <p> <em>An alternative way to organise tests lists with HUnit.</em> </p> <p> In the <a href="http://blog.ploeh.dk/2018/04/30/parametrised-unit-tests-in-haskell">previous article</a> you saw how to write <a href="http://xunitpatterns.com/Parameterized%20Test.html">parametrised test</a> with <a href="https://hackage.haskell.org/package/HUnit">HUnit</a>. While the tests themselves were elegant and readable (in my opinion), the composition of test lists left something to be desired. This article offers a different way to organise test lists. </p> <h3 id="d7a929c8507641759a43055ee6c4659f"> Duplication <a href="#d7a929c8507641759a43055ee6c4659f" title="permalink">#</a> </h3> <p> The main problem is one of duplication. Consider the <code>main</code> function for the test library, as defined in the previous article: </p> <p> <pre>main&nbsp;<span style="color:#666666;">=</span>&nbsp;defaultMain&nbsp;<span style="color:#666666;">$</span>&nbsp;hUnitTestToTests&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">TestList</span>&nbsp;[ &nbsp;&nbsp;<span style="color:#a31515;">&quot;adjustToBusinessHours&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;adjustToBusinessHoursReturnsCorrectResult, &nbsp;&nbsp;<span style="color:#a31515;">&quot;adjustToDutchBankDay&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;adjustToDutchBankDayReturnsCorrectResult, &nbsp;&nbsp;<span style="color:#a31515;">&quot;Composed&nbsp;adjust&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;composedAdjustReturnsCorrectResult&nbsp;]</pre> </p> <p> It annoys me that I have a function with a (somewhat) descriptive name, like <code>adjustToBusinessHoursReturnsCorrectResult</code>, but then I also have to give the test a label - in this case <code>"adjustToBusinessHours returns correct result"</code>. Not only is this duplication, but it also adds an extra maintenance overhead, because if I decide to rename the test, should I also rename the label? </p> <p> Why do you even need the label? When you run the test, that label is printed during the test run, so that you can see what happens: </p> <p> <pre>$ stack test --color never --ta "--plain" ZonedTimeAdjustment-0.1.0.0: test (suite: ZonedTimeAdjustment-test, args: --plain) :adjustToDutchBankDay returns correct result: : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] :adjustToBusinessHours returns correct result: : [OK] : [OK] : [OK] :Composed adjust returns correct result: : [OK] : [OK] : [OK] : [OK] : [OK] Test Cases Total Passed 20 20 Failed 0 0 Total 20 20</pre> </p> <p> I considered it redundant to give each test case in the parametrised tests their own labels, but I could have done that too, if I'd wanted to. </p> <p> What happens if you remove the labels? </p> <p> <pre>main&nbsp;<span style="color:#666666;">=</span>&nbsp;defaultMain&nbsp;<span style="color:#666666;">$</span>&nbsp;hUnitTestToTests&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">TestList</span>&nbsp;<span style="color:#666666;">$</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;adjustToBusinessHoursReturnsCorrectResult &nbsp;&nbsp;<span style="color:#666666;">++</span>&nbsp;&nbsp;adjustToDutchBankDayReturnsCorrectResult &nbsp;&nbsp;<span style="color:#666666;">++</span>&nbsp;&nbsp;composedAdjustReturnsCorrectResult</pre> </p> <p> That compiles, but produces output like this: </p> <p> <pre>$ stack test --color never --ta "--plain" ZonedTimeAdjustment-0.1.0.0: test (suite: ZonedTimeAdjustment-test, args: --plain) : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] : [OK] Test Cases Total Passed 20 20 Failed 0 0 Total 20 20</pre> </p> <p> If you don't care about the labels, then that's a fine solution. On the other hand, if you <em>do</em> care about the labels, then a different approach is warranted. </p> <h3 id="9801f758146a43939d1347b64ab092f4"> Inlined test lists <a href="#9801f758146a43939d1347b64ab092f4" title="permalink">#</a> </h3> <p> Looking at an expression like <code>"Composed adjust returns correct result" ~: composedAdjustReturnsCorrectResult</code>, I find <code>"Composed adjust returns correct result"</code> more readable than <code>composedAdjustReturnsCorrectResult</code>, so if I want to reduce duplication, I want to go after a solution that names a test with a label, instead of a solution that names a test with a function name. </p> <p> What is <code>composedAdjustReturnsCorrectResult</code>? It's just the name of a <a href="https://en.wikipedia.org/wiki/Pure_function">pure function</a> (because its type is <code>[Test]</code>). Since it's <a href="https://en.wikipedia.org/wiki/Referential_transparency">referentially transparent</a>, it means that in the test list in <code>main</code>, I can replace the function with its body! I can do this with all three functions, although, in order to keep things simplified, I'm only going to show you two of them: </p> <p> <pre><span style="color:#600277;">main</span>&nbsp;::&nbsp;IO&nbsp;() main&nbsp;<span style="color:#666666;">=</span>&nbsp;defaultMain&nbsp;<span style="color:#666666;">$</span>&nbsp;hUnitTestToTests&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">TestList</span>&nbsp;[ &nbsp;&nbsp;<span style="color:#a31515;">&quot;adjustToBusinessHours&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;<span style="color:#af00db;">do</span> &nbsp;&nbsp;&nbsp;&nbsp;(dt,&nbsp;expected)&nbsp;<span style="color:#666666;">&lt;-</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">6</span>,&nbsp;<span style="color:#09885a;">59</span>,&nbsp;&nbsp;<span style="color:#09885a;">4</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;<span style="color:#09885a;">42</span>,&nbsp;<span style="color:#09885a;">41</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;<span style="color:#09885a;">42</span>,&nbsp;<span style="color:#09885a;">41</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">19</span>,&nbsp;<span style="color:#09885a;">1</span>,&nbsp;<span style="color:#09885a;">32</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">3</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;] &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;<span style="color:#666666;">=</span>&nbsp;adjustToBusinessHours&nbsp;dt &nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;expected&nbsp;<span style="color:#666666;">~=?</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;actual &nbsp;&nbsp;, &nbsp;&nbsp;<span style="color:#a31515;">&quot;Composed&nbsp;adjust&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;<span style="color:#af00db;">do</span> &nbsp;&nbsp;&nbsp;&nbsp;(dt,&nbsp;expected)&nbsp;<span style="color:#666666;">&lt;-</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">1</span>,&nbsp;<span style="color:#09885a;">31</span>)&nbsp;(&nbsp;<span style="color:#09885a;">7</span>,&nbsp;<span style="color:#09885a;">45</span>,&nbsp;<span style="color:#09885a;">55</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">2</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">28</span>)&nbsp;(&nbsp;<span style="color:#09885a;">7</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;&nbsp;<span style="color:#09885a;">6</span>)&nbsp;(<span style="color:#09885a;">10</span>,&nbsp;&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">1</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">6</span>)&nbsp;(&nbsp;<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;&nbsp;<span style="color:#09885a;">9</span>)&nbsp;(&nbsp;<span style="color:#09885a;">4</span>,&nbsp;<span style="color:#09885a;">20</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">0</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">9</span>)&nbsp;(&nbsp;<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">12</span>)&nbsp;(<span style="color:#09885a;">16</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">11</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">0</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;<span style="color:#09885a;">10</span>)&nbsp;(<span style="color:#09885a;">16</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">11</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;<span style="color:#09885a;">14</span>)&nbsp;(<span style="color:#09885a;">13</span>,&nbsp;<span style="color:#09885a;">48</span>,&nbsp;<span style="color:#09885a;">29</span>)&nbsp;(<span style="color:#666666;">-</span><span style="color:#09885a;">1</span>),&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">4</span>,&nbsp;<span style="color:#09885a;">13</span>)&nbsp;(<span style="color:#09885a;">14</span>,&nbsp;<span style="color:#09885a;">48</span>,&nbsp;<span style="color:#09885a;">29</span>)&nbsp;<span style="color:#09885a;">0</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;] &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;adjustments&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reverse&nbsp;[adjustToNextMonth,&nbsp;adjustToBusinessHours,&nbsp;adjustToDutchBankDay,&nbsp;adjustToUtc] &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;adjust&nbsp;<span style="color:#666666;">=</span>&nbsp;appEndo&nbsp;<span style="color:#666666;">$</span>&nbsp;mconcat&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">Endo</span>&nbsp;<span style="color:#666666;">&lt;$&gt;</span>&nbsp;adjustments &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;<span style="color:#666666;">=</span>&nbsp;adjust&nbsp;dt &nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;expected&nbsp;<span style="color:#666666;">~=?</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;actual &nbsp;&nbsp;]</pre> </p> <p> In order to keep the code listing to a reasonable length, I didn't include the third test <code>"adjustToDutchBankDay returns correct result"</code>, but it works in exactly the same way. </p> <p> This is a list with two values. You can see that the values are separated by a <code>,</code>, just like list elements normally are. What's unusual, however, is that each element in the list is defined with a multi-line <code>do</code> block. </p> <p> In C# and F#, I'm used to being able to just write new test functions, and they're automatically picked up by convention and executed by the test runner. I wouldn't be at all surprised if there was a mechanism using Template Haskell that enables something similar, but I find that there's something appealing about treating tests as first-class values all the way. </p> <p> By inlining the tests, I can retain my F# and C# workflow. Just add a new test within the list, and it's automatically picked up by the <code>main</code> function. Not only that, but it's no longer possible to write a test that compiles, but is never executed by the test runner because it has the wrong type. This occasionally happens to me in F#, but with the technique outlined here, if I accidentally give the test the wrong type, it's not going to compile. </p> <h3 id="c9303b8865dc42b0a60bac2b9471fc13"> Conclusion <a href="#c9303b8865dc42b0a60bac2b9471fc13" title="permalink">#</a> </h3> <p> Since HUnit tests are first-class values, you can define them inlined in test lists. For larger code bases, I'd assume that you'd want to spread your unit tests across multiple modules. In that case, I suppose that you could have each test module export a <code>[Test]</code> value. In the test library's <code>main</code> function, you'd need to manually concatenate all the exported test lists together, so a small maintenance burden remains. When you add a new test module, you'd have to add its exported tests to <code>main</code>. </p> <p> I wouldn't be surprised, however, if a clever reader could point out to me how to avoid that as well. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Parametrised unit tests in Haskell http://blog.ploeh.dk/2018/04/30/parametrised-unit-tests-in-haskell 2018-04-30T07:04:00+00:00 Mark Seemann <div id="post"> <p> <em>Here's a way to write parametrised unit tests in Haskell.</em> </p> <p> Sometimes you'd like to execute the same (unit) test for a number of test cases. The only thing that varies is the input values, and the expected outcome. The actual test code is the same for all test cases. Among object-oriented programmers, this is known as a <a href="http://xunitpatterns.com/Parameterized%20Test.html">parametrised test</a>. </p> <p> When I recently searched the web for how to do parametrised tests in <a href="https://www.haskell.org">Haskell</a>, I could only find articles that talked about property-based testing, mostly with <a href="https://hackage.haskell.org/package/QuickCheck">QuickCheck</a>. I normally prefer property-based testing, but sometimes, I'd rather like to run a test with some deterministic test cases that are visible and readable in the code itself. </p> <p> Here's one way I found that I could do that in Haskell. </p> <h3 id="1717430a5a3048629121ab7831c1339d"> Testing date and time adjustments in C# <a href="#1717430a5a3048629121ab7831c1339d" title="permalink">#</a> </h3> <p> In <a href="http://blog.ploeh.dk/2017/11/13/endomorphism-monoid">an earlier article</a>, I discussed how to model date and time adjustments as a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. The example code was written in C#, and I used a few tests to demonstrate that the composition of adjustments work as intended: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-01-31T07:45:55+2&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-02-28T07:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-06T10:03:02+1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-03-06T09:03:02Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-09T04:20:00Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-09T09:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-12T16:02:11Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-10T16:02:11Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-03-14T13:48:29-1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-04-13T14:48:29Z&quot;</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AccumulatedAdjustReturnsCorrectResult( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;dtS, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;expectedS) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;dt&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>.Parse(dtS); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffsetAdjustment</span>.Accumulate( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NextMonthAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BusinessHoursAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DutchBankDayAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">UtcAdjustment</span>()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Adjust(dt); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#2b91af;">DateTimeOffset</span>.Parse(expectedS),&nbsp;actual); }</pre> </p> <p> The above parametrised test uses <a href="https://xunit.github.io">xUnit.net</a> (particularly its <code>Theory</code> feature) to execute the same test code for five test cases. Here's another example: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-10-02T06:59:04Z&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-10-02T09:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-10-02T09:42:41Z&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-10-02T09:42:41Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-10-02T19:01:32Z&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-10-03T09:00:00Z&quot;</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AdjustReturnsCorrectResult(<span style="color:blue;">string</span>&nbsp;dts,&nbsp;<span style="color:blue;">string</span>&nbsp;expectedS) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;dt&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>.Parse(dts); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BusinessHoursAdjustment</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Adjust(dt); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#2b91af;">DateTimeOffset</span>.Parse(expectedS),&nbsp;actual); }</pre> </p> <p> This one covers the three code paths through <code>BusinessHoursAdjustment.Adjust</code>. </p> <p> These tests are similar, so they share some good and bad qualities. </p> <p> On the positive side, I like how <em>readable</em> such tests are. The test code is only a few lines of code, and the test cases (input, and expected output) are in close proximity to the code. Unless you're on a phone with a small screen, you can easily see all of it at once. </p> <p> For a problem like this, I felt that I preferred examples rather than using property-based testing. If the date and time is this, then the adjusted result should be that, and so on. When we <em>read</em> code, we tend to prefer examples. Good documentation often contains examples, and for those of us who consider tests documentation, including examples in tests should advance that cause. </p> <p> On the negative side, tests like these still contain noise. Most of it relates to the problem that xUnit.net tests aren't first-class values. These tests actually ought to take a <code>DateTimeOffset</code> value as input, and compare it to another, expected <code>DateTimeOffset</code> value. Unfortunately, <code>DateTimeOffset</code> values aren't constants, so you can't use them in attributes, like the <code>[InlineData]</code> attribute. </p> <p> There are other workarounds than the one I ultimately chose, but none that are as simple (that I'm aware of). Strings are constants, so you can put formatted date and time strings in the <code>[InlineData]</code> attributes, but the cost of doing this is two calls to <code>DateTimeOffset.Parse</code>. Perhaps this isn't a big price, you think, but it does make me wish for something prettier. </p> <h3 id="df8f3de4ba284893b551b470a6e7c579"> Comparing date and time <a href="#df8f3de4ba284893b551b470a6e7c579" title="permalink">#</a> </h3> <p> In order to port the above tests to Haskell, I used <a href="http://haskellstack.org">Stack</a> to create a new project with <a href="https://hackage.haskell.org/package/HUnit">HUnit</a> as the unit testing library. </p> <p> The Haskell equivalent to <code>DateTimeOffset</code> is called <code>ZonedTime</code>. One problem with <code>ZonedTime</code> values is that you can't readily compare them; the type isn't an <code>Eq</code> instance. There are good reasons for that, but for the purposes of unit testing, I wanted to be able to compare them, so I defined this helper data type: </p> <p> <pre><span style="color:blue;">newtype</span>&nbsp;<span style="color:#dd0000;">ZonedTimeEq</span>&nbsp;<span style="color:#666666;">=</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;<span style="color:#dd0000;">ZonedTime</span>&nbsp;<span style="color:blue;">deriving</span>&nbsp;(<span style="color:#a31515;">Show</span>) <span style="color:blue;">instance</span>&nbsp;<span style="color:blue;">Eq</span>&nbsp;<span style="color:blue;">ZonedTimeEq</span>&nbsp;<span style="color:blue;">where</span> &nbsp;&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;(<span style="color:#dd0000;">ZonedTime</span>&nbsp;lt1&nbsp;tz1)&nbsp;<span style="color:#666666;">==</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;(<span style="color:#dd0000;">ZonedTime</span>&nbsp;lt2&nbsp;tz2)&nbsp;<span style="color:#666666;">=</span>&nbsp;lt1&nbsp;<span style="color:#666666;">==</span>&nbsp;lt2&nbsp;<span style="color:#666666;">&amp;&amp;</span>&nbsp;tz1&nbsp;<span style="color:#666666;">==</span>&nbsp;tz2</pre> </p> <p> This enables me to compare two <code>ZonedTimeEq</code> values, which are only considered equal if they represent the same date, the same time, and the same time zone. </p> <h3 id="57e07c4d36a644889271d392581ae0f3"> Test Utility <a href="#57e07c4d36a644889271d392581ae0f3" title="permalink">#</a> </h3> <p> I also added a little function for creating <code>ZonedTime</code> values: </p> <p> <pre>zt&nbsp;(y,&nbsp;mth,&nbsp;d)&nbsp;(h,&nbsp;m,&nbsp;s)&nbsp;tz&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;<span style="color:#dd0000;">ZonedTime</span>&nbsp;(<span style="color:#dd0000;">LocalTime</span>&nbsp;(fromGregorian&nbsp;y&nbsp;mth&nbsp;d)&nbsp;(<span style="color:#dd0000;">TimeOfDay</span>&nbsp;h&nbsp;m&nbsp;s))&nbsp;(hoursToTimeZone&nbsp;tz)</pre> </p> <p> The motivation is simply that, as you can tell, creating a <code>ZonedTime</code> value requires a verbose expression. Clearly, the <code>ZonedTime</code> API is flexible, but in order to define some test cases, I found it advantageous to trade readability for flexibility. The <code>zt</code> function enables me to compactly define some <code>ZonedTime</code> values for my test cases. </p> <h3 id="941af2b4f00f4fa7b0683f1590879e61"> Testing business hours in Haskell <a href="#941af2b4f00f4fa7b0683f1590879e61" title="permalink">#</a> </h3> <p> In HUnit, a test is either a <code>Test</code>, a list of <code>Test</code> values, or an impure assertion. For a parametrised test, a <code>[Test]</code> sounded promising. At the beginning, I struggled with finding a readable way to express the tests. I wanted to be able to start with a list of test cases (inputs and expected outputs), and then <code>fmap</code> them to an executable test. At first, the readability goal seemed elusive, until I realised that I can also use <code>do</code> notation with lists (since they're monads): </p> <p> <pre><span style="color:#600277;">adjustToBusinessHoursReturnsCorrectResult</span>&nbsp;::&nbsp;[<span style="color:blue;">Test</span>] adjustToBusinessHoursReturnsCorrectResult&nbsp;<span style="color:#666666;">=</span>&nbsp;<span style="color:#af00db;">do</span> &nbsp;&nbsp;(dt,&nbsp;expected)&nbsp;<span style="color:#666666;">&lt;-</span> &nbsp;&nbsp;&nbsp;&nbsp;[ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">6</span>,&nbsp;<span style="color:#09885a;">59</span>,&nbsp;&nbsp;<span style="color:#09885a;">4</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;<span style="color:#09885a;">42</span>,&nbsp;<span style="color:#09885a;">41</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;<span style="color:#09885a;">42</span>,&nbsp;<span style="color:#09885a;">41</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">2</span>)&nbsp;(<span style="color:#09885a;">19</span>,&nbsp;<span style="color:#09885a;">1</span>,&nbsp;<span style="color:#09885a;">32</span>)&nbsp;<span style="color:#09885a;">0</span>,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">10</span>,&nbsp;<span style="color:#09885a;">3</span>)&nbsp;(<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>) &nbsp;&nbsp;&nbsp;&nbsp;] &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;<span style="color:#666666;">=</span>&nbsp;adjustToBusinessHours&nbsp;dt &nbsp;&nbsp;return&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;expected&nbsp;<span style="color:#666666;">~=?</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;actual</pre> </p> <p> This is the same test as the above C# test named <code>AdjustReturnsCorrectResult</code>, and it's about the same size as well. Since the test is written using <code>do</code> notation, you can take a list of test cases and operate on each test case at a time. Although the test creates a list of tuples, the <code>&lt;-</code> arrow pulls each <code>(ZonedTime, ZonedTime)</code> tuple out of the list and binds it to <code>(dt, expected)</code>. </p> <p> This test literally consists of only three expressions, so according to my normal <a href="http://blog.ploeh.dk/2013/06/24/a-heuristic-for-formatting-code-according-to-the-aaa-pattern">heuristic for test formatting</a>, I don't even need white space to indicate the three phases of the <a href="http://wiki.c2.com/?ArrangeActAssert">AAA pattern</a>. The first expression sets up the test case <code>(dt, expected)</code>. </p> <p> The next expression exercises the System Under Test - in this case the <code>adjustToBusinessHours</code> function. That's simply a function call. </p> <p> The third expression verifies the result. It uses HUnit's <code>~=?</code> operator to compare the expected and the actual values. Since <code>ZonedTime</code> isn't an <code>Eq</code> instance, both values are converted to <code>ZonedTimeEq</code> values. The <code>~=?</code> operator returns a <code>Test</code> value, and since the entire test takes place inside a <code>do</code> block, you must <code>return</code> it. Since this particular <code>do</code> block takes place inside the list monad, the type of <code>adjustToBusinessHoursReturnsCorrectResult</code> is <code>[Test]</code>. I added the type annotation for the benefit of you, dear reader, but technically, it's not required. </p> <h3 id="45bb86711997438386258c9ddc5d94dc"> Testing the composed function <a href="#45bb86711997438386258c9ddc5d94dc" title="permalink">#</a> </h3> <p> Translating the <code>AccumulatedAdjustReturnsCorrectResult</code> C# test to Haskell follows the same recipe: </p> <p> <pre><span style="color:#600277;">composedAdjustReturnsCorrectResult</span>&nbsp;::&nbsp;[<span style="color:blue;">Test</span>] composedAdjustReturnsCorrectResult&nbsp;<span style="color:#666666;">=</span>&nbsp;<span style="color:#af00db;">do</span> &nbsp;&nbsp;(dt,&nbsp;expected)&nbsp;<span style="color:#666666;">&lt;-</span> &nbsp;&nbsp;&nbsp;&nbsp;[ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">1</span>,&nbsp;<span style="color:#09885a;">31</span>)&nbsp;(&nbsp;<span style="color:#09885a;">7</span>,&nbsp;<span style="color:#09885a;">45</span>,&nbsp;<span style="color:#09885a;">55</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">2</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">28</span>)&nbsp;(&nbsp;<span style="color:#09885a;">7</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;&nbsp;<span style="color:#09885a;">6</span>)&nbsp;(<span style="color:#09885a;">10</span>,&nbsp;&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">1</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">6</span>)&nbsp;(&nbsp;<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;&nbsp;<span style="color:#09885a;">9</span>)&nbsp;(&nbsp;<span style="color:#09885a;">4</span>,&nbsp;<span style="color:#09885a;">20</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">0</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;&nbsp;<span style="color:#09885a;">9</span>)&nbsp;(&nbsp;<span style="color:#09885a;">9</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>,&nbsp;&nbsp;<span style="color:#09885a;">0</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">12</span>)&nbsp;(<span style="color:#09885a;">16</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">11</span>)&nbsp;&nbsp;&nbsp;<span style="color:#09885a;">0</span>&nbsp;,&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;<span style="color:#09885a;">10</span>)&nbsp;(<span style="color:#09885a;">16</span>,&nbsp;&nbsp;<span style="color:#09885a;">2</span>,&nbsp;<span style="color:#09885a;">11</span>)&nbsp;<span style="color:#09885a;">0</span>), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">3</span>,&nbsp;<span style="color:#09885a;">14</span>)&nbsp;(<span style="color:#09885a;">13</span>,&nbsp;<span style="color:#09885a;">48</span>,&nbsp;<span style="color:#09885a;">29</span>)&nbsp;(<span style="color:#666666;">-</span><span style="color:#09885a;">1</span>),&nbsp;zt&nbsp;(<span style="color:#09885a;">2017</span>,&nbsp;<span style="color:#09885a;">4</span>,&nbsp;<span style="color:#09885a;">13</span>)&nbsp;(<span style="color:#09885a;">14</span>,&nbsp;<span style="color:#09885a;">48</span>,&nbsp;<span style="color:#09885a;">29</span>)&nbsp;<span style="color:#09885a;">0</span>) &nbsp;&nbsp;&nbsp;&nbsp;] &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;adjustments&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reverse&nbsp;[adjustToNextMonth,&nbsp;adjustToBusinessHours,&nbsp;adjustToDutchBankDay,&nbsp;adjustToUtc] &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;adjust&nbsp;<span style="color:#666666;">=</span>&nbsp;appEndo&nbsp;<span style="color:#666666;">$</span>&nbsp;mconcat&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">Endo</span>&nbsp;<span style="color:#666666;">&lt;$&gt;</span>&nbsp;adjustments &nbsp;&nbsp;<span style="color:blue;">let</span>&nbsp;actual&nbsp;<span style="color:#666666;">=</span>&nbsp;adjust&nbsp;dt &nbsp;&nbsp;return&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;expected&nbsp;<span style="color:#666666;">~=?</span>&nbsp;<span style="color:#dd0000;">ZT</span>&nbsp;actual</pre> </p> <p> The only notable difference is that this unit test consists of five expressions, so according to my formatting heuristic, I inserted some blank lines in order to make it easier to distinguish the three AAA phases from each other. </p> <h3 id="fb38a830884b4a1ba15b29e0b5dffbfb"> Running tests <a href="#fb38a830884b4a1ba15b29e0b5dffbfb" title="permalink">#</a> </h3> <p> I also wrote a third test called <code>adjustToDutchBankDayReturnsCorrectResult</code>, but that one is so similar to the two you've already seen that I see no point showing it here. In order to run all three tests, I define the tests' <code>main</code> function as such: </p> <p> <pre>main&nbsp;<span style="color:#666666;">=</span>&nbsp;defaultMain&nbsp;<span style="color:#666666;">$</span>&nbsp;hUnitTestToTests&nbsp;<span style="color:#666666;">$</span>&nbsp;<span style="color:#dd0000;">TestList</span>&nbsp;[ &nbsp;&nbsp;<span style="color:#a31515;">&quot;adjustToBusinessHours&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;adjustToBusinessHoursReturnsCorrectResult, &nbsp;&nbsp;<span style="color:#a31515;">&quot;adjustToDutchBankDay&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;adjustToDutchBankDayReturnsCorrectResult, &nbsp;&nbsp;<span style="color:#a31515;">&quot;Composed&nbsp;adjust&nbsp;returns&nbsp;correct&nbsp;result&quot;</span>&nbsp;<span style="color:#666666;">~:</span>&nbsp;composedAdjustReturnsCorrectResult&nbsp;]</pre> </p> <p> This uses <code>defaultMain</code> from <a href="https://hackage.haskell.org/package/test-framework">test-framework</a>, and <code>hUnitTestToTests</code> from <a href="https://hackage.haskell.org/package/test-framework-hunit">test-framework-hunit</a>. </p> <p> I'm not happy about the duplication of text and test names, and the maintenance burden implied by having to explicitly add every test function to the test list. It's too easy to forget to add a test after you've written it. In the next article, I'll demonstrate an alternative way to compose the tests so that duplication is reduced. </p> <h3 id="fd998b62c43942c7901f496b1e4205e0"> Conclusion <a href="#fd998b62c43942c7901f496b1e4205e0" title="permalink">#</a> </h3> <p> Since HUnit tests are first-class values, you can manipulate and compose them just like any other value. That includes passing them around in lists and binding them with <code>do</code> notation. Once you figure out how to write parametrised tests with HUnit, it's easy, readable, and elegant. </p> <p> The overall configuration of the test runner, however, leaves a bit to be desired, so that's the topic for the next article. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/05/07/inlined-hunit-test-lists">Inlined HUnit test lists</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Null Object as identity http://blog.ploeh.dk/2018/04/23/null-object-as-identity 2018-04-23T07:55:00+00:00 Mark Seemann <div id="post"> <p> <em>When can you implement a Null Object? When the return types of your methods are monoids.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions">a series of articles about design patterns and their category theory counterparts</a>. In a <a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">previous article</a> you learned how there's a strong relationship between the <a href="https://en.wikipedia.org/wiki/Composite_pattern">Composite</a> design pattern and <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>. In this article you'll see that the <a href="https://en.wikipedia.org/wiki/Null_Object_pattern">Null Object</a> pattern is essentially a special case of the Composite pattern. </p> <p> I also think that there's a relationship between monoidal <em>identity</em> and the Null Object pattern similar to the relationship between Composite and monoids in general: </p> <p> <img src="/content/binary/null-object-identity-set-diagram.png" alt="Set diagram showing identity as a subset of Null Object."> </p> <p> Once more, I don't claim that an isomorphism exists. You may be able to produce Null Object examples that aren't monoidal, but on the other hand, I believe that all identities are Null Objects. </p> <h3 id="b082690114af4768ac6171438c7c7657"> Null Object <a href="#b082690114af4768ac6171438c7c7657" title="permalink">#</a> </h3> <p> While the Null Object design pattern isn't one of the patterns covered in <a href="http://amzn.to/XBYukB">Design Patterns</a>, I consider it a <em>structural pattern</em> because Composite is a structural pattern, and Null Object is a special case of Composite. </p> <p> Bobby Woolf's <a href="http://amzn.to/1dEKjcj">original text</a> contains an example in <a href="https://en.wikipedia.org/wiki/Smalltalk">Smalltalk</a>, and while I'm no Smalltalk expert, I think a fair translation to C# would be an interface like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IController</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">bool</span>&nbsp;IsControlWanted(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">bool</span>&nbsp;IsControlActive(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Startup(); }</pre> </p> <p> The idea behind the Null Object pattern is to add an implementation that 'does nothing', which in the example would be this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NullController</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IController</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsControlActive() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsControlWanted() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Startup() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Woolf calls his implementation <code>NoController</code>, but I find it more intent-revealing to call it <code>NullController</code>. Both of the Boolean methods return <code>false</code>, and the <code>Startup</code> method literally does nothing. </p> <h3 id="862afa3095a847ba82c234ee1371dd70"> Doing nothing <a href="#862afa3095a847ba82c234ee1371dd70" title="permalink">#</a> </h3> <p> What exactly does it mean to 'do nothing'? In the case of the <code>Startup</code> method, it's clear, because it's a bona fide <a href="https://en.wikipedia.org/wiki/NOP">no-op</a>. This is possible for all methods without return values (i.e. methods that return <code>void</code>), but for all other methods, the compiler will insist on a return value. </p> <p> For <code>IsControlActive</code> and <code>IsControlWanted</code>, Woolf solves this by returning <code>false</code>. </p> <p> Is <code>false</code> always the correct 'do nothing' value for Booleans? And what should you return if a method returns an integer, a string, or a custom type? The original text is vague on that question: <blockquote> "Exactly what "do nothing" means is subjective and depends on the sort of behavior the Client is expecting." </blockquote> Sometimes, you can't get any closer than that, but I think that often it's possible to be more specific. </p> <h3 id="786916d104f949ce913ab94e6a0fafdc"> Doing nothing as identity <a href="#786916d104f949ce913ab94e6a0fafdc" title="permalink">#</a> </h3> <p> From <a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">unit isomorphisms</a> you know that methods without return values are isomorphic to methods that return <em>unit</em>. You also know that <em>unit</em> is a monoid. What does <em>unit</em> and <code>bool</code> have in common? They both form monoids; <code>bool</code>, in fact, forms four different monoids, of which <em>all</em> and <em>any</em> are the best-known. </p> <p> In my experience, you can implement the Null Object pattern by returning various 'do nothing' values, depending on their types: <ul> <li>For <code>bool</code>, return a constant value. Usually, <code>false</code> is the appropriate 'do nothing' value, but it does depend on the semantics of the operation.</li> <li>For <code>string</code>, return <code>""</code>.</li> <li>For collections, return an empty collection.</li> <li>For numbers, return a constant value, such as <code>0</code>.</li> <li>For <code>void</code>, do nothing, which is equivalent to returning <em>unit</em>.</li> </ul> What all of these have in common is that they return the <em>identity</em> of the monoid in question. Keep in mind that for some types, such as <code>bool</code> and <code>int</code>, more than one monoid exist, and the identity depends on which one you pick: <ul> <li>The identity for the <em>any</em> monoid is <code>false</code>.</li> <li>The <a href="http://blog.ploeh.dk/2017/10/10/strings-lists-and-sequences-as-a-monoid">identity for <code>string</code> is <code>""</code></a>.</li> <li>The identity for collections is the empty collection.</li> <li>The identity for the <em>addition</em> monoid is <code>0</code>.</li> <li>The identity for <em>unit</em> is <em>unit</em>.</li> </ul> Recall what the <em>identity</em> of a monoid is: it's the value that, when applied to another value, doesn't change the other value: </p> <p> <pre>foo.Op(<span style="color:#2b91af;">Foo</span>.Identity)&nbsp;==&nbsp;foo</pre> </p> <p> In other words: the <em>identity does nothing!</em> </p> <p> As a preliminary result, then, when all return values of your interface form monoids, you can create a Null Object. </p> <h3 id="ec81b9f4281e4c4c909d1dc606056967"> Relationship with Composite <a href="#ec81b9f4281e4c4c909d1dc606056967" title="permalink">#</a> </h3> <p> In the previous article, you saw how the Composite design pattern was equivalent with the <a href="https://www.haskell.org">Haskell</a> function <code>mconcat</code>: </p> <p> <pre>mconcat :: Monoid a =&gt; [a] -&gt; a</pre> </p> <p> This function, however, seems more limited than it has to be. It says that if you have a linked list of monoidal values, you can reduce them to a single monoidal value. Is this only true for linked lists? </p> <p> After all, in a language like C#, you'd typically express a Composite as a container of 'some collection' of objects, typically modelled by the <code>IReadOnlyCollection&lt;T&gt;</code> interface. There are several implementations of that interface, including lists, arrays, collections, and so on. </p> <p> It seems as though we ought to be able to generalise <code>mconcat</code>, and, indeed, we can. The <code>Data.Foldable</code> module defines a function called <code>fold</code>: </p> <p> <pre>fold :: (Monoid m, Foldable t) =&gt; t m -&gt; m</pre> </p> <p> Let me decipher that for you. It says that any monoid <code>m</code> contained in a 'foldable' container <code>t</code> can be reduced to a single value (still of the type <code>m</code>). You can read <code>t m</code> as 'a foldable container that contains monoids'. In C#, you could attempt to express it as <code>IFoldable&lt;TMonoid&gt;</code>. </p> <p> In other words, the Composite design pattern is equivalent to <code>fold</code>. Here's how it relates to the Null Object pattern: </p> <p> As a first step, consider methods like those defined by the above <code>IController</code> interface. In order to implement <code>NullController</code>, all of those methods ignore their (non-existent) input and return an identity value. In other words, we're looking for a Haskell function of the type <code>Monoid m =&gt; a -&gt; m</code>; that is: a function that takes input of the type <code>a</code> and returns a monoidal value <code>m</code>. </p> <p> You can do that using <code>fold</code>: </p> <p> <pre><span style="color:#600277;">nullify</span>&nbsp;::&nbsp;<span style="color:blue;">Monoid</span>&nbsp;m&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;m nullify&nbsp;<span style="color:#666666;">=</span>&nbsp;fold&nbsp;(<span style="color:#dd0000;">Identity</span>&nbsp;<span style="color:#666666;">$</span>&nbsp;const&nbsp;mempty)</pre> </p> <p> Recall that the input to <code>fold</code> must be a <code>Foldable</code> container. The good old <code>Identity</code> type is, among other capabilities, <code>Foldable</code>. That takes care of the container. The value that we put into the container is a single function that ignores its input (<code>const</code>) and always returns the identity value (<code>mempty</code>). The result is a function that always returns the identity value. </p> <p> This demonstrates that Null Object is a special case of Composite, because <code>nullify</code> is a special application of <code>fold</code>. </p> <p> There's no reason to write <code>nullify</code> in such a complicated way, though. You can simplify it like this: </p> <p> <pre><span style="color:#600277;">nullify</span>&nbsp;::&nbsp;<span style="color:blue;">Monoid</span>&nbsp;m&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;m nullify&nbsp;<span style="color:#666666;">=</span>&nbsp;const&nbsp;mempty</pre> </p> <p> Once you recall, however, that <a href="http://blog.ploeh.dk/2017/11/06/function-monoids">functions are monoids if their return values are monoids</a>, you can simplify it even further: </p> <p> <pre><span style="color:#600277;">nullify</span>&nbsp;::&nbsp;<span style="color:blue;">Monoid</span>&nbsp;m&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;m nullify&nbsp;<span style="color:#666666;">=</span>&nbsp;mempty</pre> </p> <p> The identity element for monoidal functions is exactly a function that ignores its input and returns <code>mempty</code>. </p> <h3 id="11c3a2cefcb74f7096e588c530a699a8"> Controller identity <a href="#11c3a2cefcb74f7096e588c530a699a8" title="permalink">#</a> </h3> <p> Consider the <code>IController</code> interface. According to <a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">object isomorphisms</a>, you can represent this interface as a tuple of three functions: </p> <p> <pre><span style="color:blue;">type</span>&nbsp;<span style="color:#dd0000;">Controller</span>&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;(<span style="color:#dd0000;">ControllerState</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Any</span>,&nbsp;<span style="color:#dd0000;">ControllerState</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Any</span>,&nbsp;<span style="color:#dd0000;">ControllerState</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:blue;">()</span>)</pre> </p> <p> This is cheating a little, because the third tuple element (the one that corresponds to <code>Startup</code>) is <a href="https://en.wikipedia.org/wiki/Pure_function">pure</a>, although I strongly suspect that the intent is that it should mutate the state of the Controller. Two alternatives are to change the function to either <code>ControllerState -&gt; ControllerState</code> or <code>ControllerState -&gt; IO ()</code>, but I'm going to keep things simple. It doesn't change the conclusion. </p> <p> Notice that I've used <code>Any</code> as the return type for the two first tuples. As I've previously covered, Booleans form monoids like <em>any</em> and <em>all</em>. Here, we need to use <code>Any</code>. </p> <p> This tuple is a monoid because all three functions are monoids, and <a href="http://blog.ploeh.dk/2017/10/30/tuple-monoids">a tuple of monoids is itself a monoid</a>. This means that you can easily create a Null Object using <code>mempty</code>: </p> <p> <pre>λ&gt; nullController = mempty :: Controller</pre> </p> <p> The <code>nullController</code> is a triad of functions. You can access them by pattern-matching them, like this: </p> <p> <pre>λ&gt; (isControlWanted, isControlActive, startup) = nullController</pre> </p> <p> Now you can try to call e.g. <code>isControlWanted</code> with various values in order to verify that it always returns false. In this example, I cheated and simply made <code>ControllerState</code> an alias for <code>String</code>: </p> <p> <pre>λ&gt; isControlWanted "foo" Any {getAny = False} λ&gt; isControlWanted "bar" Any {getAny = False}</pre> </p> <p> You'll get similar behaviour from <code>isControlActive</code>, and <code>startup</code> always returns <code>()</code> (<em>unit</em>). </p> <h3 id="e8bd7e04148143039708a179441b7da5"> Relaxation <a href="#e8bd7e04148143039708a179441b7da5" title="permalink">#</a> </h3> <p> As Woolf wrote in the original text, what 'do nothing' means is subjective. I think it's perfectly reasonable to say that monoidal identity fits the description of doing nothing, but you could probably encounter APIs where 'doing nothing' means something else. </p> <p> As an example, consider avatars for online forums, such as Twitter. If you don't supply a picture when you create your profile, you get a default picture. One way to implement such a feature could be by having a 'null' avatar, which is used in place of a proper avatar. Such a default avatar object could (perhaps) be considered a Null Object, but wouldn't necessarily be monoidal. There may not even be a binary operation for avatars. </p> <p> Thus, it's likely that you could encounter or create Null Objects that aren't monoids. That's the reason that I don't claim that a Null Object always is monoidal identity, although I do think that the reverse relationship holds: if it's <em>identity</em>, then it's a Null Object. </p> <h3 id="91d9a7608c884a0d9fe5d01b61d539f5"> Summary <a href="#91d9a7608c884a0d9fe5d01b61d539f5" title="permalink">#</a> </h3> <p> Monoids are associative binary operations with identity. The identity is the value that 'does nothing' in that binary operation, like, for example, <em>0</em> doesn't 'do' anything under addition. Monoids, however, can be more complex than operations on primitive values. Functions, for example, can be monoids as well, as can tuples of functions. </p> <p> The implication of that is that objects can be monoids as well. When you have a monoidal object, then its <em>identity</em> is the 'natural' Null Object. </p> <p> The question was: <em>when can you implement the Null Object pattern?</em> The answer is that you can do that when all involved methods return monoids. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/06/25/visitor-as-a-sum-type">Visitor as a sum type</a>. </p> </div> <div id="comments"> <hr /> <h2 id="comments-header">Comments</h2> <div class="comment" id="37c2c03b75684696bb16afebcbe2458d"> <div class="comment-author"> Ciprian Vilcan </div> <div class="comment-content"> <p> All the examples of using Maybe I recall seeing always wrapped a data type that had a neutral element. So Maybe&lt;int&gt; would resolve to 0 or 1, while Maybe&lt;string&gt; to string.Empty. But what about data types that do not have a neutral element? </p> <p> Suppose we have this DDD value object, NonEmptyString, written in C#. It has no public constructor and it is instantiated through a static factory method that returns a Maybe&lt;NonEmptyString&gt; containing an initialized NonEmptyString if the given input is not null or whitespace and None otherwise. </p> <p> How do you treat the None case when calling the maybe.Match method? Since the neutral element for string concatenation is string.empty, an invalid value for this value object, this type has no possibility of having a Null Object.<br> Can this situation be resolved in the functional way (without throwing an exception) or does it warrant throwing an exception? </p> </div> <div class="comment-date">2018-05-07 08:21 UTC</div> </div> <div class="comment" id="be75b93e68a8441f9bf9cea62a1d94a5"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for writing. I'm not sure I understand what you man by <em>Maybe</em> wrapping a neutral element. I hope that's not how <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">my introduction to Maybe</a> comes across. Could you point to specific examples? </p> <p> If <code>NonEmptyString</code> is, as the name implies, a <code>string</code> guaranteed to be non-empty, isn't it just a specialisation of <a href="http://blog.ploeh.dk/2017/12/11/semigroups-accumulate/#68b942712506472ebe4c6933ca7dbd56">NotEmptyCollection&lt;T&gt;</a>? If so, indeed, there's no <em>identity</em> for <code>NonEmptyString</code> (but it does form a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">Semigroup</a>). </p> <p> Since it's a semigroup, though, <a href="http://blog.ploeh.dk/2018/04/03/maybe-monoids/#79ed6bcdafca4afd91cd22f6f9cbc4a2">you can lift it to a monoid my wrapping it in Maybe</a>. If you do that, the identity of <code>Maybe&lt;NonEmptyString&gt;</code> would be <em>nothing</em>. </p> </div> <div class="comment-date">2018-05-08 1:53 UTC</div> </div> <div class="comment" id="f78e2713d0634dd39c1674ebcda763dd"> <div class="comment-author"> Ciprian Vilcan </div> <div class="comment-content"> <p> You are right, Mark. The <code>NonEmptyString</code> class is indeed a semigroup, thus has no neutral element. <br> This is not what confuses me, but what function to supply in the None case of a <code>Maybe&lt;SomeSemigroup&gt;</code> when calling the <code>.Match</code> method. In the case of <code>Maybe&lt;SomeMonoid&gt;</code>, it's simple and intuitive, as you simply supply a function that returns the neutral element of that monoid. <br> But what about semigroups? </p> <p> Here's a couple of generalized examples to better illustrate the question I'm having: <br> <code> Maybe&lt;SomeMonoid&gt; firstMaybe = someService.GetSomeMonoid(); <br> SomeMonoid value = firstMaybe.Match(Some: containedValue => containedValue, None: () => SomeMonoid.NeutralElement); <br> <br> Maybe&lt;SomeSemigroup&gt; secondMaybe = someService.GetSomeSemigroup(); <br> SomeSemigroup someSemigroup = secondMaybe.Match(Some: containedValue => containedValue, None: () => /*What to do here? Is it appropriate to throw an exception?*/); </code> </p> <p> I hope this time my question became clearer. I'm still in the process of wrapping my head around functional and category theory concepts, so my terminology may not be pinpoint accurate. </p> </div> <div class="comment-date">2018-05-11 06:44 UTC</div> </div> <div class="comment" id="2cae69987a0443a191f21d1bf4930ab1"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, that's the problem with semigroups, isn't it? There's no single natural element to use in the absence of data. </p> <p> Lifting a semigroup to a Maybe is one way to resolve that problem. Since <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe is a functor</a>, you can map the contents of the Maybe until you've mapped it into a value for which an identity exists. </p> <p> In some cases, you can also fold a Maybe value by supplying a default value that makes sense in the specific context. A default value can be an appropriate fall-back value in a given context, even if it isn't a general identity. </p> </div> <div class="comment-date">2018-05-12 8:20 UTC</div> </div> <div class="comment" id="9640402dd2834ba0b75d4c1f810dfeaa"> <div class="comment-author"> Ciprian Vilcan </div> <div class="comment-content"> <p> I think I got it!<br> If you want to process that <code>Maybe&lt;SomeSemigroup&gt;</code> in a functional way, using the .Match(Some: ..., None: ...) method, you actually have to transform the method using it from a mostly statement based one, to a mostly expression based one. You have to pretend you don't know what's inside that Maybe for as long as possible, similar to using Lazy (or lazy evaluation in general). </p> <p> In <a href="https://dotnetfiddle.net/8vP47X">this</a> fiddle I've played around and created both an imperative and functional query method for retrieving a book by title and author, in order to prove myself that they can be made isomorphic. These two methods are GetBookFunctional and GetBookImperative.<br> However, I'm now trying to transform the GetBookImperativeWithoutElses into something functional using that .Match method, but I don't think it's possible.<br> The .Match method's signature is, practically speaking, equivalent to the if-else statement, whereas the GetBookImperativeWithoutElses method uses the if statement, meaning the functional approach will be forced to treat the elses, whereas the imperative one won't. </p> <p> Wow, so if you want to use this Maybe of semigroup and/or go fully functional, you really have to go deep down the functional rabbit hole.<br> Also, my guess is there is no guarantee that going from imperative to functional does not introduce more redundancy (like the elses in the second set of methods) into your system.<br> </p> <p> Am I right in these regards? </p> </div> <div class="comment-date">2018-05-12 13:45 UTC</div> </div> <div class="comment" id="fc2325a9be294305916c8bfbdac119bf"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for the link to the code. This explains why you're running into trouble. You absolutely can address the scenario that causes you trouble in a nice functional style, but once you start having the need to keep track of error data as well as happy-path data, <em>Maybe</em> is no longer the data structure you need. </p> <p> <em>Maybe</em> enables you to model a case where data may or may not be available. It enables you distinguish something from nothing. On the other hand, in the absence of data, you have no information about the reason that data is missing. </p> <p> In order to keep track of such information, you need <em>Either</em>, which models data that's either this or that. </p> <p> I'll cover <em>Either</em> in future posts. </p> </div> <div class="comment-date">2018-05-13 14:44 UTC</div> </div> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Endomorphic Composite as a monoid http://blog.ploeh.dk/2018/04/16/endomorphic-composite-as-a-monoid 2018-04-16T08:16:00+00:00 Mark Seemann <div id="post"> <p> <em>A variation of the Composite design pattern uses endomorphic composition. That's still a monoid.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions">a series of articles about design patterns and their category theory counterparts</a>. In a <a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">previous article</a>, you learned that the <a href="https://en.wikipedia.org/wiki/Composite_pattern">Composite</a> design pattern is simply a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. </p> <p> There is, however, a variation of the Composite design pattern where the return value from one step can be used as the input for the next step. </p> <h3 id="e0d1e07a05e14c34aa72e67a2e5fae61"> Endomorphic API <a href="#e0d1e07a05e14c34aa72e67a2e5fae61" title="permalink">#</a> </h3> <p> Imagine that you have to implement some scheduling functionality. For example, you may need to schedule something to happen a month from now, but it should happen on a bank day, during business hours, and you want to know what the resulting date and time will be, expressed in <a href="https://en.wikipedia.org/wiki/Coordinated_Universal_Time">UTC</a>. I've <a href="http://blog.ploeh.dk/2017/11/13/endomorphism-monoid">previously covered the various objects for performing such steps</a>. The common behaviour is this interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value); }</pre> </p> <p> The <code>Adjust</code> method is an <a href="https://en.wikipedia.org/wiki/Endomorphism">endomorphism</a>; that is: the input type is the same as the return type, in this case <code>DateTimeOffset</code>. A <a href="http://blog.ploeh.dk/2017/11/13/endomorphism-monoid">previous article</a> already established that that's a monoid. </p> <h3 id="24dd8cb072b8434890ddb71fbb5e3ec9"> Composite endomorphism <a href="#24dd8cb072b8434890ddb71fbb5e3ec9" title="permalink">#</a> </h3> <p> If you have various implementations of <code>IDateTimeOffsetAdjustment</code>, you can make a Composite from them, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">CompositeDateTimeOffsetAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&gt;&nbsp;adjustments; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;CompositeDateTimeOffsetAdjustment( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&gt;&nbsp;adjustments) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(adjustments&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(adjustments)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.adjustments&nbsp;=&nbsp;adjustments; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;adjustment&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.adjustments) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;adjustment.Adjust(acc); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Adjust</code> method simply starts with the input <code>value</code> and loops over all the composed <code>adjustments</code>. For each <code>adjustment</code> it adjusts <code>acc</code> to produce a new <code>acc</code> value. This goes on until all <code>adjustments</code> have had a chance to adjust the value. </p> <p> Notice that if <code>adjustments</code> is empty, the <code>Adjust</code> method simply returns the input value. In that degenerate case, the behaviour is similar to the identity function, which is the identity for the endomorphism monoid. </p> <p> You can now compose the desired behaviour, as this parametrised <a href="https://xunit.github.io">xUnit.net</a> test demonstrates: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-01-31T07:45:55+2&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-02-28T07:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-06T10:03:02+1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-03-06T09:03:02Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-09T04:20:00Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-09T09:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-12T16:02:11Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-10T16:02:11Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-03-14T13:48:29-1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-04-13T14:48:29Z&quot;</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AdjustReturnsCorrectResult( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;dtS, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;expectedS) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;dt&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>.Parse(dtS); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CompositeDateTimeOffsetAdjustment</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NextMonthAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BusinessHoursAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DutchBankDayAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">UtcAdjustment</span>()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Adjust(dt); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#2b91af;">DateTimeOffset</span>.Parse(expectedS),&nbsp;actual); }</pre> </p> <p> You can see the implementation for all four composed classes in the <a href="http://blog.ploeh.dk/2017/11/13/endomorphism-monoid">previous article</a>. <code>NextMonthAdjustment</code> adjusts a date by a month into its future, <code>BusinessHoursAdjustment</code> adjusts a time to business hours, <code>DutchBankDayAdjustment</code> takes bank holidays and weekends into account in order to return a bank day, and <code>UtcAdjustment</code> convert a date and time to UTC. </p> <h3 id="5743387ec7f94a00861517d399756ab2"> Monoidal accumulation <a href="#5743387ec7f94a00861517d399756ab2" title="permalink">#</a> </h3> <p> As you've learned in that previous article that I've already referred to, an endomorphism is a monoid. In this particular example, the binary operation in question is called <code>Append</code>. From another article, you know that <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">monoids accumulate</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;Accumulate( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&gt;&nbsp;adjustments) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;acc&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">IdentityDateTimeOffsetAdjustment</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;adjustment&nbsp;<span style="color:blue;">in</span>&nbsp;adjustments) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;Append(acc,&nbsp;adjustment); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> This implementation follows the template previously described: <ul> <li>Initialize a variable <code>acc</code> with the identity element. In this case, the identity is a class called <code>IdentityDateTimeOffsetAdjustment</code>.</li> <li>For each <code>adjustment</code> in <code>adjustments</code>, <code>Append</code> the <code>adjustment</code> to <code>acc</code>.</li> <li>Return <code>acc</code>.</li> </ul> This is an entirely automatable process, and it's only C#'s lack of higher-kinded types that prevents us from writing that code once and for all. In <a href="https://www.haskell.org">Haskell</a>, this general-purpose function exists; it's called <code>mconcat</code>. We'll get back to that in a moment, but first, here's another parametrised unit test that exercises the same test cases as the previous test, only against a composition created by <code>Accumulate</code>: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-01-31T07:45:55+2&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-02-28T07:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-06T10:03:02+1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-03-06T09:03:02Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-09T04:20:00Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-09T09:00:00Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-02-12T16:02:11Z&quot;</span>&nbsp;,&nbsp;<span style="color:#a31515;">&quot;2017-03-10T16:02:11Z&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;2017-03-14T13:48:29-1&quot;</span>,&nbsp;<span style="color:#a31515;">&quot;2017-04-13T14:48:29Z&quot;</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AccumulatedAdjustReturnsCorrectResult( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;dtS, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">string</span>&nbsp;expectedS) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;dt&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>.Parse(dtS); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:#2b91af;">DateTimeOffsetAdjustment</span>.Accumulate( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NextMonthAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BusinessHoursAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DutchBankDayAdjustment</span>(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">UtcAdjustment</span>()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;sut.Adjust(dt); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(<span style="color:#2b91af;">DateTimeOffset</span>.Parse(expectedS),&nbsp;actual); }</pre> </p> <p> While the implementation is different, this monoidal composition has the same behaviour as the above <code>CompositeDateTimeOffsetAdjustment</code> class. This, again, emphasises that Composites are simply monoids. </p> <h3 id="45b98ea80cb143f2af692a7cd7ac2a4b"> Endo <a href="#45b98ea80cb143f2af692a7cd7ac2a4b" title="permalink">#</a> </h3> <p> For comparison, this section demonstrates how to implement the above behaviour in Haskell. The code here passes the same test cases as those above. You can skip to the next section if you want to get to the conclusion. </p> <p> Instead of classes that implement interfaces, in Haskell you can define functions with the type <code>ZonedTime -&gt; ZonedTime</code>. You can compose such functions using the <code>Endo</code> <code>newtype</code> 'wrapper' that turns endomorphisms into monoids: </p> <p> <pre>λ&gt; adjustments = reverse [adjustToNextMonth, adjustToBusinessHours, adjustToDutchBankDay, adjustToUtc] λ&gt; :type adjustments adjustments :: [ZonedTime -&gt; ZonedTime] λ&gt; adjust = appEndo $ mconcat $ Endo &lt;$&gt; adjustments λ&gt; :type adjust adjust :: ZonedTime -&gt; ZonedTime</pre> </p> <p> In this example, I'm using GHCi (the Haskell REPL) to show the composition in two steps. The first step creates <code>adjustments</code>, which is a list of functions. In case you're wondering about the use of the <code>reverse</code> function, it turns out that <code>mconcat</code> composes from right to left, which I found counter-intuitive in this case. <code>adjustToNextMonth</code> should execute first, followed by <code>adjustToBusinessHours</code>, and so on. Defining the functions in the more intuitive left-to-right direction and then reversing it makes the code easier to understand, I hope. </p> <p> (For the Haskell connoisseurs, you can also achieve the same result by composing <code>Endo</code> with the <code>Dual</code> monoid, instead of reversing the list of adjustments.) </p> <p> The second step composes <code>adjust</code> from <code>adjustments</code>. It first maps <code>adjustments</code> to <code>Endo</code> values. While <code>ZonedTime -&gt; ZonedTime</code> isn't a <code>Monoid</code> instances, <code>Endo ZonedTime</code> is. This means that you can reduce a list of <code>Endo ZonedTime</code> with <code>mconcat</code>. The result is a single <code>Endo ZonedTime</code> value, which you can then unwrap to a function using <code>appEndo</code>. </p> <p> <code>adjust</code> is a function that you can call: </p> <p> <pre>λ&gt; dt 2017-01-31 07:45:55 +0200 λ&gt; adjust dt 2017-02-28 07:00:00 +0000</pre> </p> <p> In this example, I'd already prepared a <code>ZonedTime</code> value called <code>dt</code>. Calling <code>adjust</code> returns a new <code>ZonedTime</code> adjusted by all four composed functions. </p> <h3 id="675b6bd1899746c8963eb97a8580fb24"> Conclusion <a href="#675b6bd1899746c8963eb97a8580fb24" title="permalink">#</a> </h3> <p> In general, you implement the Composite design pattern by calling all composed functions with the original input value, collecting the return value of each call. In the final step, you then reduce the collected return values to a single value that you return. This requires the return type to form a monoid, because otherwise, you can't reduce it. </p> <p> In this article, however, you learned about an alternative implementation of the Composite design pattern. If the method that you compose has the same output type as its input, you can pass the output from one object as the input to the next object. In that case, you can escape the requirement that the return value is a monoid. That's the case with <code>DateTimeOffset</code> and <code>ZonedTime</code>: neither are monoids, because you can't add two dates and times together. </p> <p> At first glance, then, it seems like a falsification of the original claim that Composites are monoids. As you've learned in this article, however, endomorphisms are monoids, so the claim still stands. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/04/23/null-object-as-identity">Null Object as identity</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Coalescing Composite as a monoid http://blog.ploeh.dk/2018/04/09/coalescing-composite-as-a-monoid 2018-04-09T08:15:00+00:00 Mark Seemann <div id="post"> <p> <em>A variation of the Composite design pattern uses coalescing behaviour to return non-composable values. That's still a monoid.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions">a series of articles about design patterns and their category theory counterparts</a>. In <a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">a previous article</a>, you learned that the <a href="https://en.wikipedia.org/wiki/Composite_pattern">Composite</a> design pattern is simply a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. </p> <h3 id="ee5e76abfc9c4fe58a5e232579e397c5"> Monoidal return types <a href="#ee5e76abfc9c4fe58a5e232579e397c5" title="permalink">#</a> </h3> <p> When all methods of an interface return monoids, you can create a Composite. This is fairly intuitive once you understand what a monoid is. Consider this example interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">ICustomerRepository</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Create(<span style="color:#2b91af;">Customer</span>&nbsp;customer); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Customer</span>&nbsp;Read(<span style="color:#2b91af;">Guid</span>&nbsp;id); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Update(<span style="color:#2b91af;">Customer</span>&nbsp;customer); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Delete(<span style="color:#2b91af;">Guid</span>&nbsp;id); }</pre> </p> <p> While this interface is, in fact, not readily composable, most of the methods are. It's easy to compose the three <code>void</code> methods. Here's a composition of the <code>Create</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Create(<span style="color:#2b91af;">Customer</span>&nbsp;customer) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;repository&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.repositories) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;repository.Create(customer); }</pre> </p> <p> In this case it's easy to compose multiple repositories, because <code>void</code> (<a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">or, rather, <em>unit</em></a>) forms a monoid. If you have methods that return numbers, you can add the numbers together (a monoid). If you have methods that return strings, you can concatenate the strings (a monoid). If you have methods that return Boolean values, you can <em>or</em> or <em>and</em> them together (more monoids). </p> <p> What about the above <code>Read</code> method, though? </p> <h3 id="05eec84ac1514c10bdbb0dbc6b36a957"> Picking the first Repository <a href="#05eec84ac1514c10bdbb0dbc6b36a957" title="permalink">#</a> </h3> <p> Why would you even want to compose two repositories? One scenario is where you have an old data store, and you want to move to a new data store. For a while, you wish to write to both data stores, but one of them stays the 'primary' data store, so this is the one from which you read. </p> <p> Imagine that the old repository saves customer information as JSON files on disk. The new data store, on the other hand, saves customer data as JSON documents in <a href="https://azure.microsoft.com/en-us/services/storage/blobs">Azure Blob Storage</a>. You've already written two implementations of <code>ICustomerRepository</code>: <code>FileCustomerRepository</code> and <code>AzureCustomerRepository</code>. How do you compose them? </p> <p> The three methods that return <code>void</code> are easy, as the above <code>Create</code> implementation demonstrates. The <code>Read</code> method, however, is more tricky. </p> <p> One option is to only query the first repository, and return its return value: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Customer</span>&nbsp;Read(<span style="color:#2b91af;">Guid</span>&nbsp;id) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.repositories.First().Read(id); }</pre> </p> <p> This works, but doesn't generalise. It works if you know that you have a non-empty collection of repositories, but if you want to adhere to the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Liskov Substitution Principle</a>, you should be able to handle the case where there's no repositories. </p> <p> A Composite should be able to compose an arbitrary number of other objects. This includes a collection of no objects. The <code>CompositeCustomerRepository</code> class has this constructor: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICustomerRepository</span>&gt;&nbsp;repositories; <span style="color:blue;">public</span>&nbsp;CompositeCustomerRepository( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">ICustomerRepository</span>&gt;&nbsp;repositories) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(repositories&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(repositories)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.repositories&nbsp;=&nbsp;repositories; }</pre> </p> <p> It uses standard Constructor Injection to inject an <code>IReadOnlyCollection&lt;ICustomerRepository&gt;</code>. Such a collection is finite, but can be empty. </p> <p> Another problem with blindly returning the value from the first repository is that the return value may be empty. </p> <p> In C#, people often use <code>null</code> to indicate a missing value, and while I find such practice unwise, I'll pursue this option for a bit. </p> <p> A more robust Composite would return the first non-null value it gets: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Customer</span>&nbsp;Read(<span style="color:#2b91af;">Guid</span>&nbsp;id) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;repository&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.repositories) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;customer&nbsp;=&nbsp;repository.Read(id); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(customer&nbsp;!=&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;customer; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">null</span>; }</pre> </p> <p> This implementation loops through all the injected <code>repositories</code> and calls <code>Read</code> on each until it gets a result that is not <code>null</code>. This will often be the first value, but doesn't have to be. If all repositories return <code>null</code>, then the Composite also returns <code>null</code>. To emphasise my position, I would never design C# code like this, but at least it's consistent. </p> <p> If you've ever worked with relational databases, you may have had an opportunity to use the <code>COALESCE</code> function, which works in exactly the same way. This is the reason I call such an implementation a <em>coalescing Composite</em>. </p> <h3 id="ae3e089ecda84bd299e44c22554f5b85"> The First monoid <a href="#ae3e089ecda84bd299e44c22554f5b85" title="permalink">#</a> </h3> <p> The <a href="https://docs.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql">T-SQL documentation for COALESCE</a> describes the operation like this: <blockquote> "Evaluates the arguments in order and returns the current value of the first expression that initially does not evaluate to <code>NULL</code>." </blockquote> The <a href="https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions023.htm#SQLRF00617">Oracle documentation</a> expresses it as: <blockquote> "<code>COALESCE</code> returns the first non-null <code>expr</code> in the expression list." </blockquote> This may not be apparent, but that's a monoid. </p> <p> <a href="https://www.haskell.org">Haskell</a>'s base library comes with a monoidal type called <code>First</code>, which is a <blockquote> "Maybe monoid returning the leftmost non-Nothing value." </blockquote> Sounds familiar? </p> <p> Here's how you can use it in GHCi: </p> <p> <pre>λ&gt; First (Just (Customer id1 "Joan")) &lt;&gt; First (Just (Customer id2 "Nigel")) First {getFirst = Just (Customer {customerId = 1243, customerName = "Joan"})} λ&gt; First (Just (Customer id1 "Joan")) &lt;&gt; First Nothing First {getFirst = Just (Customer {customerId = 1243, customerName = "Joan"})} λ&gt; First Nothing &lt;&gt; First (Just (Customer id2 "Nigel")) First {getFirst = Just (Customer {customerId = 5cd5, customerName = "Nigel"})} λ&gt; First Nothing &lt;&gt; First Nothing First {getFirst = Nothing}</pre> </p> <p> (To be clear, the above examples uses <code>First</code> from <code>Data.Monoid</code>, not <code>First</code> from <code>Data.Semigroup</code>.) </p> <p> The operator <code>&lt;&gt;</code> is an infix alias for <code>mappend</code> - Haskell's polymorphic binary operation. </p> <p> As long as the left-most value is present, that's the return value, regardless of whether the right value is <code>Just</code> or <code>Nothing</code>. Only when the left value is <code>Nothing</code> is the right value returned. Notice that this value may also be <code>Nothing</code>, causing the entire expression to be <code>Nothing</code>. </p> <p> That's exactly the same behaviour as the above implementation of the <code>Read</code> method. </p> <h3 id="c83d6ec43ba94073b151841289050fba"> First in C# <a href="#c83d6ec43ba94073b151841289050fba" title="permalink">#</a> </h3> <p> It's easy to port Haskell's <code>First</code> type to C#: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;item; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;hasItem; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;First() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.hasItem&nbsp;=&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;First(<span style="color:#2b91af;">T</span>&nbsp;item) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(item&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(item)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.item&nbsp;=&nbsp;item; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.hasItem&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;FindFirst(<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;other) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(<span style="color:blue;">this</span>.hasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;other; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Instead of nesting <code>Maybe</code> inside of <code>First</code>, as Haskell does, I simplified a bit and gave <code>First&lt;T&gt;</code> two constructor overloads: one that takes a value, and one that doesn't. The <code>FindFirst</code> method is the binary operation that corresponds to Haskell's <code>&lt;&gt;</code> or <code>mappend</code>. </p> <p> This is only one of several alternative implementations of <a href="http://blog.ploeh.dk/2018/04/03/maybe-monoids">the <em>first</em> monoid</a>. </p> <p> In order to make <code>First&lt;T&gt;</code> a monoid, it must also have an identity, which is just an empty value: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Identity&lt;<span style="color:#2b91af;">T</span>&gt;() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;(); }</pre> </p> <p> This enables you to <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">accumulate</a> an arbitrary number of <code>First&lt;T&gt;</code> values to a single value: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Accumulate&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">IReadOnlyList</span>&lt;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">T</span>&gt;&gt;&nbsp;firsts) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;Identity&lt;<span style="color:#2b91af;">T</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;first&nbsp;<span style="color:blue;">in</span>&nbsp;firsts) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;acc.FindFirst(first); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> You start with the identity, which is also the return value if <code>firsts</code> is empty. If that's not the case, you loop through all <code>firsts</code> and update <code>acc</code> by calling <code>FindFirst</code>. </p> <h3 id="d90234ded89e483bbc6eb8db9ffb0a19"> A composable Repository <a href="#d90234ded89e483bbc6eb8db9ffb0a19" title="permalink">#</a> </h3> <p> You can formalise such a design by changing the <code>ICustomerRepository</code> interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">ICustomerRepository</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Create(<span style="color:#2b91af;">Customer</span>&nbsp;customer); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">Customer</span>&gt;&nbsp;Read(<span style="color:#2b91af;">Guid</span>&nbsp;id); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Update(<span style="color:#2b91af;">Customer</span>&nbsp;customer); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Delete(<span style="color:#2b91af;">Guid</span>&nbsp;id); }</pre> </p> <p> In this modified version, <code>Read</code> explicitly returns <code>First&lt;Customer&gt;</code>. The rest of the methods remain as before. </p> <p> The reusable API of <code>First</code> makes it easy to implement a Composite version of <code>Read</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">Customer</span>&gt;&nbsp;Read(<span style="color:#2b91af;">Guid</span>&nbsp;id) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;candidates&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">List</span>&lt;<span style="color:#2b91af;">First</span>&lt;<span style="color:#2b91af;">Customer</span>&gt;&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;repository&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.repositories) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;candidates.Add(repository.Read(id)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">First</span>.Accumulate(candidates); }</pre> </p> <p> You could argue that this seems to be wasteful, because it calls <code>Read</code> on all repositories. If the first Repository returns a value, all remaining queries are wasted. You can address that issue with lazy evaluation. </p> <p> You can see (a recording of) a live demo of the example in this article in my <a href="https://cleancoders.com">Clean Coders</a> video <a href="https://cleancoders.com/episode/humane-code-real-episode-2/show">Composite as Universal Abstraction</a>. </p> <h3 id="8c301e16ccf34fd099e4f97503c005c5"> Summary <a href="#8c301e16ccf34fd099e4f97503c005c5" title="permalink">#</a> </h3> <p> While the typical Composite is implemented by directly aggregating the return values from the composed objects, variations exist. One variation picks the first non-empty value from a collection of candidates, reminiscent of the SQL <code>COALESCE</code> function. This is, however, still a monoid, so the overall conjecture that Composites are monoids still holds. </p> <p> Another Composite variation exists, but that one turns out to be a monoid as well. Read on! </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/04/16/endomorphic-composite-as-a-monoid">Endomorphic Composite as a monoid</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Maybe monoids http://blog.ploeh.dk/2018/04/03/maybe-monoids 2018-04-03T12:58:00+00:00 Mark Seemann <div id="post"> <p> <em>You can combine Maybe objects in several ways. An article for object-oriented programmers.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/10/06/monoids">series about monoids</a>. In short, a monoid is an associative binary operation with a neutral element (also known as identity). </p> <p> You can combine <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a> objects in various ways, thereby turning them into monoids. There's at least two unconstrained monoids over Maybe values, as well as some constrained monoids. By <em>constrained</em> I mean that the monoid only exists for Maybe objects that contain certain values. You'll see such an example first. </p> <h3 id="7a7573db11bf4e73b49aa84b7c9d1253"> Combining Maybes over semigroups <a href="#7a7573db11bf4e73b49aa84b7c9d1253" title="permalink">#</a> </h3> <p> If you have two Maybe objects, and they both (potentially) contain values that form a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a>, you can combine the Maybe values as well. Here's a few examples. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;CombineMinimum(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem&nbsp;&amp;&amp;&nbsp;y.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;(<span style="color:#2b91af;">Math</span>.Min(x.Item,&nbsp;y.Item)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> In this first example, the semigroup operation in question is the <em>minimum</em> operation. Since C# doesn't enable you to write generic code over mathematical operations, the above method just gives you an example implemented for <code>Maybe&lt;int&gt;</code> values. If you also want to support e.g. <code>Maybe&lt;decimal&gt;</code> or <code>Maybe&lt;long&gt;</code>, you'll have to add overloads for those types. </p> <p> If both <code>x</code> and <code>y</code> have values, you get the minimum of those, still wrapped in a Maybe container: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;(42); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;(1337); <span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:#2b91af;">Maybe</span>.CombineMinimum(x,&nbsp;y);</pre> </p> <p> Here, <code>m</code> is a <code>new Maybe&lt;int&gt;(42)</code>. </p> <p> It's possible to combine any two Maybe objects as long as you have a way to combine the contained values in the case where both Maybe objects contain values. In other words, you need a binary operation, so the contained values must form a semigroup, like, for example, the <em>minimum</em> operation. Another example is <em>maximum:</em> </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;&nbsp;CombineMaximum(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem&nbsp;&amp;&amp;&nbsp;y.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;(<span style="color:#2b91af;">Math</span>.Max(x.Item,&nbsp;y.Item)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> In order to vary the examples, I chose to implement this operation for <code>decimal</code> instead of <code>int</code>, but you can see that the implementation code follows the same template. When both <code>x</code> and <code>y</code> contains values, you invoke the binary operation. If, on the other hand, <code>y</code> is empty, then right identity still holds: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;(42); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">decimal</span>&gt;(); <span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:#2b91af;">Maybe</span>.CombineMaximum(x,&nbsp;y);</pre> </p> <p> Since <code>y</code> in the above example is empty, the resulting object <code>m</code> is a <code>new Maybe&lt;decimal&gt;(42)</code>. </p> <p> You don't have to constrain yourself to semigroups exclusively. You can use a monoid as well, such as the <em>sum</em> monoid: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">long</span>&gt;&nbsp;CombineSum(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">long</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">long</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem&nbsp;&amp;&amp;&nbsp;y.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">long</span>&gt;(x.Item&nbsp;+&nbsp;y.Item); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> Again, notice how most of this code is boilerplate code that follows the same template as above. In C#, unfortunately, you have to write out all the combinations of operations and contained types, but in <a href="https://www.haskell.org">Haskell</a>, with its stronger type system, it all comes in the base library: </p> <p> <pre>Prelude Data.Semigroup&gt; Option (Just (Min 42)) &lt;&gt; Option (Just (Min 1337)) Option {getOption = Just (Min {getMin = 42})} Prelude Data.Semigroup&gt; Option (Just (Max 42)) &lt;&gt; mempty Option {getOption = Just (Max {getMax = 42})} Prelude Data.Semigroup&gt; mempty &lt;&gt; Option (Just (Sum 1337)) Option {getOption = Just (Sum {getSum = 1337})}</pre> </p> <p> That particular monoid over Maybe, however, does require as a minimum that the contained values form a semigroup. There are other monoids over Maybe that don't have any such constraints. </p> <h3 id="a21e44f2039d440f9e9469770a47777e"> First <a href="#a21e44f2039d440f9e9469770a47777e" title="permalink">#</a> </h3> <p> As you can read in <a href="http://blog.ploeh.dk/2017/11/27/semigroups">the introductory article about semigroups</a>, there's two semigroup operations called <em>first</em> and <em>last</em>. Similarly, there's two operations by the same name defined over monoids. They behave a little differently, although they're related. </p> <p> The <em>first</em> monoid operation <em>returns the left-most non-empty value</em> among candidates. You can view <em>nothing</em> as being a <a href="http://blog.ploeh.dk/2015/11/13/null-has-no-type-but-maybe-has">type-safe equivalent to null</a>, in which case this monoid is equivalent to a <a href="https://en.wikipedia.org/wiki/Null_coalescing_operator">null coalescing operator</a>. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;First&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> As long as <code>x</code> contains a value, <code>First</code> returns it. The contained values don't have to form monoids or semigroups, as this example demonstrates: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;03C2ECDBEF1D46039DE94A9994BA3C1E&quot;</span>)); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;A1B7BC82928F4DA892D72567548A8826&quot;</span>)); <span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:#2b91af;">Maybe</span>.First(x,&nbsp;y);</pre> </p> <p> While I'm not aware of any reasonable way to combine <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">GUIDs</a>, you can still pick the left-most non-empty value. In the above example, <code>m</code> contains <code>03C2ECDBEF1D46039DE94A9994BA3C1E</code>. If, on the other hand, the first value is empty, you get a different result: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;2A2D19DE89D84EFD9E5BEE7C4ADAFD90&quot;</span>)); <span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:#2b91af;">Maybe</span>.First(x,&nbsp;y);</pre> </p> <p> In this case, <code>m</code> contains <code>2A2D19DE89D84EFD9E5BEE7C4ADAFD90</code>, even though it comes from <code>y</code>. </p> <p> Notice that there's no guarantee that <code>First</code> returns a non-empty value. If both <code>x</code> and <code>y</code> are empty, then the result is also empty. The <code>First</code> operation is an associative binary operation, and the identity is the empty value (often called <em>nothing</em> or <em>none</em>). It's a monoid. </p> <h3 id="119e8d969d5e4f35a47c6c17947a28f9"> Last <a href="#119e8d969d5e4f35a47c6c17947a28f9" title="permalink">#</a> </h3> <p> Since you can define a binary operation called <code>First</code>, it's obvious that you can also define one called <code>Last</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Last&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(y.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; }</pre> </p> <p> This operation <em>returns the right-most non-empty value</em>: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;1D9326CDA0B3484AB495DFD280F990A3&quot;</span>)); <span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">Guid</span>&gt;(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;FFFC6CE263C7490EA0290017FE02D9D4&quot;</span>)); <span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:#2b91af;">Maybe</span>.Last(x,&nbsp;y);</pre> </p> <p> In this example, <code>m</code> contains <code>FFFC6CE263C7490EA0290017FE02D9D4</code>, but while <code>Last</code> favours <code>y</code>, it'll still return <code>x</code> if <code>y</code> is empty. Notice that, like <code>First</code>, there's no guarantee that you'll receive a populated Maybe. If both <code>x</code> and <code>y</code> are empty, the result will be empty as well. </p> <p> Like <code>First</code>, <code>Last</code> is an associative binary operation with <em>nothing</em> as the identity. </p> <h3 id="79ed6bcdafca4afd91cd22f6f9cbc4a2"> Generalisation <a href="#79ed6bcdafca4afd91cd22f6f9cbc4a2" title="permalink">#</a> </h3> <p> The first examples you saw in this article (<code>CombineMinimum</code>, <code>CombineMaximum</code>, and so on), came with the constraint that the contained values form a semigroup. The <code>First</code> and <code>Last</code> operations, on the other hand, seem unconstrained. They work even on GUIDs, which notoriously can't be combined. </p> <p> If you recall, though, <em>first</em> and <em>last</em> are both associative binary operations. They are, in fact, unconstrained semigroups. Recall the <code>Last</code> semigroup: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Last&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> This binary operation operates on any unconstrained type <code>T</code>, including <code>Guid</code>. It unconditionally returns <code>y</code>. </p> <p> You could implement the <code>Last</code> monoid over Maybe using the same template as above, utilising the underlying semigroup: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Last&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;x,&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem&nbsp;&amp;&amp;&nbsp;y.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;(Last(x.Item,&nbsp;y.Item)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> This implementation has exactly the same behaviour as the previous implementation of <code>Last</code> shown earlier. You can implement <code>First</code> in the same way. </p> <p> That's exactly how Haskell works: </p> <p> <pre>Prelude Data.Semigroup Data.UUID.Types&gt; x = sequence $ Last $ fromString "03C2ECDB-EF1D-4603-9DE9-4A9994BA3C1E" Prelude Data.Semigroup Data.UUID.Types&gt; x Just (Last {getLast = 03c2ecdb-ef1d-4603-9de9-4a9994ba3c1e}) Prelude Data.Semigroup Data.UUID.Types&gt; y = sequence $ Last $ fromString "A1B7BC82-928F-4DA8-92D7-2567548A8826" Prelude Data.Semigroup Data.UUID.Types&gt; y Just (Last {getLast = a1b7bc82-928f-4da8-92d7-2567548a8826}) Prelude Data.Semigroup Data.UUID.Types&gt; Option x &lt;&gt; Option y Option {getOption = Just (Last {getLast = a1b7bc82-928f-4da8-92d7-2567548a8826})} Prelude Data.Semigroup Data.UUID.Types&gt; Option x &lt;&gt; mempty Option {getOption = Just (Last {getLast = 03c2ecdb-ef1d-4603-9de9-4a9994ba3c1e})}</pre> </p> <p> The <code>&lt;&gt;</code> operator is the generic binary operation, and the way Haskell works, it changes behaviour depending on the type upon which it operates. <code>Option</code> is a wrapper around <code>Maybe</code>, and <code>Last</code> represents the <em>last</em> semigroup. When you stack <code>UUID</code> values inside of <code>Option Last</code>, you get the behaviour of selecting the right-most non-empty value. </p> <p> In fact, <blockquote> <a href="https://en.wikipedia.org/wiki/Monoid">Any semigroup <em>S</em> may be turned into a monoid simply by adjoining an element <em>e</em> not in <em>S</em> and defining <em>e</em> • <em>s</em> = <em>s</em> = <em>s</em> • <em>e</em> for all <em>s</em> ∈ <em>S</em>.</a> </blockquote> </p> <p> <img src="/content/binary/semigroup-to-monoid.png" alt="semigroup-to-monoid diagram"> </p> <p> That's just a mathematical way of saying that if you have a semigroup, you can add an extra value <em>e</em> and make <em>e</em> behave like the identity for the monoid you're creating. That extra value is <em>nothing</em>. The way Haskell's <code>Data.Semigroup</code> module models a monoid over Maybe instances aligns with the underlying mathematics. </p> <h3 id="908819d511be489e8f02f7751b666804"> Conclusion <a href="#908819d511be489e8f02f7751b666804" title="permalink">#</a> </h3> <p> Just as there's more than one monoid over numbers, and more than one monoid over Boolean values, there's more than one monoid over Maybe values. The most useful one may be the one that elevates any semigroup to a monoid by adding <em>nothing</em> as the identity, but others exist. While, at first glance, the <em>first</em > and <em>last</em> monoids over Maybes look like operations in their own right, they're just applications of the general rule. They elevate the <em>first</em> and <em>last</em> semigroups to monoids by 'wrapping' them in Maybes, and using <em>nothing</em> as the identity. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">Monoids accumulate</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. The Maybe functor http://blog.ploeh.dk/2018/03/26/the-maybe-functor 2018-03-26T05:19:00+00:00 Mark Seemann <div id="post"> <p> <em>A introduction to the Maybe functor for object-oriented programmers.</em> </p> <p> This article is an instalment in <a href="http://blog.ploeh.dk/2018/03/22/functors">an article series about functors</a>. </p> <p> One of the simplest, and easiest to understand, functors is <em>Maybe</em>. It's also sometimes known as the <em>Maybe monad</em>, but this is not a monad tutorial; it's a functor tutorial. Maybe is many things; one of them is a functor. In <a href="http://fsharp.org">F#</a>, Maybe is called <code>option</code>. </p> <h3 id="e9a74dc1e498466a9f8bf63224867176"> Motivation <a href="#e9a74dc1e498466a9f8bf63224867176" title="permalink">#</a> </h3> <p> Maybe enables you to model a value that may or may not be present. Object-oriented programmers typically have a hard time grasping the significance of Maybe, since it essentially does the same as <em>null</em> in mainstream object-oriented languages. There are differences, however. In languages like C# and Java, most things can be null, which can lead to much <a href="http://blog.ploeh.dk/2013/07/08/defensive-coding">defensive coding</a>. What happens more frequently, though, is that programmers forget to check for null, with run-time exceptions as the result. </p> <p> A Maybe value, on the other hand, makes it explicit that a value may or may not be present. In statically typed languages, it also forces you to deal with the case where no data is present; if you don't, your code will not compile. </p> <p> Finally, in a language like C#, <a href="http://blog.ploeh.dk/2015/11/13/null-has-no-type-but-maybe-has">null has no type</a>, but a Maybe value always has a type. </p> <p> If you appreciate the tenet that <a href="https://www.python.org/dev/peps/pep-0020">explicit is better than implicit</a>, then you should favour Maybe over null. </p> <h3 id="09da3571d64a4a77b94ffccacd59e3ed"> Implementation <a href="#09da3571d64a4a77b94ffccacd59e3ed" title="permalink">#</a> </h3> <p> If you've read <a href="http://blog.ploeh.dk/2018/03/22/functors">the introduction</a>, then you know that <code>IEnumerable&lt;T&gt;</code> is a functor. In many ways, Maybe is like <code>IEnumerable&lt;T&gt;</code>, but it's a particular type of collection that can only contain zero or one element(s). There are various ways in which you can implement Maybe in an object-oriented language like C#; here's one: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">internal</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;HasItem&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">internal</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Item&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Maybe() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.HasItem&nbsp;=&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Maybe(<span style="color:#2b91af;">T</span>&nbsp;item) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(item&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(item)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.HasItem&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Item&nbsp;=&nbsp;item; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;Select&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;selector) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(selector&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(selector)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(<span style="color:blue;">this</span>.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;(selector(<span style="color:blue;">this</span>.Item)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;GetValueOrFallback(<span style="color:#2b91af;">T</span>&nbsp;fallbackValue) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(fallbackValue&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(fallbackValue)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(<span style="color:blue;">this</span>.HasItem) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Item; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;fallbackValue; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;Equals(<span style="color:blue;">object</span>&nbsp;obj) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;other&nbsp;=&nbsp;obj&nbsp;<span style="color:blue;">as</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:#2b91af;">T</span>&gt;; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(other&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">object</span>.Equals(<span style="color:blue;">this</span>.Item,&nbsp;other.Item); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">int</span>&nbsp;GetHashCode() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.HasItem&nbsp;?&nbsp;<span style="color:blue;">this</span>.Item.GetHashCode()&nbsp;:&nbsp;0; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This is a generic class with two constructors. The parameterless constructor indicates the case where no value is present, whereas the other constructor overload indicates the case where exactly one value is available. Notice that a guard clause prevents you from accidentally passing null as a value. </p> <p> The <code>Select</code> method has the correct signature for a functor. If a value is present, it uses the <code>selector</code> method argument to map <code>item</code> to a new value, and return a new <code>Maybe&lt;TResult&gt;</code> value. If no value is available, then a new empty <code>Maybe&lt;TResult&gt;</code> value is returned. </p> <p> This class also override <code>Equals</code>. This isn't necessary in order for it to be a functor, but it makes it easier to compare two <code>Maybe&lt;T&gt;</code> values. </p> <p> A common question about such generic <a href="https://bartoszmilewski.com/2014/01/14/functors-are-containers">containers</a> is: <em>how do you get the value out of the container?</em> </p> <p> The answer depends on the particular container, but in this example, I decided to enable that functionality with the <code>GetValueOrFallback</code> method. The only way to get the item out of a <code>Maybe</code> value is by supplying a fall-back value that can be used if no value is available. This is one way to guarantee that you, as a client developer, always remember to deal with the empty case. </p> <h3 id="b95ee3d38a35472c949b3cea4c5b0216"> Usage <a href="#b95ee3d38a35472c949b3cea4c5b0216" title="permalink">#</a> </h3> <p> It's easy to use this <code>Maybe</code> class: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;source&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">int</span>&gt;(42); </pre> </p> <p> This creates a new <code>Maybe&lt;int&gt;</code> object that contains the value <code>42</code>. If you need to change the value inside the object, you can, for example, do this: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;dest&nbsp;=&nbsp;source.Select(x&nbsp;=&gt;&nbsp;x.ToString()); </pre> </p> <p> Since C# natively understands functors through its query syntax, you could also have written the above translation like this: </p> <p> <pre><span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;&nbsp;dest&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;x&nbsp;<span style="color:blue;">in</span>&nbsp;source &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;x.ToString();</pre> </p> <p> It's up to you and your collaborators whether you prefer one or the other of those alternatives. In both examples, though, <code>dest</code> is a new populated <code>Maybe&lt;string&gt;</code> object containing the string <code>"42"</code>. </p> <p> A more realistic example could be as part of a line-of-business application. Many <a href="http://blog.ploeh.dk/2012/12/18/RangersandZookeepers">enterprise developers</a> are familiar with the <a href="https://martinfowler.com/eaaCatalog/repository.html">Repository pattern</a>. Imagine that you'd like to query a repository for a <code>Reservation</code> object. If one is found in the database, you'd like to convert it to a view model, so that you can display it. </p> <p> <pre><span style="color:blue;">var</span>&nbsp;viewModel&nbsp;=&nbsp;repository.Read(id) &nbsp;&nbsp;&nbsp;&nbsp;.Select(r&nbsp;=&gt;&nbsp;r.ToViewModel()) &nbsp;&nbsp;&nbsp;&nbsp;.GetValueOrFallback(<span style="color:#2b91af;">ReservationViewModel</span>.Null);</pre> </p> <p> The repository's <code>Read</code> method returns <code>Maybe&lt;Reservation&gt;</code>, indicating that it's possible that no object is returned. This will happen if you're querying the repository for an <code>id</code> that doesn't exist in the underlying database. </p> <p> While you can translate the (potential) <code>Reservation</code> object to a view model (using the <code>ToViewModel</code> extension method), you'll have to supply a default view model to handle the case when the reservation wasn't found. </p> <p> <code>ReservationViewModel.Null</code> is a static read-only class field implementing the <a href="https://en.wikipedia.org/wiki/Null_Object_pattern">Null Object pattern</a>. Here, it's used for the fall-back value, in case no object was returned from the repository. </p> <p> Notice that while you need a fall-back value at the end of your <a href="https://martinfowler.com/bliki/FluentInterface.html">fluent interface</a> pipeline, you don't need fall-back values for any intermediate steps. Specifically, you don't need a Null Object implementation for your domain model (<code>Reservation</code>). Furthermore, no defensive coding is required, because <code>Maybe&lt;T&gt;</code> guarantees that the object passed to <code>selector</code> is never <code>null</code>. </p> <h3 id="e5b5aead20eb4f62947a5e0b100b1beb"> First functor law <a href="#e5b5aead20eb4f62947a5e0b100b1beb" title="permalink">#</a> </h3> <p> A <code>Select</code> method with the right signature isn't enough to be a functor. It must also obey the functor laws. Maybe obeys both laws, which you can demonstrate with a few examples. Here's some test cases for a populated Maybe: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;foo&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;bar&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;corge&quot;</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;antidisestablishmentarianism&quot;</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;PopulatedMaybeObeysFirstFunctorLaw(<span style="color:blue;">string</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;id&nbsp;=&nbsp;x&nbsp;=&gt;&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(m,&nbsp;m.Select(id)); }</pre> </p> <p> This parametrised unit test uses <a href="https://xunit.github.io">xUnit.net</a> to demonstrate that a populated Maybe value doesn't change when translated with the local <code>id</code> function, since <code>id</code> returns the input unchanged. </p> <p> The first functor law holds for an empty Maybe as well: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;EmptyMaybeObeysFirstFunctorLaw() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;id&nbsp;=&nbsp;x&nbsp;=&gt;&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(m,&nbsp;m.Select(id)); }</pre> </p> <p> When a Maybe starts empty, translating it with <code>id</code> doesn't change that it's empty. It's worth noting, however, that the original and the translated objects are considered equal because <code>Maybe&lt;T&gt;</code> overrides <code>Equals</code>. Even in the case of the empty Maybe, the value returned by <code>Select(id)</code> is a new object, with a memory address different from the original value. </p> <h3 id="1f17f61c26f9481aa3eea8d033ed3afc"> Second functor law <a href="#1f17f61c26f9481aa3eea8d033ed3afc" title="permalink">#</a> </h3> <p> You can also demonstrate the second functor law with some examples, starting with some test cases for the populated case: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;&quot;</span>,&nbsp;<span style="color:blue;">true</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;foo&quot;</span>,&nbsp;<span style="color:blue;">false</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;bar&quot;</span>,&nbsp;<span style="color:blue;">false</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;corge&quot;</span>,&nbsp;<span style="color:blue;">false</span>)] [<span style="color:#2b91af;">InlineData</span>(<span style="color:#a31515;">&quot;antidisestablishmentarianism&quot;</span>,&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;PopulatedMaybeObeysSecondFunctorLaw(<span style="color:blue;">string</span>&nbsp;value,&nbsp;<span style="color:blue;">bool</span>&nbsp;expected) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;g&nbsp;=&nbsp;s&nbsp;=&gt;&nbsp;s.Length; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">bool</span>&gt;&nbsp;&nbsp;&nbsp;f&nbsp;=&nbsp;i&nbsp;=&gt;&nbsp;i&nbsp;%&nbsp;2&nbsp;==&nbsp;0; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(m.Select(g).Select(f),&nbsp;m.Select(s&nbsp;=&gt;&nbsp;f(g(s)))); }</pre> </p> <p> In this parametrised test, <code>f</code> and <code>g</code> are two local functions. <code>g</code> returns the length of a string (for example, the length of <em>antidisestablishmentarianism</em> is <em>28</em>). <code>f</code> evaluates whether or not a number is even. </p> <p> Whether you decide to first translate <code>m</code> with <code>g</code>, and then translate the return value with <code>f</code>, or you decide to translate the composition of those functions in a single <code>Select</code> method call, the result should be the same. </p> <p> The second functor law holds for the empty case as well: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;EmptyMaybeObeysSecondFunctorLaw() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;g&nbsp;=&nbsp;s&nbsp;=&gt;&nbsp;s.Length; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">bool</span>&gt;&nbsp;&nbsp;&nbsp;f&nbsp;=&nbsp;i&nbsp;=&gt;&nbsp;i&nbsp;%&nbsp;2&nbsp;==&nbsp;0; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;m&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Maybe</span>&lt;<span style="color:blue;">string</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(m.Select(g).Select(f),&nbsp;m.Select(s&nbsp;=&gt;&nbsp;f(g(s)))); }</pre> </p> <p> Since <code>m</code> is empty, applying the translations doesn't change that fact - it only changes the type of the resulting object, which is an empty <code>Maybe&lt;bool&gt;</code>. </p> <h3 id="9468d48e71ea45c8b17540919be78b0f"> Haskell <a href="#9468d48e71ea45c8b17540919be78b0f" title="permalink">#</a> </h3> <p> In <a href="https://www.haskell.org">Haskell</a>, Maybe is built in. You can create a <code>Maybe</code> value containing an integer like this (the type annotations are optional): </p> <p> <pre><span style="color:#600277;">source</span>&nbsp;::&nbsp;Maybe&nbsp;Int source&nbsp;<span style="color:#666666;">=</span>&nbsp;Just&nbsp;<span style="color:#09885a;">42</span></pre> </pre> </p> <p> Mapping <code>source</code> to a <code>String</code> can be done like this: </p> <p> <pre><span style="color:#600277;">dest</span>&nbsp;::&nbsp;Maybe&nbsp;String dest&nbsp;<span style="color:#666666;">=</span>&nbsp;fmap&nbsp;show&nbsp;source</pre> </p> <p> The function <code>fmap</code> corresponds to the above C# <code>Select</code> method. </p> <p> It's also possible to use infix notation: </p> <p> <pre><span style="color:#600277;">dest</span>&nbsp;::&nbsp;Maybe&nbsp;String dest&nbsp;<span style="color:#666666;">=</span>&nbsp;show&nbsp;<span style="color:#666666;">&lt;$&gt;</span>&nbsp;source</pre> </p> <p> The <code>&lt;$&gt;</code> operator is an alias for <code>fmap</code>. </p> <p> Whether you use <code>fmap</code> or <code>&lt;$&gt;</code>, the resulting <code>dest</code> value is <code>Just "42"</code>. </p> <p> If you want to create an empty <code>Maybe</code> value, you use the <code>Nothing</code> data constructor. </p> <h3 id="76073b1acf7f4b9ab72f873738dec4f4"> F# <a href="#76073b1acf7f4b9ab72f873738dec4f4" title="permalink">#</a> </h3> <p> Maybe is also a built-in type in F#, but here it's called <code>option</code> instead of <code>Maybe</code>. You create an option containing an integer like this: </p> <p> <pre><span style="color:green;">//&nbsp;int&nbsp;option</span> <span style="color:blue;">let</span>&nbsp;source&nbsp;=&nbsp;<span style="color:navy;">Some</span>&nbsp;42</pre> </p> <p> While the case where a value is present was denoted with <code>Just</code> in Haskell, in F# it's called <code>Some</code>. </p> <p> You can translate option values using the <code>map</code> function from the <code>Option</code> module: </p> <p> <pre><span style="color:green;">//&nbsp;string&nbsp;option</span> <span style="color:blue;">let</span>&nbsp;dest&nbsp;=&nbsp;source&nbsp;|&gt;&nbsp;<span style="color:teal;">Option</span>.<span style="color:navy;">map</span>&nbsp;<span style="color:navy;">string</span></pre> </p> <p> Finally, if you want to create an empty <code>option</code> value, you can use the <code>None</code> case constructor. </p> <h3 id="5c14e63d3b50485f8252718eae911d04"> Summary <a href="#5c14e63d3b50485f8252718eae911d04" title="permalink">#</a> </h3> <p> Together with a functor called <em>Either</em>, Maybe is one of the workhorses of statically typed functional programming. You aren't going to write much F# or Haskell before you run into it. In C# I've used variations of the above <code>Maybe&lt;T&gt;</code> class for years, with much success. </p> <p> In this article, I only discussed Maybe in its role of being a functor, but it's so much more than that! It's also an applicative functor, a monad, and traversable (enumerable). Not all functors are that rich. </p> <p> <strong>Next:</strong> Tree. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Functors http://blog.ploeh.dk/2018/03/22/functors 2018-03-22T16:57:00+00:00 Mark Seemann <div id="post"> <p> <em>A functor is a common abstraction. While typically associated with functional programming, functors exist in C# as well.</em> </p> <p> This article series is part of <a href="http://blog.ploeh.dk/2018/03/19/functors-applicatives-and-friends">a larger series of articles about functors, applicatives, and other mappable containers</a>. </p> <p> Programming is about abstraction, since you can't manipulate individual sub-atomic particles on your circuit boards. Some abstractions are well-known because they're rooted in mathematics. Particularly, <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a> has proven to be fertile ground for functional programming. Some of the concepts from category theory apply to object-oriented programming as well; all you need is generics, which is a feature of both C# and Java. </p> <p> In previous articles, you got an introduction to the specific <a href="http://blog.ploeh.dk/2017/08/14/from-test-data-builders-to-the-identity-functor">Test Data Builder</a> and <a href="http://blog.ploeh.dk/2017/09/18/the-test-data-generator-functor">Test Data Generator</a> functors. Functors are more common than you may realise, although in programming, we usually work with a subset of functors called <em>endofunctors</em>. In daily speak, however, we just call them <em>functors</em>. </p> <p> In the next series of articles, you'll see plenty of examples of functors, with code examples in both C#, F#, and Haskell. These articles are mostly aimed at object-oriented programmers curious about the concept. <ul> <li><a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a></li> <li>Tree</li> <li>Visitor</li> <li>Observable</li> </ul> This list is far from exhaustive; more functors exist. Perhaps the most well-known of all functors is List, a.k.a. Sequence. C# query syntax can handle any functor, but most people only think of it as a language feature related to <code>IEnumerable&lt;T&gt;</code>. Since the combination of <code>IEnumerable&lt;T&gt;</code> and query syntax is already well-described, I'm not going to cover it explicitly here. </p> <p> If you understand how LINQ, <code>IEnumerable&lt;T&gt;</code>, and C# query syntax works, however, all other functors should feel intuitive. That's the power of abstractions. </p> <h3 id="3053c67ef9dd4d21bd68ccc1ddbd208a"> Overview <a href="#3053c67ef9dd4d21bd68ccc1ddbd208a" title="permalink">#</a> </h3> <p> The purpose of this article isn't to give you a comprehensive introduction to the category theory of functors. Rather, the purpose is to give you an opportunity to learn how it translates to object-oriented code like C#. For a great introduction to functors, see <a href="https://bartoszmilewski.com">Bartosz Milewski</a>'s <a href="https://bartoszmilewski.com/2015/01/20/functors">explanation with illustrations</a>. </p> <p> In short, a functor is a mapping between two categories. A functor maps not only objects, but also functions (called <em>morphisms</em>) between objects. For instance, a functor <em>F</em> may be a mapping between the categories <em>C</em> and <em>D</em>: </p> <p> <img src="/content/binary/functor-diagram.png" alt="Functor diagram."> </p> <p> Not only does <em>F</em> map <em>a</em> from <em>C</em> to <em>F a</em> in <em>D</em> (and likewise for <em>b</em>), it also maps the function <em>f</em> to <em>F f</em>. Functors preserve the structure between objects. You'll often hear the phrase that a functor is a <em>structure-preserving map</em>. One example of this regards lists. You can translate a <code>List&lt;int&gt;</code> to a <code>List&lt;string&gt;</code>, but the translation preserves the structure. This means that the resulting object is also a list, and the order of values within the lists doesn't change. </p> <p> In category theory, categories are often named <em>C</em>, <em>D</em>, and so on, but an example of a category could be <code>IEnumerable&lt;T&gt;</code>. If you have a function that translates integers to strings, the source <em>object</em> (that's what it's called, but it's not the same as an OOP object) could be <code>IEnumerable&lt;int&gt;</code>, and the destination object could be <code>IEnumerable&lt;string&gt;</code>. A functor, then, represents the ability to go from <code>IEnumerable&lt;int&gt;</code> to <code>IEnumerable&lt;string&gt;</code>, and since the <a href="https://msdn.microsoft.com/en-us/library/bb548891">Select</a> method gives you that ability, <code>IEnumerable&lt;T&gt;.Select</code> is a functor. In this case, you sort of 'stay within' the category of <code>IEnumerable&lt;T&gt;</code>, only you change the generic type argument, so this functor is really an endofunctor (the <em>endo</em> prefix is from Greek, meaning <em>within</em>). </p> <p> As a rule of thumb, if you have a type with a generic type argument, it's a candidate to be a functor. Such a type is not always a functor, because it also depends on where the generic type argument appears, and some other rules. </p> <p> Fundamentally, you must be able to implement a method for your generic type that looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;Select&lt;<span style="color:#2b91af;">TResult</span>&gt;(<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">TResult</span>&gt;&nbsp;selector) </pre> </p> <p> Here, I've defined the <code>Select</code> method as an instance method on a class called <code>Functor&lt;T&gt;</code>, but often, as is the case with <code>IEnumerable&lt;T&gt;</code>, the method is instead implemented as an extension method. You don't have to name it <code>Select</code>, but doing so enables query syntax in C#: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;dest&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;x&nbsp;<span style="color:blue;">in</span>&nbsp;source &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;x.ToString();</pre> </p> <p> Here, <code>source</code> is a <code>Functor&lt;int&gt;</code> object. </p> <p> If you don't name the method <code>Select</code>, it could still be a functor, but then query syntax wouldn't work. Instead, normal method-call syntax would be your only option. This is, however, a specific C# language feature. F#, for example, has no particular built-in awareness of functors, although most libraries name the central function <code>map</code>. In Haskell, <code>Functor</code> is a typeclass that defines a function called <code>fmap</code>. </p> <p> The common trait is that there's an input value (<code>Functor&lt;T&gt;</code> in the above C# code snippet), which, when combined with a mapping function (<code>Func&lt;T, TResult&gt;</code>), returns an output value of the same generic type, but with a different generic type argument (<code>Functor&lt;TResult&gt;</code>). </p> <h3 id="314a59e80ab4476381e0ed3205d35491"> Laws <a href="#314a59e80ab4476381e0ed3205d35491" title="permalink">#</a> </h3> <p> Defining a <code>Select</code> method isn't enough. The method must also obey the so-called <em>functor laws</em>. These are quite intuitive laws that govern that a functor behaves correctly. </p> <p> The first law is that mapping the identity function returns the functor unchanged. The <em>identity function</em> is a function that returns all input unchanged. (It's called the <em>identity function</em> because it's the <em>identity</em> for the <a href="http://blog.ploeh.dk/2017/11/13/endomorphism-monoid">endomorphism monoid</a>.) In F# and Haskell, this is simply a built-in function called <code>id</code>. </p> <p> In C#, you can write a demonstration of the law as a unit test: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(-101)] [<span style="color:#2b91af;">InlineData</span>(-1)] [<span style="color:#2b91af;">InlineData</span>(0)] [<span style="color:#2b91af;">InlineData</span>(1)] [<span style="color:#2b91af;">InlineData</span>(42)] [<span style="color:#2b91af;">InlineData</span>(1337)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;FunctorObeysFirstFunctorLaw(<span style="color:blue;">int</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;id&nbsp;=&nbsp;x&nbsp;=&gt;&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:blue;">int</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(sut,&nbsp;sut.Select(id)); }</pre> </p> <p> While this doesn't <em>prove</em> that the first law holds for all values and all generic type arguments, it illustrates what's going on. </p> <p> Since C# doesn't have a built-in identity function, the test creates a specialised identity function for integers, and calls it <code>id</code>. It simply returns all input values unchanged. Since <code>id</code> doesn't change the value, then <code>Select(id)</code> shouldn't change the functor, either. There's nothing more to the first law than this. </p> <p> The second law states that if you have two functions, <code>f</code> and <code>g</code>, then mapping over one after the other should be the same as mapping over the composition of <code>f</code> and <code>g</code>. In C#, you can illustrate it like this: </p> <p> <pre>[<span style="color:#2b91af;">Theory</span>] [<span style="color:#2b91af;">InlineData</span>(-101)] [<span style="color:#2b91af;">InlineData</span>(-1)] [<span style="color:#2b91af;">InlineData</span>(0)] [<span style="color:#2b91af;">InlineData</span>(1)] [<span style="color:#2b91af;">InlineData</span>(42)] [<span style="color:#2b91af;">InlineData</span>(1337)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;FunctorObeysSecondFunctorLaw(<span style="color:blue;">int</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;&nbsp;&nbsp;&nbsp;g&nbsp;=&nbsp;i&nbsp;=&gt;&nbsp;i.ToString(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">string</span>,&nbsp;<span style="color:blue;">string</span>&gt;&nbsp;f&nbsp;=&nbsp;s&nbsp;=&gt;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:blue;">string</span>(s.Reverse().ToArray()); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;sut&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Functor</span>&lt;<span style="color:blue;">int</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(sut.Select(g).Select(f),&nbsp;sut.Select(i&nbsp;=&gt;&nbsp;f(g(i)))); }</pre> </p> <p> Here, <code>g</code> is a function that translates an <code>int</code> to a <code>string</code>, and <code>f</code> reverses a string. Since <code>g</code> returns <code>string</code>, you can compose it with <code>f</code>, which takes <code>string</code> as input. </p> <p> As the assertion points out, it shouldn't matter if you call <code>Select</code> piecemeal, first with <code>g</code> and then with <code>f</code>, or if you call <code>Select</code> with the composed function <code>f(g(i))</code>. </p> <h3 id="eb061f6fdd094731a1c52850eec7feac"> Summary <a href="#eb061f6fdd094731a1c52850eec7feac" title="permalink">#</a> </h3> <p> This is not a monad tutorial; it's a functor tutorial. Functors are commonplace, so it's worth keeping an eye out for them. If you already understand how LINQ (or similar concepts in Java) work, then functors should be intuitive, because they are all based on the same underlying maths. </p> <p> While this article is an overview article, it's also a part of <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">a larger series of articles</a> that explore what object-oriented programmers can learn from category theory. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Functors, applicatives, and friends http://blog.ploeh.dk/2018/03/19/functors-applicatives-and-friends 2018-03-19T08:35:00+00:00 Mark Seemann <div id="post"> <p> <em>Functors and related data structures are containers of values. It's a family of abstractions. An overview for object-oriented programmers.</em> </p> <p> This article series is part of <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">an even larger series of articles about the relationship between design patterns and category theory.</a> </p> <p> If you've worked with C# or Java recently, you've most likely encountered types such as <code>Foo&lt;T&gt;</code> or <code>Bar&lt;T&gt;</code> (specifically, on .NET, e.g. <a href="https://msdn.microsoft.com/en-us/library/6sh2ey19">List&lt;T&gt;</a>). Perhaps you've also noticed that often, you can translate the type inside of <a href="https://bartoszmilewski.com/2014/01/14/functors-are-containers">the container</a>. For example, if you have a <code>Foo&lt;string&gt;</code>, perhaps you can call some method on it that returns a <code>Foo&lt;int&gt;</code>. If so, it may be a <em>functor</em>. </p> <p> Not all generic types are functors. In order to be a functor, a generic type must obey a couple of intuitive laws. You'll learn about those in future articles. </p> <p> Some functors have extra capabilities, and you'll learn about some of those as well. Some are called <em>applicative functors</em>, and some are called <em>bifunctors</em>. There are others, as well. </p> <p> <img src="/content/binary/functors-applicatives-bifunctors.png" alt="Functors, applicative functors, and bifunctors as subsets of each other."> </p> <p> All applicative functors are functors, and this is true for bifunctors as well. </p> <p> In this article series, you'll learn about the following categories: <ul> <li><a href="http://blog.ploeh.dk/2018/03/22/functors">Functors</a> <ul> <li><a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a></li> <li>Tree</li> <li>Visitor</li> <li>Observable</li> </ul> </li> <li>Applicative functors <ul> <li>Deck of cards</li> <li>Guess a password</li> <li>Applicative sequences as combinations</li> <li>Maybe</li> <li>Validation</li> <li>Test Data Generator</li> <li>Danish CPR numbers in F#</li> </ul> </li> <li>Bifunctors <ul> <li>Tuple bifunctor</li> <li>Either bifunctor</li> </ul> </li> </ul> You'll see plenty of examples along the way. Most examples will be in C#, but some articles will have code examples in <a href="http://fsharp.org">F#</a> or <a href="https://www.haskell.org">Haskell</a>. You can read or skip those articles as you prefer. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/03/22/functors">Functors</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Composite as a monoid http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid 2018-03-12T09:39:00+00:00 Mark Seemann <div id="post"> <p> <em>When can you use the Composite design pattern? When the return types of your methods are monoids.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions/">a series of articles about design patterns and their universal abstraction counterparts</a>. </p> <p> The <a href="https://en.wikipedia.org/wiki/Composite_pattern">Composite</a> design pattern is a powerful way to structure code, but not all objects are composable. When is an object composable? This article explores that question. </p> <p> In short, Composites are <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>. </p> <p> <img src="/content/binary/composite-as-subset-of-monoid.png" alt="Composite shown as a subset of the set of monoids."> </p> <p> Not all monoids are Composites, but as far as I can tell, all Composites are monoids. </p> <h3 id="ab8f3501700042419375b91315249a77"> Composite <a href="#ab8f3501700042419375b91315249a77" title="permalink">#</a> </h3> <p> First, I'll use various <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">software design isomorphisms</a> to put Composite in a canonical form. From <a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">unit isomorphisms</a>, <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">function isomorphisms</a>, and <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">argument list isomorphisms</a>, we know that we can represent any method as a method or function that takes a single argument, and returns a single output value. From <a href="http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism">abstract class isomorphism</a> we know that we can represent an abstract class with interfaces. Thus, you can represent the interface for a Composite like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IInterface1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">In2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">In3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;operations...</span> }</pre> </p> <p> In order to create a Composite, we must be able to take an arbitrary number of implementations and make them look like a single object. </p> <h3 id="30b860e1b0904901a41b1ead2424a74d"> Composite as monoid <a href="#30b860e1b0904901a41b1ead2424a74d" title="permalink">#</a> </h3> <p> You have a set of implementations of <code>IInterface1</code>. In order to create a Composite, you loop over all of those implementations in order to produce an aggregated result. Imagine that you have to implement a <code>CompositeInterface1</code> class that composes <code>imps</code>, an <code>IReadOnlyCollection&lt;IInterface1&gt;</code>. In order to implement <code>Op1</code>, you'd have to write code like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;imp&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.imps) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;out1&nbsp;=&nbsp;imp.Op1(arg); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Somehow&nbsp;combine&nbsp;this&nbsp;out1&nbsp;value&nbsp;with&nbsp;previous&nbsp;values</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Return&nbsp;combined&nbsp;Out1&nbsp;value</span> }</pre> </p> <p> This implies that we have an ordered, finite sequence of implementations: <em>imp1, imp2, imp3, ...</em>. In C#, we could represent such a sequence with the type <code>IReadOnlyCollection&lt;IInterface1&gt;</code>. Somehow, we need to turn that collection into a single <code>IInterface1</code> value. In other words, we need a translation of the type <code>IReadOnlyCollection&lt;IInterface1&gt; -&gt; IInterface1</code>. </p> <p> If we look to <a href="https://www.haskell.org">Haskell</a> for inspiration for a moment, let's replace <code>IReadOnlyCollection&lt;T&gt;</code> with Haskell's built-in linked list. This means that we need a function of the type <code>[IInterface1] -&gt; IInterface1</code>, or, more generally, <code>[a] -&gt; a</code>. This function exists for all <code>a</code> as long as <code>a</code> forms a monoid; it's called <code>mconcat</code>: </p> <p> <pre>mconcat :: Monoid a =&gt; [a] -&gt; a</pre> </p> <p> We also know from a previous article that <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">a collection of monoids can be reduced to a single monoid</a>. Notice how the above outline of a composite implementation of <code>Op1</code> looks similar to the <code>Accumulate</code> method shown in the linked article. If <code>IInterface1</code> can form a monoid, then you can make a Composite. </p> <h3 id="79bbc5e304734bb180724a77929e23b6"> Objects as monoids <a href="#79bbc5e304734bb180724a77929e23b6" title="permalink">#</a> </h3> <p> When can an object (like <code>IInterface1</code>) form a monoid? </p> <p> From <a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">object isomorphisms</a> we know that we can decompose an object with <em>n</em> members to <em>n</em> static methods. This means that instead of analysing all of <code>IInterface1</code>, we can consider the properties of each method in isolation. The properties of an object is the consolidation of the properties of all the methods. </p> <p> Recall, still from <em>object isomorphisms</em>, that we can represent an object as a tuple of functions. Moreover, <a href="http://blog.ploeh.dk/2017/10/30/tuple-monoids">if you have a tuple of monoids, then the tuple also forms monoid</a>! </p> <p> In order to make an object a monoid, then, you have to make each method a monoid. When is a method a monoid? <a href="http://blog.ploeh.dk/2017/11/06/function-monoids">A method is a monoid when its return type forms a monoid</a>. </p> <p> That's it. An interface like <code>IInterface1</code> is a monoid when <code>Out1</code>, <code>Out2</code>, <code>Out3</code>, and so on, form monoids. If that's the case, you can make a Composite. </p> <h3 id="75ca550ef1ef42b3a559bece1ff6b52d"> Examples <a href="#75ca550ef1ef42b3a559bece1ff6b52d" title="permalink">#</a> </h3> <p> From <em>unit isomorphism</em>, we know that we can represent C#'s and Java's <em>void</em> keywords with methods returning <em>unit</em>, and <em>unit</em> is a monoid. All methods that return <code>void</code> can be part of a Composite, but we already knew that <a href="http://blog.ploeh.dk/2011/03/22/CommandsareComposable">Commands are composable</a>. If you search for examples of the Composite design pattern, you'll find more than one variation involving drawing shapes on a digital canvas, with the central operation being a <code>Draw</code> method with a <code>void</code> return type. </p> <p> Another example could be calculation of the price of a shopping basket. If you have an interface method of the type <code>decimal Calculate(Basket basket)</code>, you could have several implementations: <ul> <li>Add all the item prices together</li> <li>Apply a discount (a negative number)</li> <li>Calculate sales tax</li> </ul> These could be three implementations of the same interface method, and since decimal numbers form a monoid over addition, then you can make a Composite basket calculator out of the three implementations. For a detailed example, see the <a href="http://blog.ploeh.dk/2018/05/17/composite-as-a-monoid-a-business-rules-example">coda containing a business rules example</a>. </p> <p> Boolean values also form at least two monoids (<em>any</em> and <em>all</em>), so any method you have that returns a Boolean value can be used in a Composite. You could, for example, have a list of criteria for granting a loan. Each such business rule returns <code>true</code> if it evaluates that the loan should be granted, and <code>false</code> otherwise. If you have more than one business rule, you can create a Composite that returns <code>true</code> only if all the individual rules return <code>true</code>. </p> <p> If you have a method that returns a string, then that is also a candidate for inclusion in a Composite, if string concatenation makes sense in the domain in question. </p> <p> You probably find it fairly mundane that you can create a Composite if all the methods involved return numbers, strings, Booleans, or nothing. The result generalises, however, to all monoids, including more complex types, including methods that return other interfaces that themselves form monoids, and so on recursively. </p> <h3 id="3d21d64a1ec64432abd38ebcd09332a6"> Granularity <a href="#3d21d64a1ec64432abd38ebcd09332a6" title="permalink">#</a> </h3> <p> The result, then, is that you can make a Composite when <em>all</em> methods in your interface have monoidal return types. If only a single method has a return type that isn't a monoid, you can't aggregate that value, and you can't make a Composite. </p> <p> Your interface can have as many methods you like, but they must all be monoids. Even one rogue method will prevent you from being able to create a Composite. This is another argument for <a href="https://martinfowler.com/bliki/RoleInterface.html">Role Interfaces</a>. The smaller an interface is, the more likely it is that you can make a Composite out of it. If you follow that line of reasoning to its ultimate conclusion, you'll <a href="http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional">design your interfaces with a single member each</a>. </p> <h3 id="f98c1cf3efa24c919cc10fba5d672435"> Relaxation <a href="#f98c1cf3efa24c919cc10fba5d672435" title="permalink">#</a> </h3> <p> There can be some exceptions to the rule that all return values must be monoids. If you have at least one implementation of your interface, then a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a> may be enough. Recall that monoids accumulate like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Accumulate(<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Foo</span>&gt;&nbsp;foos) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;Identity; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;f&nbsp;<span style="color:blue;">in</span>&nbsp;foos) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;acc.Op(f); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> You only need <code>Identity</code> in order to start the accumulation, and to have something to return in case you have no implementations. If you have at least one implementation, you don't need the identity, and then <a href="http://blog.ploeh.dk/2017/12/11/semigroups-accumulate">a semigroup is enough to accumulate</a>. Consider the <a href="http://blog.ploeh.dk/2017/12/04/bounding-box-semigroup">bounding box example</a>. If you have a method that returns <code>BoundingBox</code> values, you can still make a Composite out of such an interface, as long as you have at least one implementation. There's no 'identity' bounding box, but it makes intuitive sense that you can still compose bounding boxes into bigger bounding boxes. </p> <p> Haskell formalises the rule for semigroups: </p> <p> <pre>sconcat :: Semigroup a =&gt; Data.List.NonEmpty.NonEmpty a -&gt; a</pre> </p> <p> The <code>sconcat</code> function reduces any non-empty list of any semigroup <code>a</code> to a single <code>a</code> value. </p> <p> If you have a non-empty list of implementations, then perhaps you don't even need a semigroup. Perhaps any <a href="http://blog.ploeh.dk/2017/12/27/magmas">magma</a> will work. Be aware, however, that the lack of associativity will cause the order of implementations to matter. </p> <p> Technically, you may be able to program a Composite from a magma, but I'd suggest caution. The monoid and semigroup laws are intuitive. A magma without those properties may not form an intuitive Composite. While it may compile, it may have surprising, or counter-intuitive, behaviour. I'd favour sticking to monoids or semigroups. </p> <h3 id="b30a2eafacfb4ddf98caec0c2030bf49"> Summary <a href="#b30a2eafacfb4ddf98caec0c2030bf49" title="permalink">#</a> </h3> <p> When is an object-oriented design composable? Composition could mean more than one thing, but this article has focused exclusively on the Composite design pattern. When can you use the Composite pattern? When all method return types are monoids. </p> <p> <strong>Next: </strong> <a href="http://blog.ploeh.dk/2018/04/09/coalescing-composite-as-a-monoid">Coalescing Composite as a monoid</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Some design patterns as universal abstractions http://blog.ploeh.dk/2018/03/05/some-design-patterns-as-universal-abstractions 2018-03-05T08:10:00+00:00 Mark Seemann <div id="post"> <p> <em>Some design patterns can be formalised by fundamental abstractions.</em> </p> <p> This article series submits results based on the work presented in <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">an even larger series of articles about the relationship between design patterns and category theory</a>. </p> <p> Wouldn't it be wonderful if you could assemble software from predefined building blocks? This idea is <em>old</em>, and has been the driving force behind object-oriented programming (OOP). In <a href="https://www.coupland.com">Douglas Coupland</a>'s 1995 novel <a href="http://bit.ly/microserfs">Microserfs</a>, the characters attempt to reach that goal through a project called <em>Oop!</em>. <a href="https://en.wikipedia.org/wiki/Lego">Lego bricks</a> play a role as a metaphor as well. </p> <p> <img src="/content/binary/lego-bricks-as-connections.png" alt="Lego bricks."> </p> <p> Decades later, it doesn't look like we're much nearer that goal than before, but I believe that we'd made at least two (rectifiable) mistakes along the way: <ul> <li>Granularity</li> <li>Object-orientation</li> </ul> While I'm going to discuss both of these briefly, my principal message is one of hope. I still think we can assemble software from predefined 'things', but I believe that these 'things' are small and 'objects' in a different sense than normal. </p> <h3 id="e1bedfebfd5d4292a18a5a2eecf763c9"> Granularity <a href="#e1bedfebfd5d4292a18a5a2eecf763c9" title="permalink">#</a> </h3> <p> Over the years, I've seen several attempts at reducing software development to a matter of putting things together. These attempts have invariably failed. </p> <p> I believe that one of the reasons for failure is that such projects tend to aim at coarse-grained building blocks. As I explain in the <em>Interface Segregation Principle</em> module of my <a href="http://blog.ploeh.dk/encapsulation-and-solid">Encapsulation and SOLID</a> Pluralsight course, granularity is a crucial determinant for your ability to create. The coarser-grained the building blocks, the harder it is to create something useful. </p> <p> Most attempts at software-as-building-blocks have used big, specialised building blocks aimed at non-technical users (<em>"Look! Create an entire web site without writing a single line of code!"</em>). That's just like <a href="https://en.wikipedia.org/wiki/Lego_Duplo">Duplo</a>. You can create exactly what the blocks were designed for, but as soon as you try to create something new and original, you can't. </p> <h3 id="11a18062d294481bb092e2d4c364b4a4"> Object-orientation <a href="#11a18062d294481bb092e2d4c364b4a4" title="permalink">#</a> </h3> <p> OOP is another attempt at software-as-building-blocks. In .NET (the OOP framework with which I'm most familiar) the Base Class Library (BCL) is enormous. Many of the reusable objects in the BCL are fine-grained, so at least it's often possible to put them together to create something useful. The problem with an object-oriented library like the .NET BCL, however, is that all the objects are <em>special</em>. </p> <p> The vision was always that software 'components' would be able to 'click' together, just like Lego bricks. The BCL isn't like that. Typically, objects have nothing in common apart from the useless <code>System.Object</code> base class. There's no system. In order to learn how the BCL works, you have to learn the ins and outs of every single class. </p> <p> Better know a framework. </p> <p> It doesn't help that OOP was never formally defined. Every time you see or hear a discussion about what 'real' object-orientation is, you can be sure that sooner or later, someone will say: "...but that's not what <a href="https://en.wikipedia.org/wiki/Alan_Kay">Alan Kay</a> had in mind." </p> <p> What Alan Kay had in mind is still unclear to me, but it seems safe to say that it wasn't what we have now (C++, Java, C#). </p> <h3 id="58ae1b0666de46d890675b19f525d42d"> Building blocks from category theory <a href="#58ae1b0666de46d890675b19f525d42d" title="permalink">#</a> </h3> <p> While we (me included) have been on an a thirty-odd year long detour around object-orientation, I don't think all is lost. I still believe that a Lego-brick-like system exists for software development, but I think that it's a system that we have to <em>discover</em> instead of invent. </p> <p> As I already covered in the <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">introductory article</a>, <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a> does, in fact, discuss 'objects'. It's not the same type of object that you know from C# or Java, but some of them do consist of data and behaviour - <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>, for example, or <a href="http://blog.ploeh.dk/2018/03/22/functors">functors</a>. Such object are more like types than objects in the OOP sense. </p> <p> Another, more crucial, difference to object-oriented programming is that these objects are lawful. An object is only a monoid if it obeys the monoid laws. An object is only a functor if it obeys the functor laws. </p> <p> Such objects are still fine-grained building blocks, but they fit into a system. You don't have to learn tens of thousands of specific objects in order to get to know a framework. You need to understand the system. You need to understand monoids, functors, applicatives, and a few other universal abstractions (yes: monads too). </p> <p> Many of these universal abstractions were almost discovered by the Gang of Four twenty years ago, but they weren't quite in place then. Much of that has to do with the fact that functional programming didn't seem like a realistic alternative back then, because of hardware limitations. This has all changed to the better. </p> <h3 id="ae905a16cecc41ffb316a9f291ed5d78"> Specific patterns <a href="#ae905a16cecc41ffb316a9f291ed5d78" title="permalink">#</a> </h3> <p> In the <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">introductory article about the relationship between design patterns and category theory</a>, you learned that some design patterns significantly overlap concepts from category theory. In this article series, we'll explore the relationships between some of the classic patterns and category theory. I'm not sure that all the patterns from <a href="http://amzn.to/XBYukB">Design Patterns</a> can be reinterpreted as universal abstractions, but the following subset seems promising: <ul> <li><a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">Composite as a monoid</a> <ul> <li><a href="http://blog.ploeh.dk/2018/04/09/coalescing-composite-as-a-monoid">Coalescing Composite as a monoid</a></li> <li><a href="http://blog.ploeh.dk/2018/04/16/endomorphic-composite-as-a-monoid">Endomorphic Composite as a monoid</a></li> </ul> </li> <li><a href="http://blog.ploeh.dk/2018/04/23/null-object-as-identity">Null Object as identity</a></li> <li><a href="http://blog.ploeh.dk/2018/06/25/visitor-as-a-sum-type">Visitor as a sum type</a></li> </ul> Granted, Null Object is actually not from <em>Design Patterns</em>, but as we shall see, it's a special case of Composite, so it fits well into that group. </p> <h3 id="cecda3b2021848f2b68874c1ae80ce63"> Summary <a href="#cecda3b2021848f2b68874c1ae80ce63" title="permalink">#</a> </h3> <p> Some design patterns closely resemble categorical objects. This article provides an overview, whereas the next articles in the series will dive into specifics. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/03/12/composite-as-a-monoid">Composite as a monoid</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Inheritance-composition isomorphism http://blog.ploeh.dk/2018/02/26/inheritance-composition-isomorphism 2018-02-26T07:24:00+00:00 Mark Seemann <div id="post"> <p> <em>Reuse via inheritance is isomorphic to composition.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. </p> <p> Chapter 1 of <a href="http://amzn.to/XBYukB">Design Patterns</a> admonishes: <blockquote> Favor object composition over class inheritance </blockquote> People sometimes struggle with this, because they use inheritance as a means to achieve reuse. That's not necessary, because you can use object composition instead. </p> <p> In the <a href="http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism">previous article</a>, you learned that an abstract class can be refactored to a concrete class with injected dependencies. </p> <p> Did you you notice that there was an edge case that I didn't cover? </p> <p> I didn't cover it because I think it deserves its own article. The case is when you want to reuse a base class' functionality in a derived class. How do you do that with Dependency Injection? </p> <h3 id="dfaf463837d64ea1918d71ea7ed7d98a"> Calling base <a href="#dfaf463837d64ea1918d71ea7ed7d98a" title="permalink">#</a> </h3> <p> Imagine a virtual method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) </pre> </p> <p> In C#, a method is virtual when explicitly marked with the <code>virtual</code> keyword, whereas this is the default in Java. When you override a virtual method in a derived class, you can still invoke the parent class' implementation: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;baseResult&nbsp;=&nbsp;<span style="color:blue;">base</span>.Virt1(arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value</span> }</pre> </p> <p> When you override a virtual method, you can use the <code>base</code> keyword to invoke the parent implementation of the method that you're overriding. The enables you to reuse the base implementation, while at the same time adding new functionality. </p> <h3 id="842b27b75f9b420ca41e7c40b15b9ad5"> Virtual method as interface <a href="#842b27b75f9b420ca41e7c40b15b9ad5" title="permalink">#</a> </h3> <p> If you perform the refactoring to Dependency Injection shown in the previous article, you now have an interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg); }</pre> </p> <p> as well as a default implementation. In the previous article, I showed an example where a single class implements several 'virtual member interfaces'. In order to make this particular example clearer, however, here you instead see a variation where the default implementation of <code>IVirt1</code> is in a class that only implements that interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultVirt1</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> <code>DefaultVirt1.Virt1</code> corresponds to the original virtual method on the abstract class. How can you 'override' this default implementation, while still make use of it? </p> <h3 id="c2a7f21e019740d59b132b017f7e5822"> From base to composition <a href="#c2a7f21e019740d59b132b017f7e5822" title="permalink">#</a> </h3> <p> You have a default implementation, and instead of replacing all of it, you want to somehow enhance it, but still use the 'base' implementation. Instead of inheritance, you can use composition: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">OverridingVirt1</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;@base&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultVirt1</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this&nbsp;and&nbsp;arg</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;baseResult&nbsp;=&nbsp;@base.Virt1(arg); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> In order to drive home the similarity, I named the class field <code>@base</code>. I couldn't use <code>base</code> as a name, because that's a keyword in C#, but you can use the prefix <code>@</code> in order to use a keyword as a legal C# name. Notice that the body of <code>OverridingVirt1.Virt1</code> is almost identical to the above, inheritance-based overriding method. </p> <p> As a variation, you can inject <code>@base</code> via the constructor of <code>OverridingVirt1</code>, in which case you have a <a href="https://en.wikipedia.org/wiki/Decorator_pattern">Decorator</a>. </p> <h3 id="6425171e658e474cbe2ab0634b5dbb40"> Isomorphism <a href="#6425171e658e474cbe2ab0634b5dbb40" title="permalink">#</a> </h3> <p> If you already have an interface with a 'default implementation', and you want to reuse the default implementation, then you can use object composition as shown above. At its core, it's reminiscent of the Decorator design pattern, but instead of receiving the inner object via its constructor, it creates the object itself. You can, however, also use a Decorator in order to achieve the same effect. This will make your code more flexible, but possibly also more error-prone, because you no longer have any guarantee what the 'base' is. This is where the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Liskov Substitution Principle</a> becomes important, but that's a digression. </p> <p> If you're using the previous <a href="http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism">abstract class isomorphism</a> to refactor to Dependency Injection, you can refactor any use of <code>base</code> to object composition as shown here. </p> <p> This is a special case of <em>Replace Inheritance with Delegation</em> from <a href="http://amzn.to/YPdQDf">Refactoring</a>, which also describes the inverse refactoring <em>Replace Delegation with Inheritance</em>, thereby making these two refactorings an isomorphism. </p> <h3 id="6ce9849ca5744a50afeea686a40f0e71"> Summary <a href="#6ce9849ca5744a50afeea686a40f0e71" title="permalink">#</a> </h3> <p> This article focuses on a particular issue that you may run into if you try to avoid the use of abstract classes. Many programmers use inheritance in order to achieve reuse, but this is in no way necessary. Favour composition over inheritance. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/05/22/church-encoding">Church encoding</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Abstract class isomorphism http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism 2018-02-19T13:10:00+00:00 Mark Seemann <div id="post"> <p> <em>Abstract classes are isomorphic to Dependency Injection.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. </p> <p> The introduction to <a href="http://amzn.to/XBYukB">Design Patterns</a> states: <blockquote> Program to an interface, not an implementation. </blockquote> When I originally read that, I took it quite literally, so I wrote all my C# code using interfaces instead of abstract classes. There are several reasons why, in general, that turns out to be a good idea, but that's not the point of this article. It turns out that it doesn't really matter. </p> <p> If you have an abstract class, you can refactor to an object model composed from interfaces without loss of information. You can also refactor back to an abstract class. These two refactorings are each others' inverses, so together, they form an isomorphism. </p> <p> <img src="/content/binary/abstract-class-to-interfaces-isomorphism.png" alt="Abstract class on the left, concrete class with injected interfaces on the right; arrow between boxes."> </p> <p> When refactoring an abstract class, you extract all its pure virtual members to an interface, each of its virtual members to other interfaces, and inject them into a concrete class. The inverse refactoring involves going back to an abstract class. </p> <p> This is an important result, because upon closer inspection, the Gang of Four didn't have C# or Java interfaces in mind. The book pre-dates both Java and C#, and its examples are mostly in C++. Many of the examples involve abstract classes, but more than ten years of experience has taught me that I can always write a variant that uses C# interfaces. That is, I believe, not a coincidence. </p> <h3 id="d7a0264c0f134c30a15963ee8216e518"> Abstract class <a href="#d7a0264c0f134c30a15963ee8216e518" title="permalink">#</a> </h3> <p> An abstract class in C# has this general shape: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt1</span>&nbsp;PureVirt1(<span style="color:#2b91af;">InPureVirt1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt2</span>&nbsp;PureVirt2(<span style="color:#2b91af;">InPureVirt2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">OutPureVirt3</span>&nbsp;PureVirt3(<span style="color:#2b91af;">InPureVirt3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;pure&nbsp;virtual&nbsp;members...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt2</span>&nbsp;Virt2(<span style="color:#2b91af;">InVirt2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:#2b91af;">OutVirt3</span>&nbsp;Virt3(<span style="color:#2b91af;">InVirt3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutVirt3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;virtual&nbsp;members...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc1</span>&nbsp;Op1(<span style="color:#2b91af;">InConc1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc2</span>&nbsp;Op2(<span style="color:#2b91af;">InConc2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc3</span>&nbsp;Op3(<span style="color:#2b91af;">InConc3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;concrete&nbsp;members...</span> }</pre> </p> <p> Like in <a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">the previous article</a>, I've deliberately kept the naming abstract (but added a more concrete example towards the end). The purpose of this article series is to look at the shape of code, instead of what it does, or why. From <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">argument list isomorphisms</a> we know that we can represent any method as taking a single input value, and returning a single output value. </p> <p> An abstract class can have non-virtual members. In C#, this is the default, whereas in Java, you'd explicitly have to use the <code>final</code> keyword. In the above generalised representation, I've named these non-virtual members <code>Op1</code>, <code>Op2</code>, and so on. </p> <p> An abstract class can also have virtual members. In C#, you must explicitly use the <code>virtual</code> keyword in order to mark a method as overridable, whereas this is the default for Java. In the above representation, I've called these methods <code>Virt1</code>, <code>Virt2</code>, etcetera. </p> <p> Some virtual members are <em>pure virtual</em> members. These are members without an implementation. Any concrete (that is: non-abstract) class inheriting from an abstract class must provide an implementation for such members. In both C# and Java, you must declare such members using the <code>abstract</code> keyword. In the above representation, I've called these methods <code>PureVirt1</code>, <code>PureVirt2</code>, and so on. </p> <p> Finally, an abstract class can contain data, which you can represent as a single data object, here of the type <code>Data1</code>. </p> <p> The concrete and virtual members could, conceivably, call other members in the class - both concrete, virtual, and pure virtual. In fact, this is how many of the design patterns in the book work, for example <a href="https://en.wikipedia.org/wiki/Strategy_pattern">Strategy</a>, <a href="https://en.wikipedia.org/wiki/Template_method_pattern">Template Method</a>, and <a href="https://en.wikipedia.org/wiki/Builder_pattern">Builder</a>. </p> <h3 id="b22dc0035a4c44948369c7cda63646ad"> From abstract class to Dependency Injection <a href="#b22dc0035a4c44948369c7cda63646ad" title="permalink">#</a> </h3> <p> Apart from its <code>Data</code>, an abstract class contains three types of members: <ul> <li>Those that <em>must</em> be implemented by derived classes: pure virtual members</li> <li>Those that <em>optionally</em> can be overriden by derived classes: virtual members</li> <li>Those that cannot be overridden by derived classes: concrete, sealed, or final, members</li> </ul> When refactoring to interfaces, you do the following: <ol> <li>Extract an interface from the pure virtual members.</li> <li>Extract an interface from each of the virtual members.</li> <li>Implement each of the 'virtual member interfaces' with the implementation from the virtual member.</li> <li>Add a constructor to the abstract class that takes all these new interfaces as arguments. Save the arguments as class fields.</li> <li>Change all code in the abstract class to talk to the injected interfaces instead of direct class members.</li> <li>Remove the virtual and pure virtual members from the class, or make them non-virtual. If you keep them around, their implementation should be one line of code, delegating to the corresponding interface.</li> <li>Change the class to a concrete (non-abstract) class.</li> </ol> If you apply this refactoring to the above class, you should arrive at something like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IInterface1</span>&nbsp;pureVirts; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;virt1; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt2</span>&nbsp;virt2; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IVirt3</span>&nbsp;virt3; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;virt&nbsp;fields...</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Class1( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IInterface1</span>&nbsp;pureVirts,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt1</span>&nbsp;virt1,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt2</span>&nbsp;virt2,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IVirt3</span>&nbsp;virt3 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">/*&nbsp;More&nbsp;virt&nbsp;arguments...&nbsp;*/</span>) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.pureVirts&nbsp;=&nbsp;pureVirts; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt1&nbsp;=&nbsp;virt1; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt2&nbsp;=&nbsp;virt2; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.virt3&nbsp;=&nbsp;virt3; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;field&nbsp;assignments</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc1</span>&nbsp;Op1(<span style="color:#2b91af;">InConc1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc2</span>&nbsp;Op2(<span style="color:#2b91af;">InConc2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc2&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">OutConc3</span>&nbsp;Op3(<span style="color:#2b91af;">InConc3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;OutConc3&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;concrete&nbsp;members...</span> }</pre> </p> <p> While not strictly necessary, I've marked the class <code>sealed</code> (<code>final</code> in Java) in order to drive home the point that this is no longer an abstract class. </p> <p> This is an example of the Constructor Injection design pattern. (This is not a Gang of Four pattern; you can find a description in <a href="http://amzn.to/12p90MG">my book about Dependency Injection</a>.) </p> <p> Since it's optional to override virtual members, any class originally inheriting from an abstract class can choose to override only one, or two, of the virtual members, while leaving other virtual members with their default implementations. In order to support such piecemeal redefinition, you can extract each virtual member to a separate interface, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IVirt1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutVirt1</span>&nbsp;Virt1(<span style="color:#2b91af;">InVirt1</span>&nbsp;arg); }</pre> </p> <p> Notice that each of these 'virtual interfaces' are injected into <code>Class1</code> as a separate argument. This enables you to pass your own implementation of exactly those you wish to change, while you can pass in the default implementation for the rest. The default implementations are the original code from the virtual members, but moved to a class that implements the interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultVirt</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IVirt1</span>,&nbsp;<span style="color:#2b91af;">IVirt2</span>,&nbsp;<span style="color:#2b91af;">IVirt3</span> </pre> </p> <p> When inheriting from the original abstract class, however, you must implement all the pure virtual members, so you can extract a single interface from all the pure virtual members: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IInterface1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt1</span>&nbsp;PureVirt1(<span style="color:#2b91af;">InPureVirt1</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt2</span>&nbsp;PureVirt2(<span style="color:#2b91af;">InPureVirt2</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">OutPureVirt3</span>&nbsp;PureVirt3(<span style="color:#2b91af;">InPureVirt3</span>&nbsp;arg); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;pure&nbsp;virtual&nbsp;members...</span> }</pre> </p> <p> This forces anyone who wants to use the refactored (sealed) <code>Class1</code> to provide an implementation of all of those members. There's an edge case where you inherit from the original <code>Class1</code> in order to create a new <em>abstract</em> class, and implement only one or two of the pure virtual members. If you want to support that edge case, you can define an interface for each pure virtual member, instead of one big interface, similar to <code>IVirt1</code>, <code>IVirt2</code>, and so on. </p> <h3 id="7647f5cced134b24b4df7ec37d61fbf7"> From Dependency Injection to abstract class <a href="#7647f5cced134b24b4df7ec37d61fbf7" title="permalink">#</a> </h3> <p> I hope it's clear how to perform the inverse refactoring. Assume that the above sealed <code>Class1</code> is the starting point: <ol> <li>Mark <code>Class1</code> as <code>abstract</code>.</li> <li>For each of the members of <code>IInterface1</code>, add a pure virtual member.</li> <li>For each of the members of <code>IVirt1</code>, <code>IVirt2</code>, and so on, add a virtual member.</li> <li>Move the code from the default implementation of the 'virtual interfaces' to the new virtual members.</li> <li>Delete the dependency fields and remove the corresponding arguments from the constructor.</li> <li>Clean up orphaned interfaces and implementations.</li> </ol> This refactoring assumes a class using Dependency Injection like the one shown in this article, above. The example code is the same as the above example code, although the order is reversed: you start with the Dependency Injection class and end with the abstract class. </p> <h3 id="6dae326271714421b35d3acb4c08b99d"> Example: Gang of Four maze Builder as an abstract class <a href="#6dae326271714421b35d3acb4c08b99d" title="permalink">#</a> </h3> <p> As an example, consider the original Gang of Four example of the <a href="https://en.wikipedia.org/wiki/Builder_pattern">Builder</a> pattern. The example in the book is based on an abstract class called <code>MazeBuilder</code>. Translated to C#, it looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze()&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room)&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">virtual</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo)&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze(); }</pre> </p> <p> In the book, all four methods are virtual, because: <blockquote> "They're not declared pure virtual to let derived classes override only those methods in which they're interested." </blockquote> When it comes to the <code>GetMaze</code> method, this means that the method in the book returns a null reference by default. Since this seems like poor API design, and also because the example becomes more illustrative if the class has both abstract and virtual members, I changed it to be abstract (i.e. pure virtual). </p> <p> In general, there are various other issues with this design, the most glaring of which is the implied <a href="http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling">sequence coupling</a> between members: you're expected to call <code>BuildMaze</code> before any of the other methods. A better design would be to remove that explicit step entirely, or else turn it into a factory that you have to call in order to be able to call the other methods. That's not the topic of the present article, so I'll leave the API like this. </p> <p> The book also shows a simple usage example of the abstract <code>MazeBuilder</code> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeGame</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;CreateMaze(<span style="color:#2b91af;">MazeBuilder</span>&nbsp;builder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildRoom(1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildRoom(2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;builder.BuildDoor(1,&nbsp;2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;builder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> You use it with e.g. a <code>StandardMazeBuilder</code> like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(builder);</pre> </p> <p> You could also, again following the book's example as closely as possible, use it with a <code>CountingMazeBuilder</code>, like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(builder); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> This would produce <code>"The maze has 2 rooms and 1 doors."</code>. </p> <p> Both <code>StandardMazeBuilder</code> and <code>CountingMazeBuilder</code> are concrete classes that derive from the abstract <code>MazeBuilder</code> class. </p> <h3 id="dffe775a502b4e0eb55ec6d9705c3dcb"> Maze Builder refactored to interfaces <a href="#dffe775a502b4e0eb55ec6d9705c3dcb" title="permalink">#</a> </h3> <p> If you follow the refactoring outline in this article, you can refactor the above <code>MazeBuilder</code> class to a set of interfaces. The first should be an interface extracted from all the pure virtual members of the class. In this example, there's only one such member, so the interface becomes this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMazeBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze(); }</pre> </p> <p> The three virtual members each get their own interface, so that you can pick and choose which of them you want to override, and which of them you prefer to keep with their default implementation (which, in this particular case, is to do nothing). </p> <p> The first one was difficult to name: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IMazeInitializer</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze(); }</pre> </p> <p> An interface with a single method called <code>BuildMaze</code> would naturally have a name like <code>IMazeBuilder</code>, but unfortunately, I just used that name for the previous interface. The reason I named the above interface <code>IMazeBuilder</code> is because this is an interface extracted from the <code>MazeBuilder</code> abstract class, and I consider the pure virtual API to be the core API of the abstraction, so I think it makes most sense to keep the name for that interface. Thus, I had to come up with a <a href="http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling">smelly</a> name like <code>IMazeInitializer</code>. </p> <p> Fortunately, the two remaining interfaces are a little better: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IRoomBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo); }</pre> </p> <p> The three virtual members all had default implementations, so you need to keep those around. You can do that by moving the methods' code to a new class that implements the new interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> </pre> </p> <p> In this example, there's no reason to show the implementation of the class, because, as you may recall, all three methods are no-ops. </p> <p> Instead of inheriting from <code>MazeBuilder</code>, implementers now implement the appropriate interfaces: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> </pre> </p> <p> This version of <code>StandardMazeBuilder</code> implements all four interfaces, since, before, it overrode all four methods. <code>CountingMazeBuilder</code>, on the other hand, never overrode <code>BuildMaze</code>, so it doesn't have to implement <code>IMazeInitializer</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeBuilder</span> </pre> </p> <p> All of these changes leaves the original <code>MazeBuilder</code> class defined like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>,&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>,&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>,&nbsp;<span style="color:#2b91af;">IDoorBuilder</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;mazeInitializer; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MazeBuilder( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;mazeInitializer, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeBuilder&nbsp;=&nbsp;mazeBuilder; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeInitializer&nbsp;=&nbsp;mazeInitializer; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.roomBuilder&nbsp;=&nbsp;roomBuilder; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.doorBuilder&nbsp;=&nbsp;doorBuilder; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildMaze() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.mazeInitializer.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildRoom(<span style="color:blue;">int</span>&nbsp;room) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.roomBuilder.BuildRoom(room); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BuildDoor(<span style="color:blue;">int</span>&nbsp;roomFrom,&nbsp;<span style="color:blue;">int</span>&nbsp;roomTo) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.doorBuilder.BuildDoor(roomFrom,&nbsp;roomTo); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;GetMaze() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.mazeBuilder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> At this point, you may decide to keep the old <code>MazeBuilder</code> class around, because you may have other code that relies on it. Notice, however, that it's now a concrete class that has dependencies injected into it via its constructor. All four members only delegate to the relevant dependencies in order to do actual work. </p> <p> <code>MazeGame</code> looks like before, but calling <code>CreateMaze</code> looks more complicated: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>(builder,&nbsp;builder,&nbsp;builder,&nbsp;builder));</pre> </p> <p> Notice that while you're passing four dependencies to the <code>MazeBuilder</code> constructor, you can reuse the same <code>StandardMazeBuilder</code> object for all four roles. </p> <p> If you want to count the rooms and doors, however, <code>CountingMazeBuilder</code> doesn't implement <code>IMazeInitializer</code>, so for that role, you'll need to use the default implementation: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeBuilder</span>(builder,&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>(),&nbsp;builder,&nbsp;builder)); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> If, at this point, you're beginning to wonder what value <code>MazeBuilder</code> adds, then I think that's a legitimate concern. What often happens, then, is that you simply remove that extra layer. </p> <h3 id="dbb69051eeb1482c9a2bee079df977ab"> Mazes without MazeBuilder <a href="#dbb69051eeb1482c9a2bee079df977ab" title="permalink">#</a> </h3> <p> When you delete the <code>MazeBuilder</code> class, you'll have to adjust <code>MazeGame</code> accordingly: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MazeGame</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Maze</span>&nbsp;CreateMaze( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeInitializer</span>&nbsp;initializer,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IRoomBuilder</span>&nbsp;roomBuilder,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDoorBuilder</span>&nbsp;doorBuilder, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IMazeBuilder</span>&nbsp;mazeBuilder) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;initializer.BuildMaze(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;roomBuilder.BuildRoom(1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;roomBuilder.BuildRoom(2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;doorBuilder.BuildDoor(1,&nbsp;2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;mazeBuilder.GetMaze(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>CreateMaze</code> method now simply takes the four interfaces on which it relies as individual arguments. This simplifies the client code as well: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">StandardMazeBuilder</span>(); <span style="color:blue;">var</span>&nbsp;maze&nbsp;=&nbsp;game.CreateMaze(builder,&nbsp;builder,&nbsp;builder,&nbsp;builder);</pre> </p> <p> You can still reuse a single <code>StandardMazeBuilder</code> in all roles, but again, if you only want to count the rooms and doors, you'll have to rely on <code>DefaultMazeBuilder</code> for the behaviour that <code>CountingMazeBuilder</code> doesn't define: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;game&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">MazeGame</span>(); <span style="color:blue;">var</span>&nbsp;builder&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">CountingMazeBuilder</span>(); game.CreateMaze(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">DefaultMazeBuilder</span>(),&nbsp;builder,&nbsp;builder,&nbsp;builder); <span style="color:blue;">var</span>&nbsp;msg&nbsp;=&nbsp;<span style="color:#a31515;">$&quot;The&nbsp;maze&nbsp;has&nbsp;</span>{builder.RoomCount}<span style="color:#a31515;">&nbsp;rooms&nbsp;and&nbsp;</span>{builder.DoorCount}<span style="color:#a31515;">&nbsp;doors.&quot;</span>;</pre> </p> <p> The order in which dependencies are passed to <code>CreateMaze</code> is different than the order they were passed to the now-deleted <code>MazeBuilder</code> constructor, so you'll have to pass a <code>new DefaultMazeBuilder()</code> as the first argument in order to fill the role of <code>IMazeInitializer</code>. Another way to address this issue is to supply various overloads of the <code>CreateMaze</code> method that uses <code>DefaultMazeBuilder</code> for the behaviour that you don't want to override. </p> <h3 id="011d61051d3c4340bbd3d9582b6dc482"> Summary <a href="#011d61051d3c4340bbd3d9582b6dc482" title="permalink">#</a> </h3> <p> Many of the original design patterns in <em>Design Patterns</em> are described with examples in C++, and many of these examples use abstract classes as the programming interfaces that the Gang of Four really had in mind when they wrote that we should be programming to interfaces instead of implementations. </p> <p> The most important result of this article is that you can reinterpret the original design patterns with C# or Java interfaces and Dependency Injection, instead of using abstract classes. I've done this in C# for more than ten years, and in my experience, you never need abstract classes in a greenfield code base. There's always an equivalent representation that involves composition of interfaces. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/02/26/inheritance-composition-isomorphism">Inheritance-composition isomorphism</a>. </p> </div> <div id="comments"> <hr /> <h2 id="comments-header">Comments</h2> <div class="comment" id="b8cb5baf6ccd4cc98412c229d3dadb06"> <div class="comment-author"> <a href="https://github.com/MaxKot">Max Kiselev</a> </div> <div class="comment-content"> <p> While the idea is vey interesting I think it is not exactly an isomorphism. </p> <p> The first reason I think it is not an isomorphism is language-specific since Java and C# allow implementing multiple interfaces but not multiple abstract classes. It can make a reverse transformation from interfaces back to an abstract class non-trivial. </p> <p> The second reason is that abstract class guarantees that whatever class implements the pure virtual members and overrides virtual members share the same state between all its methods and also with the abstract base class. With the maze Builder example there must be a state shared between GetMaze, BuildMaze, BuildRoom and BuildDoor methods but the dependency injection does not seem to reflect it. </p> <p> Perhaps there should be some kind of Data parameter passed to all injected interfaces. </p> </div> <div class="comment-date">2018-03-05 19:03 UTC</div> </div> <div class="comment" id="13cc2c9a28114b52add8942d3ac3c94d"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Max, thank you for writing, and particularly for applying critique to this post. One of my main motivations for writing <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">the entire article series</a> is that I need to subject my thoughts to peer review. I've been thinking about these things for years, but in order to formalise them, I need to understand whether I'm completely wrong (I hope not), of, if I'm not, what are the limits of my findings. </p> <p> I think you've just pointed at one such limit, and for that I'm grateful. The rest of this answer, then, is not an attempt to refute your comment, but rather an effort to identify some <em>constraints</em> within which what I wrote may still hold. </p> <p> Your second objection doesn't worry me that much, because you also suggest a way around it. I admit that I faked the Maze Builder code somewhat, so that the state isn't explicit. I feel that fudging the code example is acceptable, as the Gang of Four code example is also clearly incomplete. In any case, you're right that an abstract class could easily contain some shared state. When refactoring to interfaces, the orchestrating class could instead pass around that state as an argument to all methods, as you suggest. Would it be reasonable to conclude that this, then, doesn't prevent the translations from being isomorphic? </p> <p> There's still your first objection, which I think is significant. That's the reason I decided to cover your second objection first, because I think it'll require more work to address the first objection. </p> <p> First, I think we need to delimit the problem, since your comment slightly misrepresents my article. The claim in the article is that you can refactor an abstract class to a concrete class with injected dependencies. Furthermore, the article claims that this translation is isomorphic; i.e. that you can refactor a concrete class with injected dependencies to an abstract class. </p> <p> If I read your comment right, you're saying that a class can implement more than one interface, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IFoo</span>,&nbsp;<span style="color:#2b91af;">IBar</span><br/></pre> </p> <p> I agree that you can't use the transformations described in this article to refactor <code>MyClass</code> to an abstract class, because that's not the transformation that the article describes. </p> <p> That doesn't change that your comment is uncomfortably close to an inconvenient limitation. You're right that there seems to be a limitation when it comes to C#'s and Java's lack of multiple inheritance. As your comment implies, if a translation is isomorphic, one has to be able to start at either end, and round-trip to the other end and back. Thus, one has to be able to start with a concrete class with injected dependencies, and refactor to an abstract class; for example: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span><br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass(<span style="color:#2b91af;">IFoo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">IBar</span>&nbsp;bar)<br/>&nbsp;&nbsp;&nbsp;&nbsp;{<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span><br/>&nbsp;&nbsp;&nbsp;&nbsp;}<br/>}</pre> </p> <p> As far as I can tell, that's exactly the shape of the <code>sealed</code> version of <code>Class1</code>, above, so I'm not convinced that that's a problem, but something like the following does look like a problem to me: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span><br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass(<span style="color:#2b91af;">IFoo</span>&nbsp;foo1,&nbsp;<span style="color:#2b91af;">IFoo</span>&nbsp;foo2)<br/>&nbsp;&nbsp;&nbsp;&nbsp;{<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span><br/>&nbsp;&nbsp;&nbsp;&nbsp;}<br/>}</pre> </p> <p> It's not clear to me how one can refactor something like that to an abstract class, and still retain the distinction between <code>foo1</code> and <code>foo2</code>. My claim is not that this is impossible, but only that it's not immediately clear to me how to do that. Thus, we may have to put a constraint on the original claim, and instead say something like this: <blockquote> An abstract class is isomorphic to a concrete class with injected dependencies, given that all the injected dependencies are of different types. </blockquote> We can attempt to illustrate the claim like this: </p> <p> <img src="/content/binary/abstract-class-to-constrained-dependency-injection-isomorphism.png" alt="The set of abstract classes juxtaposed with the set of dependency injection, the latter with a subset for which arrows go both ways between the subset and the set of abstract classes."> </p> <p> This is still an isomorphism, I think, although I invite further criticism of that claim. <a href="http://amzn.to/13tGJ0f">Conceptual Mathematics</a> defines an isomorphism in terms of categories <em>A</em> and <em>B</em>, and as far as I can tell, <em>A</em> and <em>B</em> can be as specific as we want them to be. Thus, we can say that <em>A</em> is the set of abstract classes, and <em>B</em> is the subset of concrete classes with injected dependencies, for which no dependency share the same type. </p> <p> If we have to constrain the isomorphism in this way, though, is it still interesting? Why should we care? </p> <p> To be perfectly honest, what motivated me to write this particular article is that I wanted to describe the translation from an abstract class to dependency injection. The inverse interests me less, but I thought that if the inverse translation exists, I could fit this article in with the other articles in this article series about software design isomorphisms. </p> <p> The reason I care about the translation from abstract class to dependency injection is that I often see code where the programmers misuse inheritance. My experience with C# is that one can completely avoid inheritance. The way to do that is to use dependency injection instead. This article shows how to do that. </p> <p> The result that one can write real, complex code bases in C# without inheritance is important to me, because one of my current goals is to teach people the advantages of functional programming, and one barrier I run into is that people who come from object-oriented programming run into problems when they no longer can use inheritance. Thus, this article shows an object-oriented alternative to inheritance, so that people can get used to the idea of designing without inheritance, even before they start looking at functional programming. </p> <p> Another motivation for this article is that it's part of <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">a much larger article series</a> about design patterns, and how they relate to fundamental abstractions. In <em>Design Patterns</em>, all the (C++) patterns are described in terms of inheritance, so I wrote this article series on isomorphisms in order to be able to represent various design patterns in other forms than they appear in the book. </p> </div> <div class="comment-date">2018-03-08 9:57 UTC</div> </div> <div class="comment" id="93410202470d4406a698fa4ffb6d3c27"> <div class="comment-author"> Ciprian Vilcan </div> <div class="comment-content"> <p> This idea is a very interesting and useful one, but as I found out in one of my toy projects and as Max stated above, it is unfortunately not language agnostic.<br /> As far as C# is concerned, you can have operator overloading in an abstract class, which is a bit of logic that I see no way of extracting to an interface and thus remove the need for inheritance. Example below.<br /> (You could define Add, Subtract, Multiply and Divide methods, but to me they seem like reinventing the square wheel. They seem much less convenient than +-*/) </p> <p> I tried creating some nice Temperature value objects, similar to <a href="http://blog.ploeh.dk/2017/10/16/money-monoid/">the money monoid you presented</a> and I came up with 5 classes:<br /> Temperature, Kelvin, Celsius, Fahrenheit and TemperatureExpression.<br /> Temperature is the abstract class and its +Temperature and -Temperature operators are overloaded so that they return a TemperatureExpression, which can then be evaluated to a Maybe&lt;TTemperature&gt; where TTemperature : Temperature. <br /> A TemperatureExpression is nothing more than a lazily evaluated mathematical expression (for example: 12K + 24C - 32F).<br /> Also, it's a Maybe because 0K - 1C won't be a valid temperature, so we have to also take this case into consideration. <br /> </p> <p> For further convenience, the Kelvin class has its own overloaded + operator, because no matter what you do, when adding together two Kelvin values you'll always end up with something that is greater than 0. </p> <p> These being said, if you want to leverage the C# operators there are some limitations regarding this transformation that keep you from having this abstract class -> DI isomorphism. <br /> That is, unless you're willing to add the methods I've spoken of in the first paragraph. <br /> But, in an ideal programming language, IMHO, arithmetic and boolean operators should be part of some public interfaces like, ISubtractable, IDivideable and thus allow for a smooth transition between abstract classes and interface DI. </p> </div> <div class="comment-date">2018-03-08 10:16 UTC</div> </div> <div class="comment" id="7aac063a684047ae9561c6666a42f908"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for writing. I agree that this isn't language agnostic. It's possible that we need to add further constraints to the conjecture, but I still anticipate that, with appropriate constraints, it holds for statically typed 'mainstream' object-oriented languages (i.e. C# and Java). It may also hold for other languages, but it requires detailed knowledge of a language to claim that it does. For instance, it's been too long since I wrote C++ code, and I can't remember how its object-oriented language features work. Likewise, it'd be interesting to investigate if the conjecture holds when applied to JavaScript, Ruby, Python, etc., but I've been careful not to claim that, as I know too little about those languages. </p> <p> Regarding your temperature example, I <em>think</em> that perhaps I understand what the issue is, but I'm not sure I've guessed right. In the interest of being able to have an unambiguous discussion about a code example, could you please post the pertinent code that illustrates your point? </p> </div> <div class="comment-date">2018-03-09 8:07 UTC</div> </div> <div class="comment" id="52d98574756f471482303e34dc02df33"> <div class="comment-author">Ciprian Vilcan</div> <div class="comment-content"> <p> I've added the code to <a href="https://github.com/ciprian-vilcan/CQRS.CoffeeMaker">github</a>. I think it's better than copy-pasting here as you can gain some extra context. </p> <p> It's a playground project where I put to practice various ideas I find on the web (so if you see something you consider should be done otherwise, I don't mind you saying it). I've added a few comments to make it a bit easier to understand and also removed anything that doesn't pertain to the issue with abstract class -> DI.<br /> </p> <p> In short, the bit of logic that I can't see a way of extracting to some sort of injectable dependency are the +- operators on the Temperature class due to the fact that they are static methods, thus cannot be part of an interface (at least in C#, I don't know about programming languages). </p> </div> <div class="comment-date">2018-03-09 11:14 UTC</div> </div> <div class="comment" id="b9a9d7e657804832b4adcc6e71aa0d7f"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Ciprian, thank you for elaborating. I'd forgotten about C#'s ability to overload arithmetic operators, which is, I believe, what you're referring to. To be clear, I do believe that it's a fair enough critique, so that we'll have to once again restrict this article's conjecture to something like: <blockquote> There exists a subset <em>A</em> of all abstract classes, and a subset of all concrete classes with injected dependencies <em>I</em>, such that an isomorphism <em>A &lt;-&gt; I</em> exists. </blockquote> In diagram form, it would look like this: </p> <p> <img src="/content/binary/subset-of-abstract-classes-to-subset-of-dependency-injection-isomorphism.png" alt=""> </p> <p> By its shape, the diagram suggests that the size of abstract classes <em>not</em> isomorphic with Dependency Injection is substantial, but that's not really my intent; I just had to leave room for the text. </p> <p> My experience suggests to me that most abstract classes can be refactored as I've described in this article, but clearly, as you've shown, there are exceptions. C#'s support for operator overloading is one such exception, but there may be others of which I'm currently ignorant. </p> <p> That said, I would like to make the case that arithmetic operators aren't object-oriented in the first place. Had the language been purely object-oriented from the outset, addition would more appropriately have had a syntax like <code>40.Add(2)</code>. This would imply that the language would have been based on the concept of objects as data with behaviour, and the behaviour would exclusively have been defined by class members. </p> <p> Even at the beginning, though, C# was a hybrid language. It had (and still has) a subset of language features focused on more low-level programming. It has value types in addition to reference types, it has arithmetic operators, it has special support for bitwise Boolean operators, and it even has pointers. </p> <p> There are practical reasons that all of those features exist, but I would claim that none of those features have anything to do with object-orientation. </p> <p> Specifically when it comes to arithmetic operators, the operators are all special cases baked into the language. The selection of operators is sensible, but when you get to the bottom of it, arbitrary. For instance, there's a modulo operator, but no power operator. Why? </p> <p> As an aside, languages do exist where arithmetic is an abstraction instead of a language feature. The one I'm most familiar with is <a href="https://www.haskell.org">Haskell</a>, where arithmetic is defined in terms of type classes. It's worth noting that the operators <code>+</code>, <code>*</code>, and <code>-</code> are defined in an abstraction called <a href="http://hackage.haskell.org/package/base/docs/Prelude.html#t:Num">Num</a>, whereas the 'fourth' arithmetic operator <code>/</code> is defined in a more specialised abstraction called <a href="http://hackage.haskell.org/package/base/docs/Prelude.html#t:Fractional">Fractional</a>. </p> <p> Not that Haskell's model of arithmetic is perfect, but there's a rationale behind this distinction. Division is special, because it can translate two integers (e.g. <code>2</code> and <code>3</code>) into a rational number (e.g. <code>2/3</code>), while both addition and multiplication are <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>. This is where Haskell starts to fall apart itself, though, because subtraction can also translate two numbers out of the set in which they originally belonged. For example, given two <em>natural</em> numbers <code>2</code> and <code>3</code>, <code>2 - 3</code> is no longer a natural number, since it's negative. </p> <p> But all of that is an aside. Even in C#, one has to deal with low-level exceptional cases such as integer overflow, so even addition isn't truly monoidal, unless you use <a href="https://msdn.microsoft.com/en-us/library/system.numerics.biginteger">BigInteger</a>. </p> </div> <div class="comment-date">2018-03-11 9:35 UTC</div> </div> <div class="comment" id="5b00a6edefbf4a82925083eeac5d7768"> <div class="comment-author"><a href="https://github.com/MaxKot">Max Kiselev</a></div> <div class="comment-content"> <p> Mark, thank you for the detailed response. I didn't mean to refute the usefulness of the refactoring you described. I now see how I tried to apply the refactoring of DI to abstact class where it was not claimed to be possible. </p> <p> I've been thinking about the example with the injection of distinct instances of the same type. I think we can use simple wrapper types for this kind of problem: </p> <p> <pre style="font-family:Consolas;font-size:13;color:black;background:white;"><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo1</span>&nbsp;:&nbsp;IFoo { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;IFoo&nbsp;impl_; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Foo1&nbsp;(IFoo&nbsp;impl) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;impl_&nbsp;=&nbsp;impl; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Out1&nbsp;Op1&nbsp;(In1&nbsp;in1) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;impl_.Op1&nbsp;(in1); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Foo1 implements IFoo to keep the ability to e.g. create a list of foo1 and foo2. </p> <p> Given such wrappers are created for all dependencies of type IFoo, MyClass can be rewritten like this: </p> <p> <pre style="font-family:Consolas;font-size:13;color:black;background:white;"><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">MyClass</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;MyClass&nbsp;(Foo1&nbsp;foo1,&nbsp;Foo2&nbsp;foo2) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;...</span> &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Now MyClass can be refactored into an abstract class without losing the distinction between foo1 and foo2. </p> <p> I also belive that, given the wrappers are used only in the context of MyClass, the use of wrappers and diffent fields or parameters is an isomorphism. While its usefulness as a stand-alone refactoing is limited, it may come handy for reasoning similar to the one you did in <a href="/2018/03/12/composite-as-a-monoid/">Composite as a monoid</a>. </p> <p> Thin wrappers can be used to create an <em>almost</em> convenient way to define operators on interfaces. Unfortunately C# does not allow user-defined conversions to or from an interface so one have to explicitly wrap all instances of the interface in an expression that do not have wrapper on one side of an expression. While it can be acceptable in some cases (like <span>Wrap(a) + b + c + d ...</span>), it can make more complex expressions very cumbersome (like <span>(Wrap(a) + b) + (Wrap(c) + d) ...</span> hence it does not solve the problem that Ciprian described. </p> </div> <div class="comment-date">2018-03-22 21:33 UTC</div> </div> <div class="comment" id="2e3ab0c8da334d5cb066eab2f492c50e"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Max, thank you for writing back. That's an ingenious resolution to some of the problems you originally pointed out. Thank you! </p> <p> As far as I can tell, this seems to strengthen the original argument, although there's still some corner cases, like the one pointed out by Ciprian. We can use Decorators as <a href="http://blog.ploeh.dk/2012/08/31/ConcreteDependencies">concrete dependencies</a> as you point out, as an argument that even two (or <em>n</em>) identical polymorphic dependencies can be treated as though they were distinct dependencies. </p> <p> What if we have an arbitrary number of dependencies? One example would be of a Composite, but it doesn't have to be. Consider the <code>ShippingCostCalculatorFactory</code> class from <a href="http://blog.ploeh.dk/2013/01/11/PartialTypeNameRoleHint">this example</a>. It depends on a list of <code>IBasketCalculator</code> candidates. Could such a class, too, be refactored to an abstract class? </p> <p> I suppose it could, since the dependency then really isn't an arbitrary number of <code>IBasketCalculator</code>, but rather the dependency is on <em>a collection</em>. Would it be enough to refactor to an abstract class with a single <a href="https://en.wikipedia.org/wiki/Factory_method_pattern">Factory Method</a> that returns the candidates? </p> </div> <div class="comment-date">2018-03-27 5:50 UTC</div> </div> <div class="comment" id="ae9139f637184901bd681f5a28ddecb4"> <div class="comment-author"><a href="https://github.com/MaxKot">Max Kiselev</a></div> <div class="comment-content"> <p> Mark, you're welcome! Admittedly, my solution is heavily inspired by the strong-typing as promoted by "if a Haskell program compiles, it probably works" and the <a href="https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/">original purpose of Hungarian notation</a>. </p> <p> As for an abrbitrary number of dependencies, you have already pointed out that the dependency is the collection itself, not its elements. So I think ShippingCostCalculatorFactory can be refactored to an abstract class with an abstract factory method to provide a collection of IBasketCalculator. </p> <p> While abstract class would be more complex and less elegant than DI implementation, I find the reversibility of refactorings very important. Reversability means that the changes to the code are not changing the behavior of the compiled program. It allows to refactor even obscure and undertested legacy code without fear of breaking it. I find the two-way nature of changes to the code the most interesting about your concept of software isomorphisms. </p> <p> I think the reason abstract classes are usually difficult to reason about and often considered to be a bad choice is that an abstract class and it's inheritors create an implicit composition and the relationships of the parts of this composition can be very different. A base class can serve as a collection of helper methods, or derived classes can serve as dependencies or specify dependencies like in the ShippingCostCalculatorFactory example, or inheitors can serve as a configuration to the base class like custom configuration element classes in .NET derived from ConfigurationElement. Abstract base class can be even used to implement disciminated unions (and in fact F# compiler does). </p> <p> Perhaps different kinds of hierarchies can be enumerated with some formal ways to recognize a specific kind of hierarchy and refactor it into an explicit compistion? </p> <p> P.S. One way to implement discriminated unions with C# abstract base classes and guarantee exhaustive matching: </p> <pre style="font-family:Consolas;font-size:13;color:black;background:white;"><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Some(<span style="color:#2b91af;">T</span>&nbsp;value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;None(); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Option</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">SomeImpl</span>&nbsp;:&nbsp;<span style="color:#2b91af;">Option</span>&lt;<span style="color:#2b91af;">T</span>&gt; &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;_value; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;SomeImpl(<span style="color:#2b91af;">T</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_value&nbsp;=&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visitor.Some(_value); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NoneImpl</span>&nbsp;:&nbsp;<span style="color:#2b91af;">Option</span>&lt;<span style="color:#2b91af;">T</span>&gt; &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">override</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visitor.None(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;Option&nbsp;() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Option</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Some(<span style="color:#2b91af;">T</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">SomeImpl</span>(value); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Option</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;None&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;}&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NoneImpl</span>(); } </pre> <p> While I don't see how this kind of abstract base class can be refactored to DI, I can not call this a constraint on the abstact class isomorphism because semantically it is not an asbtract class in first place. </p> </div> <div class="comment-date">2018-04-03 18:20 UTC</div> </div> <div class="comment" id="bbc66b98b21d438d98733bf264edba18"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Max, once again thank you for writing. I've never seen that article by Joel Spolsky before, but I particularly liked your enumeration of the various different roles an abstract class can have. </p> <p> It's seems that we're generally in agreement about the constraints of the described refactoring. </p> <p> When it comes to your <em>option</em> implementation, I think you could fairly easy split up <code>Option&lt;T&gt;</code> into an interface that defines the <code>AcceptVisitor</code> method, and two classes that implements that interface. This is, however, closely related to a series of articles I'll publish in the future. </p> </div> <div class="comment-date">2018-04-04 19:20 UTC</div> </div> <div class="comment" id="72285cb33eb5424cb0c82f5239d02bfe"> <div class="comment-author"><a href="https://github.com/MaxKot">Max Kiselev</a></div> <div class="comment-content"> <p> Mark, thank you for pointing out the alternative option implementation. </p> <p> The key trick in my Option implementation is the use of private constructor in an abstract class with nested sealed implementation classes. Nested classes can access the private contructor while any class "outside" Option would be unable to call the base constructor. Now I think that enforcing that there are no implementation of Option except for SomeImpl and NoneImpl is redundant as long as the implementations are correct. </p> <p> Perhaps I should have made an example with public nested classes which can be matched by their type but then it could be refactored into Visitor pattern too. Does it mean that Visitor is isomorphic to discriminated unions then? </p> </div> <div class="comment-date">2018-04-05 18:50 UTC</div> </div> <div class="comment" id="eea4079cf3794de2a3645fb68436eca9"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Max, I agree that using a nested, private, sealed class is a good way to ensure that no-one else can add rogue implementations of an interface like <code>IOptionVisitor&lt;T&gt;</code>. </p> <p> Additionally, I think that you're correct that it isn't possible to lock down the API to the same degree if you redefine <code>Option&lt;T&gt;</code> to an interface. Just to be clear, I'm thinking about something like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Some(<span style="color:#2b91af;">T</span>&nbsp;value); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;None(); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IOption</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor); } <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Option</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IOption</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Some&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">SomeImpl</span>&lt;<span style="color:#2b91af;">T</span>&gt;(value); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">SomeImpl</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IOption</span>&lt;<span style="color:#2b91af;">T</span>&gt; &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;SomeImpl(<span style="color:#2b91af;">T</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.value&nbsp;=&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visitor.Some(value); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IOption</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;None&lt;<span style="color:#2b91af;">T</span>&gt;() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NoneImpl</span>&lt;<span style="color:#2b91af;">T</span>&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">sealed</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NoneImpl</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IOption</span>&lt;<span style="color:#2b91af;">T</span>&gt; &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AcceptVisitor(<span style="color:#2b91af;">IOptionVisitor</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;visitor) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;visitor.None(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> With a design like that, rogue implementations of <code>IOption&lt;T&gt;</code> are possible, and I admit that I can't think of a way to prevent that. </p> <p> Usually, that doesn't concern me that much, but if one were to publish a type like that as, say, a public NuGet package, that degree of lock-down could, in fact, be desirable. So, it looks like you've identified another constraint on the isomorphism. I admit that I may have been too focused on the ability to implement <em>behaviour</em> in various different ways, whereas I haven't given too much thought to accessibility. </p> <p> To be frank, one of the reasons for that is that I tend to not consider accessibility modifiers too much in C#, as I tend to design classes in such a way that they protect their invariants. When classes do that, I'm happy to make most methods <code>public</code>. </p> <p> Another reason that I've been vague on accessibility is that this could easily get implementation-specific. The way C#'s access modifiers work is different from Java's and C++'s. </p> <p> That doesn't change the fact, though, that it looks like you've identified another constraint on the isomorphism, and for that I'm very grateful. Perhaps we ought to say something like: <blockquote> Abstract classes are isomorphic with dependency injection up to accessibility. </blockquote> Again, there may be other constraints than that (and operator overloads), but I'm beholden to you for fleshing out those that you've already identified. </p> <p> About the relationship between discriminated unions and the Visitor design pattern, then yes: those are isomorphic. That's a known property, but I'm going to publish a whole (sub-)series of articles about that particular topic in the future, so I think it'd be better to discuss that when we get there. I've already written those articles, but it'll take months before I publish them, according to the publishing schedule that I currently have in mind. Very prescient of you, though. </p> </div> <div class="comment-date">2018-04-06 7:36 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Object isomorphisms http://blog.ploeh.dk/2018/02/12/object-isomorphisms 2018-02-12T19:34:00+00:00 Mark Seemann <div id="post"> <p> <em>An object is equivalent to a product of functions. Alternative ways to look at objects.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. So far, you've seen how to represent a single method or function in many different ways, but we haven't looked much at <em>objects</em> (in the object-oriented interpretation of the word). </p> <p> While this article starts by outlining the abstract concepts involved, an example is included towards the end. </p> <h3 id="40bc65be9e9f4c67af814a0b1983304d"> Objects as data with behaviour <a href="#40bc65be9e9f4c67af814a0b1983304d" title="permalink">#</a> </h3> <p> I often use the phrase that <em>objects are data with behaviour</em>. (I'm sure I didn't come up with this myself, but the source of the phrase escapes me.) In languages like C# and Java, objects are described by classes, and these often contain <em>class fields</em>. These fields constitute an instance's data, whereas its methods implement its behaviour. </p> <p> A class can contain an arbitrary number of fields, just like a method can take an arbitrary number of arguments. As demonstrated by the <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">argument list isomorphisms</a>, you can also represent an arbitrary number of arguments as a Parameter Object. The same argument can be applied to class fields. Instead of <em>n</em> fields, you can add a single 'data class' that holds all of these fields. In <a href="http://fsharp.org">F#</a> and <a href="https://www.haskell.org">Haskell</a> these are called <em>records</em>. You could also dissolve such a record to individual fields. That would be the inverse refactoring, so these representations are isomorphic. </p> <p> In other words, a class looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;Data&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">In2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">In3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;this,&nbsp;Data,&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members...</span> }</pre> </p> <p> Instead of an arbitrary number of fields, I've used the above isomorphism to represent data in a single <code>Data</code> property (Java developers: a C# property is a class field with public getter and setter methods). </p> <p> In this code example, I've deliberately kept the naming abstract. The purpose of this article series is to look at the shape of code, instead of what it does, or why. From argument list isomorphisms we know that we can represent any method as taking a single input value, and returning a single output value. The remaining work to be done in this article is to figure out what to do when there's more than a single method. </p> <h3 id="ec92878346c240baa60b3aa7e85b3c6e"> Module <a href="#ec92878346c240baa60b3aa7e85b3c6e" title="permalink">#</a> </h3> <p> From <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">function isomorphisms</a> we know that static methods are isomorphic to instance methods, as long as you include the original object as an extra argument. In this case, all data in <code>Class1</code> is contained in a single (mutable) <code>Data1</code> record, so we can eliminate <code>Class1</code> from the argument list in favour of <code>Data1</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Class1</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In1</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out2</span>&nbsp;Op2(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In2</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Out3</span>&nbsp;Op3(<span style="color:#2b91af;">Data1</span>&nbsp;data,&nbsp;<span style="color:#2b91af;">In3</span>&nbsp;arg) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;data&nbsp;and&nbsp;arg;&nbsp;return&nbsp;an&nbsp;Out1&nbsp;value.</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members...</span> }</pre> </p> <p> Notice that <code>Class1</code> is now a <code>static</code> class. This simply means that it has no instance members, and if you try to add one, the C# compiler will complain. </p> <p> This is, in essence, a <em>module</em>. In F#, for example, a <code>module</code> is a static class that contains a collection of values and functions. </p> <h3 id="ba6804b2be7f48f989041fd684b55faf"> Closures as behaviour with data <a href="#ba6804b2be7f48f989041fd684b55faf" title="permalink">#</a> </h3> <p> As <em>data with behaviour</em>, objects are often passed around as input to methods. It's a convenient way to pass both data and associated behaviour (perhaps even with polymorphic dispatch) as a single thing. You'd be forgiven if you've looked at the above module-style refactoring and found it lacking in that regard. </p> <p> Nevertheless, function isomorphisms already demonstrated that you can solve this problem with closures. Imagine that you want to package all the static methods of <code>Class1</code> with a particular <code>Data1</code> value, and pass that 'package' as a single argument to another method. You can do that by closing over the value: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Data1</span>&nbsp;{&nbsp;<span style="color:green;">/*&nbsp;initialize&nbsp;members&nbsp;here&nbsp;*/</span>&nbsp;}; <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In1</span>,&nbsp;<span style="color:#2b91af;">Out1</span>&gt;&nbsp;op1&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op1(data,&nbsp;arg); <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In2</span>,&nbsp;<span style="color:#2b91af;">Out2</span>&gt;&nbsp;op2&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op2(data,&nbsp;arg); <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">In3</span>,&nbsp;<span style="color:#2b91af;">Out3</span>&gt;&nbsp;op3&nbsp;=&nbsp;arg&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Class1</span>.Op3(data,&nbsp;arg); <span style="color:green;">//&nbsp;More&nbsp;closures...</span></pre> </p> <p> First, you create a <code>Data1</code> value, and initialise it with your desired values. You then create <code>op1</code>, <code>op2</code>, and so on. These are functions that close over <code>data</code>; A.K.A. <em>closures</em>. Notice that they all close over the same variable. Also keep in mind here that I'm in no way pretending that <code>data</code> is immutable. That's not a requirement. </p> <p> Now you have <em>n</em> closures that all close over the same <code>data</code>. All you need to do is to package them into a single 'object': </p> <p> <pre><span style="color:blue;">var</span>&nbsp;objEq&nbsp;=&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(op1,&nbsp;op2,&nbsp;op3&nbsp;<span style="color:green;">/*&nbsp;more&nbsp;closures...&nbsp;*/</span>); </pre> </p> <p> Once again, tuples are workhorses of software design isomorphisms. <code>objEq</code> is an 'object equivalent' consisting of closures; it's <em>behaviour with data</em>. You can now pass <code>objEq</code> as an argument to another method, if that's what you need to do. </p> <h3 id="6152f0c00f044f02afa4720affe09616"> Isomorphism <a href="#6152f0c00f044f02afa4720affe09616" title="permalink">#</a> </h3> <p> One common variation that I sometimes see is that instead of a tuple of functions, you can create a <em>record</em> of functions. This enables you to give each function a statically enforced name. In the theory of <a href="https://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data types</a>, tuples and records are both <em>product types</em>, so when looking at the shape of code, these are closely related. Records also enable you to preserve the name of each method, so that this mapping from object to record of functions becomes lossless. </p> <p> The inverse mapping also exists. If you have a record of functions, you can refactor it to a class. You use the name of each record element as a method name, and the arguments and return types to further flesh out the methods. </p> <h3 id="0805ec33f9504153a7bc4173f5189479"> Example: simplified Turtle <a href="#0805ec33f9504153a7bc4173f5189479" title="permalink">#</a> </h3> <p> As an example, consider this (over-)simplified <a href="https://en.wikipedia.org/wiki/Turtle_graphics">Turtle</a> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Turtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Turtle() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Turtle(<span style="color:blue;">double</span>&nbsp;x,&nbsp;<span style="color:blue;">double</span>&nbsp;y,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;=&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;=&nbsp;(<span style="color:blue;">this</span>.AngleInDegrees&nbsp;+&nbsp;angleInDegrees)&nbsp;%&nbsp;360; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Convert&nbsp;degrees&nbsp;to&nbsp;radians&nbsp;with&nbsp;180.0&nbsp;degrees&nbsp;=&nbsp;1&nbsp;pi&nbsp;radian</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;angleInRadians&nbsp;=&nbsp;<span style="color:blue;">this</span>.AngleInDegrees&nbsp;*&nbsp;(<span style="color:#2b91af;">Math</span>.PI&nbsp;/&nbsp;180); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;=&nbsp;<span style="color:blue;">this</span>.X&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Cos(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;=&nbsp;<span style="color:blue;">this</span>.Y&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Sin(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> In order to keep the example simple, the only operations offered by the <code>Turtle</code> class is <code>Turn</code> and <code>Move</code>. With this simplified API, you can create a <code>turtle</code> object and interact with it: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>(); turtle.Move(2); turtle.Turn(90); turtle.Move(1);</pre> </p> <p> This sequence of operations will leave <code>turtle</code> as position <em>(2, 1)</em> and an angle of 90°. </p> <p> Instead of modelling a turtle as an object, you can instead model it as a data structure and a set of (impure) functions: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">TurtleData</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TurtleData() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TurtleData(<span style="color:blue;">double</span>&nbsp;x,&nbsp;<span style="color:blue;">double</span>&nbsp;y,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.x&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.angleInDegrees&nbsp;=&nbsp;angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:#2b91af;">TurtleData</span>&nbsp;data,&nbsp;<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.angleInDegrees&nbsp;=&nbsp;(data.angleInDegrees&nbsp;+&nbsp;angleInDegrees)&nbsp;%&nbsp;360; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:#2b91af;">TurtleData</span>&nbsp;data,&nbsp;<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Convert&nbsp;degrees&nbsp;to&nbsp;radians&nbsp;with&nbsp;180.0&nbsp;degrees&nbsp;=&nbsp;1&nbsp;pi&nbsp;radian</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;angleInRadians&nbsp;=&nbsp;data.angleInDegrees&nbsp;*&nbsp;(<span style="color:#2b91af;">Math</span>.PI&nbsp;/&nbsp;180); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.x&nbsp;=&nbsp;data.x&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Cos(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data.y&nbsp;=&nbsp;data.y&nbsp;+&nbsp;(distance&nbsp;*&nbsp;<span style="color:#2b91af;">Math</span>.Sin(angleInRadians)); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetX(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.x; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetY(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.y; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">double</span>&nbsp;GetAngleInDegrees(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;data.angleInDegrees; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that all five static methods take a <code>TurtleData</code> value as their first argument, just as the above abstract description suggests. The implementations are almost identical; you simply replace <code>this</code> with <code>data</code>. If you're a C# developer, you may be wondering about the accessor functions <code>GetX</code>, <code>GetY</code>, and <code>GetAngleInDegrees</code>. These are, however, the static equivalents to the <code>Turtle</code> class <code>X</code>, <code>Y</code>, and <code>AngleInDegrees</code> properties. Keep in mind that in C#, a property is nothing but syntactic sugar over one (or two) IL methods (e.g. <code>get_X()</code>). </p> <p> You can now create a pentuple (a five-tuple) of closures over those five static methods and a single <code>TurtleData</code> object. While you can always do that from scratch, it's illuminating to transform a <code>Turtle</code> into such a tuple, thereby illustrating how that morphism looks: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt;&nbsp;ToTuple() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TurtleData</span>(<span style="color:blue;">this</span>.X,&nbsp;<span style="color:blue;">this</span>.Y,&nbsp;<span style="color:blue;">this</span>.AngleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;turn&nbsp;=&nbsp;angle&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Turn(data,&nbsp;angle); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;move&nbsp;=&nbsp;distance&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Move(data,&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getX&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetX(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getY&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetY(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getAngle&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetAngleInDegrees(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(turn,&nbsp;move,&nbsp;getX,&nbsp;getY,&nbsp;getAngle); }</pre> </p> <p> This <code>ToTuple</code> method is an instance method on <code>Turtle</code> (I just held it back from the above code listing, in order to list it here instead). It creates a new <code>TurtleData</code> object from its current state, and proceeds to close over it five times - each time delegating the closure implementation to the corresponding static method. Finally, it creates a pentuple of those five closures. </p> <p> You can interact with the pentuple just like it was an object: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>().ToTuple(); turtle.Item2(2); turtle.Item1(90); turtle.Item2(1);</pre> </p> <p> The syntax is essentially the same as before, but clearly, this isn't as readable. You have to remember that <code>Item2</code> contains the <code>move</code> closure, <code>Item1</code> the <code>turn</code> closure, and so on. Still, since they are all delegates, you can call them as though they are methods. </p> <p> I'm not trying to convince you that this sort of design is better, or even equivalent, in terms of readability. Clearly, it isn't - at least in C#. The point is, however, that from a perspective of structure, these two models are equivalent. Everything you can do with an object, you can also do with a tuple of closures. </p> <p> So far, you've seen that you can translate a <code>Turtle</code> into a tuple of closures, but in order to be an isomorphism, the reverse translation should also be possible. </p> <p> One way to translate from <code>TurtleData</code> to <code>Turtle</code> is with this static method (i.e. function): </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Turtle</span>&nbsp;ToTurtle(<span style="color:#2b91af;">TurtleData</span>&nbsp;data) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Turtle</span>(data.x,&nbsp;data.y,&nbsp;data.angleInDegrees); }</pre> </p> <p> Another option for making the pentuple of closures look like an object is to extract an interface from the original <code>Turtle</code> class: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">ITurtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} }</pre> </p> <p> Not only can you let <code>Turtle</code> implement this interface (<code>public class Turtle : ITurtle</code>), but you can also define an <a href="https://en.wikipedia.org/wiki/Adapter_pattern">Adapter</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">TupleTurtle</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ITurtle</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imp; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;TupleTurtle( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt;&nbsp;imp) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp&nbsp;=&nbsp;imp; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Turn(<span style="color:blue;">double</span>&nbsp;angleInDegrees) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp.Item1(angleInDegrees); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Move(<span style="color:blue;">double</span>&nbsp;distance) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.imp.Item2(distance); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;X &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item3();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;Y &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item4();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">double</span>&nbsp;AngleInDegrees &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.imp.Item5();&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This class simply delegates all its behaviour to the implementing pentuple. It can be used like this with no loss of readability: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;turtle&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TupleTurtle</span>(<span style="color:#2b91af;">TurtleData</span>.CreateDefault()); turtle.Move(2); turtle.Turn(90); turtle.Move(1);</pre> </p> <p> This example utilises this creation function: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;,&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;CreateDefault() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;data&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">TurtleData</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;turn&nbsp;=&nbsp;angle&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Turn(data,&nbsp;angle); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Action</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;move&nbsp;=&nbsp;distance&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.Move(data,&nbsp;distance); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getX&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetX(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getY&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetY(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:blue;">double</span>&gt;&nbsp;getAngle&nbsp;=&nbsp;()&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">TurtleData</span>.GetAngleInDegrees(data); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Tuple</span>.Create(turn,&nbsp;move,&nbsp;getX,&nbsp;getY,&nbsp;getAngle); }</pre> </p> <p> This function is almost identical to the above <code>ToTuple</code> method, and those two could easily be refactored to a single method. </p> <p> This example demonstrates how an object can also be viewed as a tuple of closures, and that translations exist both ways between those two views. </p> <h3 id="74da051e30dc457dac7c3bcd9c11686a"> Conclusion <a href="#74da051e30dc457dac7c3bcd9c11686a" title="permalink">#</a> </h3> <p> To be clear, I'm not trying to convince you that it'd be great if you wrote all of your C# or Java using tuples of closures; it most likely wouldn't be. The point is that a class is isomorphic to a tuple of functions. </p> <p> From <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a>, and particular its application to Haskell, we know quite a bit about the properties of certain functions. Once we start to look at objects as tuples of functions, we may be able to say something about the properties of objects, because category theory also has something to say about the properties of tuples (for example that a tuple of <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a> is <a href="http://blog.ploeh.dk/2017/10/30/tuple-monoids">itself a monoid</a>). </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism">Abstract class isomorphism</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Uncurry isomorphisms http://blog.ploeh.dk/2018/02/05/uncurry-isomorphisms 2018-02-05T07:54:00+00:00 Mark Seemann <div id="post"> <p> <em>Curried functions are isomorphic to tupled functions.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. <strong>Nota bene:</strong> it's <em>not</em> about <a href="https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence">Curry–Howard isomorphism</a>. In order to prevent too much confusion, I chose the title <em>Uncurry isomorphism</em> over <em>Curry isomorphism</em>. </p> <p> The <a href="https://www.haskell.org">Haskell</a> base library includes two functions called <code>curry</code> and <code>uncurry</code>, and for anyone aware of them, it should be no surprise that they are each others' inverses. This is another important software design isomorphism, because in the previous article, you saw that <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">all methods can be represented in tupled form</a>. The current isomorphism then extends that result because tupled and curried forms are isomorphic. </p> <h3 id="802dc6627a004cdcb47f727165f6cef0"> An F# introduction to curry and uncurry <a href="#802dc6627a004cdcb47f727165f6cef0" title="permalink">#</a> </h3> <p> While Haskell programmers are likely to be familiar with <code>curry</code> and <code>uncurry</code>, developers more familiar with other languages may not know them well. In this section follows an introduction in <a href="http://fsharp.org">F#</a>. Haskellers can skip it if they like. </p> <p> In F#, you often have to interoperate with code written in C#, and as the previous article explained, all such methods look to F# like functions taking a single tuple as input. Sometimes, however, you'd wish they were curried. </p> <p> This little function can help with that: </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;*&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c)&nbsp;-&gt;&nbsp;&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c</span> <span style="color:blue;">let</span>&nbsp;<span style="color:navy;">curry</span>&nbsp;<span style="color:navy;">f</span>&nbsp;x&nbsp;y&nbsp;=&nbsp;<span style="color:navy;">f</span>&nbsp;(x,&nbsp;y)</pre> </p> <p> You'll probably have to look at it for a while, and perhaps play with it, before it clicks, but it does this: it takes a function (<code>f</code>) that takes a tuple (<code>'a * 'b</code>) as input, and returns a new function that does the same, but instead takes the arguments in curried form: <code>'a -&gt; 'b -&gt; 'c</code>. </p> <p> It can be useful in interoperability scenarios. Imagine, as a toy example, that you have to list the powers of two from 0 to 10. You can use <a href="https://msdn.microsoft.com/en-us/library/system.math.pow">Math.Pow</a>, but since it was designed with C# in mind, its argument is a single tuple. <code>curry</code> to the rescue: </p> <p> <pre>&gt; List.map (curry Math.Pow 2.) [0.0..10.0];; val it : float list = [1.0; 2.0; 4.0; 8.0; 16.0; 32.0; 64.0; 128.0; 256.0; 512.0; 1024.0]</pre> </p> <p> While <code>Math.Pow</code> has the type <code>float * float -&gt; float</code>, <code>curry Math.Pow</code> turns it into a function with the type <code>float -&gt; float -&gt; float</code>. Since that function is curried, it can be partially applied with the value <code>2.</code>, which returns a function of the type <code>float -&gt; float</code>. That's a function you can use with <code>List.map</code>. </p> <p> You'd hardly be surprised that you can also <code>uncurry</code> a function: </p> <p> <pre><span style="color:green;">//&nbsp;(&#39;a&nbsp;-&gt;&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c)&nbsp;-&gt;&nbsp;&#39;a&nbsp;*&nbsp;&#39;b&nbsp;-&gt;&nbsp;&#39;c</span> <span style="color:blue;">let</span>&nbsp;<span style="color:navy;">uncurry</span>&nbsp;<span style="color:navy;">f</span>&nbsp;(x,&nbsp;y)&nbsp;=&nbsp;<span style="color:navy;">f</span>&nbsp;x&nbsp;y</pre> </p> <p> This function takes a curried function <code>f</code>, and returns a new function that does the same, but instead takes a tuple as input. </p> <h3 id="276c1e476f7c4f9fadff82bca9617e0f"> Pair isomorphism <a href="#276c1e476f7c4f9fadff82bca9617e0f" title="permalink">#</a> </h3> <p> Haskell comes with <code>curry</code> and <code>uncurry</code> as part of its standard library. It hardly comes as a surprise that they form an isomorphism. You can demonstrate this with some <a href="https://hackage.haskell.org/package/QuickCheck">QuickCheck</a> properties. </p> <p> If you have a curried function, you should be able to first <code>uncurry</code> it, then <code>curry</code> that function, and that function should be the same as the original function. In order to demonstrate that, I chose the <code>(&lt;&gt;)</code> operator from <code>Data.Semigroup</code>. Recall that Haskell operators are curried functions. This property function demonstrates the round-trip property of <code>uncurry</code> and <code>curry</code>: </p> <p> <pre><span style="color:#600277;">semigroup2RoundTrips</span>&nbsp;::&nbsp;(<span style="color:blue;">Semigroup</span>&nbsp;a,&nbsp;<span style="color:blue;">Eq</span>&nbsp;a)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Bool semigroup2RoundTrips&nbsp;x&nbsp;y&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;x&nbsp;<span style="color:#666666;">&lt;&gt;</span>&nbsp;y&nbsp;<span style="color:#666666;">==</span>&nbsp;curry&nbsp;(uncurry&nbsp;<span style="color:#600277;">(&lt;&gt;)</span>)&nbsp;x&nbsp;y </pre> </p> <p> This property states that the result of combining two <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a> values is the same as first uncurrying <code>(&lt;&gt;)</code>, and then 'recurry' it. It passes for various <code>Semigroup</code> instances: </p> <p> <pre>testProperty&nbsp;<span style="color:#a31515;">&quot;All&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">All</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">All</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Any&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Any</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Any</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;First&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">First</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">First</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Last&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Last</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Last</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Sum&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Sum</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Sum</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>), testProperty&nbsp;<span style="color:#a31515;">&quot;Product&nbsp;round-trips&quot;</span>&nbsp;(semigroup2RoundTrips&nbsp;<span style="color:#666666;">::</span>&nbsp;<span style="color:#dd0000;">Product</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Product</span>&nbsp;<span style="color:#dd0000;">Int</span>&nbsp;<span style="color:#666666;">-&gt;</span>&nbsp;<span style="color:#dd0000;">Bool</span>) </pre> </p> <p> It's not a formal proof that all of these properties pass, but it does demonstrate the isomorphic nature of these two functions. In order to be truly isomorphic, however, you must also be able to start with a tupled function. In order to have a similar tupled function, I defined this: </p> <p> <pre><span style="color:#600277;">t2sg</span>&nbsp;::&nbsp;<span style="color:blue;">Semigroup</span>&nbsp;a&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;(a,&nbsp;a)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a t2sg&nbsp;(x,&nbsp;y)&nbsp;<span style="color:#666666;">=</span>&nbsp;x&nbsp;<span style="color:#666666;">&lt;&gt;</span>&nbsp;y</pre> </p> <p> The <em>t2</em> in the name stands for <em>tuple-2</em>, and <em>sg</em> means <em>semigroup</em>. It really only exposes <code>(&lt;&gt;)</code> in tupled form. With it, though, you can write another property that demonstrates that the mapping starting with a tupled form is also an isomorphism: </p> <p> <pre><span style="color:#600277;">pairedRoundTrips</span>&nbsp;::&nbsp;(<span style="color:blue;">Semigroup</span>&nbsp;a,&nbsp;<span style="color:blue;">Eq</span>&nbsp;a)&nbsp;<span style="color:blue;">=&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;Bool pairedRoundTrips&nbsp;x&nbsp;y&nbsp;<span style="color:#666666;">=</span> &nbsp;&nbsp;t2sg&nbsp;(x,&nbsp;y)&nbsp;<span style="color:#666666;">==</span>&nbsp;uncurry&nbsp;(curry&nbsp;t2sg)&nbsp;(x,&nbsp;y) </pre> </p> <p> You can create properties for the same instances of <code>Semigroup</code> as the above list for <code>semigroup2RoundTrips</code>, and they all pass as well. </p> <h3 id="5011c10f550d44a78b5fbafd12df999f"> Triplet isomorphism <a href="#5011c10f550d44a78b5fbafd12df999f" title="permalink">#</a> </h3> <p> <code>curry</code> and <code>uncurry</code> only works for pairs (two-tuples) and functions that take exactly two curried arguments. What if you have a function that takes three curried arguments, or a function that takes a triplet (three-tuple) as an argument? </p> <p> First of all, while they aren't built-in, you can easily define corresponding mappings for those as well: </p> <p> <pre><span style="color:#600277;">curry3</span>&nbsp;::&nbsp;((a,&nbsp;b,&nbsp;c)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;b&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;c&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d curry3&nbsp;f&nbsp;x&nbsp;y&nbsp;z&nbsp;<span style="color:#666666;">=</span>&nbsp;f&nbsp;(x,&nbsp;y,&nbsp;z) <span style="color:#600277;">uncurry3</span>&nbsp;::&nbsp;(a&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;b&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;c&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;(a,&nbsp;b,&nbsp;c)&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;d uncurry3&nbsp;f&nbsp;(x,&nbsp;y,&nbsp;z)&nbsp;<span style="color:#666666;">=</span>&nbsp;f&nbsp;x&nbsp;y&nbsp;z </pre> </p> <p> These form an isomorphism as well. </p> <p> More generally, though, you can represent a triplet <code>(a, b, c)</code> as a nested pair: <code>(a, (b, c))</code>. These two representations are also isomorphic, as is <code>(a, b, c, d)</code> with <code>(a, (b, (c, d)))</code>. In other words, you can represent any n-tuple as a nested pair, and you already know that a function taking a pair as input is isomorphic to a curried function. </p> <h3 id="16541c1b69804d76a725715547ece986"> Summary <a href="#16541c1b69804d76a725715547ece986" title="permalink">#</a> </h3> <p> From <a href="https://en.wikipedia.org/wiki/Abstract_algebra">abstract algebra</a>, and particularly its application to a language like Haskell, we have mathematical abstractions over computation - semigroups, for example! In Haskell, these abstractions are often represented in curried form. If we wish to learn about such abstractions, and see if we can use them in object-oriented programming as well, we need to translate the curried representations into something more closely related to object-oriented programming, such as C# or Java. </p> <p> The present article describes how functions in curried form are equivalent to functions that take a single tuple as argument, and in a <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">previous article</a>, you saw how such functions are isomorphic to C# or Java methods. These equivalences provide a bridge that enables us to take what we've learned about abstract algebra and <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a>, and bring them to object-oriented programming. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">Object isomorphisms</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Argument list isomorphisms http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms 2018-01-29T07:23:00+00:00 Mark Seemann <div id="post"> <p> <em>There are many ways to represent an argument list. An overview for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. </p> <p> Most programming languages enable you to pass arguments to operations. In C# and Java, you declare methods with a list of arguments: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Bar(<span style="color:#2b91af;">Baz</span>&nbsp;baz,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux)</pre> </p> <p> Here, <code>baz</code> and <code>qux</code> are arguments to the <code>Bar</code> method. Together, the arguments for a method is called an <em>argument list</em>. To be clear, this isn't universally adopted terminology, but is what I'll be using in this article. Sometimes, people (including me) say <em>parameter</em> instead of <em>argument</em>, and I'm not aware of any formal specification to differentiate the two. </p> <p> While you can pass arguments as a flat list, you can also model them as parameter objects or tuples. These representations are equivalent, because lossless translations between them exist. We say that they are isomorphic. </p> <h3 id="3d3062e7768547348c90892b94b025a8"> Isomorphisms <a href="#3d3062e7768547348c90892b94b025a8" title="permalink">#</a> </h3> <p> In theory, you can declare a method that takes thousands of arguments. In practice, you should constrain your design to as few arguments as possible. As <a href="http://amzn.to/YPdQDf">Refactoring</a> demonstrates, one way to do that is to <em>Introduce Parameter Object</em>. That, already, teaches us that there's a mapping from a flat argument list to a Parameter Object. Is there an inverse mapping? Do other representations exist? </p> <p> <img src="/content/binary/argument-list-isomorphisms.png" alt="Isomorphisms between the general concept of a product type, and three types of representation: argument lists, parameter objects, and tuples."> </p> <p> There's at least three alternative representations of a group of arguments: <ul> <li>Argument list</li> <li>Parameter Object</li> <li>Tuple</li> </ul> The central concept that they all seem to orbit is what in <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a> is known as a <em>product</em>. In the theory of <a href="https://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data types</a>, this is known as a <em>product type</em>. In short, a product type is a composite of elements, where each element can vary independently of the other elements. For more details, I can recommend <a href="http://tomasp.net">Tomáš Petříček</a>'s introduction to the subject: <a href="http://tomasp.net/blog/types-and-math.aspx">Power of mathematics: Reasoning about functional types</a>. </p> <h3 id="a50c52d2cd9b448b8a9f9213a8eba24f"> Argument list/Parameter Object isomorphism <a href="#a50c52d2cd9b448b8a9f9213a8eba24f" title="permalink">#</a> </h3> <p> Perhaps the best-known mapping from an argument list is the <em>Introduce Parameter Object</em> refactoring described in <em>Refactoring</em>. </p> <p> Since the refactoring is described in detail in the book, I don't want to repeat it all here, but in short, assume that you have a method like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge)</pre> </p> <p> In this case, the method only has two arguments, so the refactoring may not be necessary, but that's not the point. The point is that it's possible to refactor the code to this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">BazParameter</span>&nbsp;arg) </pre> </p> <p> where <code>BazParameter</code> looks like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">BazParameter</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;Qux&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;Corge&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;<span style="color:blue;">set</span>;&nbsp;} }</pre> </p> <p> In <em>Refactoring</em>, the recipe states that you should make the class immutable, and while that's a good idea (I recommend it!), it's technically not necessary in order to perform the translation, so I omitted it here in order to make the code simpler. </p> <p> You're probably able to figure out how to translate back again. We could call this refactoring <em>Dissolve Parameter Object:</em> <ol> <li>For each field or property in the Parameter Object, add a new method argument to the target method.</li> <li>At all call sites, pass the Parameter Object's field or property value as each of those new arguments.</li> <li>Change the method body so that it uses each new argument, instead of the Parameter Object.</li> <li>Remove the Parameter Object argument, and update call sites accordingly.</li> </ol> You can go back and forth between a 'flat' argument list and a Parameter Object without loss of information, so these two refactorings together form an isomorphism. </p> <p> As an example, consider the <a href="http://blog.ploeh.dk/2017/10/30/tuple-monoids">Roster example from a previous article</a>. The <code>Combine</code> method on the <code>Roster</code> class is implemented like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine(<span style="color:#2b91af;">Roster</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Girls&nbsp;+&nbsp;other.Girls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Boys&nbsp;+&nbsp;other.Boys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Exemptions.Concat(other.Exemptions).ToArray()); }</pre> </p> <p> This method takes an object as a single argument. You can think of this <code>Roster</code> object as a Parameter Object. </p> <p> If you like, you can add a method overload that dissolves the <code>Roster</code> object to its constituent values: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">params</span>&nbsp;<span style="color:blue;">string</span>[]&nbsp;otherExemptions) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Combine( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>(otherGirls,&nbsp;otherBoys,&nbsp;otherExemptions)); }</pre> </p> <p> In this incarnation, the dissolved method overload creates a new <code>Roster</code> from its argument list and delegates to the other overload. This is, however, an arbitrary implementation detail. You could just as well implement the two methods the other way around: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine(<span style="color:#2b91af;">Roster</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Combine( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Girls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Boys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;other.Exemptions.ToArray()); } <span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;Combine( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">int</span>&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">params</span>&nbsp;<span style="color:blue;">string</span>[]&nbsp;otherExemptions) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Girls&nbsp;+&nbsp;otherGirls, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Boys&nbsp;+&nbsp;otherBoys, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Exemptions.Concat(otherExemptions).ToArray()); }</pre> </p> <p> In this variation, the overload that takes three arguments contains the implementation, whereas the <code>Combine(Roster)</code> overload simply delegates to the <code>Combine(int, int, string[])</code> overload. </p> <p> In order to illustrate the idea that both APIs are equivalent, in this example I show two method overloads side by side. The overall point, however, is that you can translate between such two representations without changing the behaviour of the system. You don't have to keep both method overloads in place together. </p> <h3 id="97ea8f87723f4b1bb995b0824b1caba4"> Argument list/tuple isomorphism <a href="#97ea8f87723f4b1bb995b0824b1caba4" title="permalink">#</a> </h3> <p> In relationship to statically typed functional programming, the term <em>argument list</em> is confounding. In the functional programming languages I've so far dabbled with (<a href="http://fsharp.org">F#</a>, <a href="https://www.haskell.org">Haskell</a>, <a href="http://www.purescript.org">PureScript</a>, <a href="https://clojure.org">Clojure</a>, <a href="https://www.erlang.org">Erlang</a>), the word <em>list</em> is used synonymously with <a href="https://en.wikipedia.org/wiki/Linked_list">linked list</a>. </p> <p> As a data type, a linked list can hold an arbitrary number of elements. (In Haskell, it can even be infinite, because Haskell is lazily evaluated.) Statically typed languages like F# and Haskell add the constraint that all elements must have the same type. </p> <p> An argument list like <code>(Qux qux, Corge corge)</code> isn't at all a statically typed linked list. Neither does it have an arbitrary size nor does it contain elements of the same type. On the contrary, it has a fixed length (two), and elements of different types. The first element must be a <code>Qux</code> value, and the second element must be a <code>Corge</code> value. </p> <p> That's not a list; that's a tuple. </p> <p> Surprisingly, Haskell may provide the most digestible illustration of that, even if you don't know how to read Haskell syntax. Suppose you have the values <code>qux</code> and <code>corge</code>, of similarly named types. Consider a C# method call <code>Baz(qux, corge)</code>. What's the type of the 'argument list'? </p> <p> <pre>λ&gt; :type (qux, corge) (qux, corge) :: (Qux, Corge)</pre> </p> <p> <code>:type</code> is a <a href="https://wiki.haskell.org/GHC/GHCi">GHCi</a> command that displays the type of an expression. By coincidence (or is it?), the C# argument list <code>(qux, corge)</code> is also valid Haskell syntax, but it is syntax for a tuple. In this example, the tuple is a <em>pair</em> where the first element has the type <code>Qux</code>, and the second element has the type <code>Corge</code>, but <code>(foo, qux, corge)</code> would be a triple, <code>(foo, qux, corge, grault)</code> would be a quadruple, and so on. </p> <p> We know that the argument list/tuple isomorphism exists, because that's how the F# compiler works. F# is a multi-paradigmatic language, and it can interact with C# code. It does that by treating all C# argument lists as tuples. Consider this example of calling <a href="https://msdn.microsoft.com/en-us/library/system.math.pow">Math.Pow</a>: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>(2.,&nbsp;4.)</pre> </p> <p> Programmers who still write more C# than F# often write it like that, because it looks like a method call, but I prefer to insert a space between the method and the arguments: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;(2.,&nbsp;4.)</pre> </p> <p> The reason is that in F#, function calls are delimited with space. The brackets are there in order to override the normal operator precedence, just like you'd write <code>(1 + 2) * 3</code> in order to get <code>9</code> instead of <code>7</code>. This is better illustrated by introducing an intermediate value: </p> <p> <pre><span style="color:blue;">let</span>&nbsp;t&nbsp;=&nbsp;(2.,&nbsp;4.) <span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;t</pre> </p> <p> or even </p> <p> <pre><span style="color:blue;">let</span>&nbsp;t&nbsp;=&nbsp;2.,&nbsp;4. <span style="color:blue;">let</span>&nbsp;i&nbsp;=&nbsp;<span style="color:teal;">Math</span>.<span style="color:navy;">Pow</span>&nbsp;t</pre> </p> <p> because the brackets are now redundant. In the last two examples, <code>t</code> is a tuple of two floating-point numbers. All four code examples are equivalent and compile, thereby demonstrating that a translation exist from F# tuples to C# argument lists. </p> <p> The inverse translation exists as well. You can see a demonstration of this in the (dormant) <a href="https://github.com/ploeh/Numsense">Numsense</a> code base, which includes an object-oriented <a href="https://en.wikipedia.org/wiki/Facade_pattern">Façade</a>, which defines (among other things) an interface where the <code>TryParse</code> method takes a tuple argument. Here's the declaration of that method: </p> <p> <pre><span style="color:blue;">abstract</span>&nbsp;<span style="color:navy;">TryParse</span>&nbsp;:&nbsp;s&nbsp;:&nbsp;<span style="color:teal;">string</span>&nbsp;*&nbsp;[&lt;<span style="color:teal;">Out</span>&gt;]result&nbsp;:&nbsp;<span style="color:teal;">int</span>&nbsp;<span style="color:teal;">byref</span>&nbsp;<span style="color:blue;">-&gt;</span>&nbsp;<span style="color:teal;">bool</span></pre> </p> <p> That looks cryptic, but if you remove the <code>[&lt;Out&gt;]</code> annotation and the argument names, the method is declared as taking <em>single</em> input value of the type <code>string * int byref</code>. It's a single value, but it's a tuple (a pair). </p> <p> Perhaps it's easier to understand if you see an implementation of this interface method, so here's the English implementation: </p> <p> <pre><span style="color:blue;">member</span>&nbsp;this.<span style="color:navy;">TryParse</span>&nbsp;(s,&nbsp;result)&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:teal;">Helper</span>.<span style="color:navy;">tryParse</span>&nbsp;<span style="color:teal;">Numeral</span>.<span style="color:navy;">tryParseEnglish</span>&nbsp;(s,&nbsp;&amp;result)</pre> </p> <p> You can see that, as I've described above, I've inserted a space between <code>this.TryParse</code> and <code>(s, result)</code>, in order to highlight that this is an F# function that takes a single tuple as input. </p> <p> In C#, however, you can use the method as though it had a standard C# argument list: </p> <p> <pre><span style="color:blue;">int</span>&nbsp;i; <span style="color:blue;">var</span>&nbsp;success&nbsp;=&nbsp;<span style="color:#2b91af;">Numeral</span>.English.TryParse( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#a31515;">&quot;one-thousand-three-hundred-thirty-seven&quot;</span>, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">out</span>&nbsp;i);</pre> </p> <p> You'll note that this is an advanced example that involves an <code>out</code> parameter, but even in this edge case, the translation is possible. </p> <p> C# argument lists and F# tuples are isomorphic. I'd be surprised if this result doesn't extend to other languages. </p> <h3 id="7302293f4f3947cfbf97b328edc34e54"> Parameter Object/tuple isomorphism <a href="#7302293f4f3947cfbf97b328edc34e54" title="permalink">#</a> </h3> <p> The third isomorphism that I claim exists is the one between Parameter Objects and tuples. If, however, we assume that the two above isomorphisms hold, then this third isomorphism exists as well. I know from my copy of <a href="http://amzn.to/13tGJ0f">Conceptual Mathematics</a> that isomorphisms are transitive. If you can translate from Parameter Object to argument list, and from argument list to tuple, then you can translate from Parameter Object to tuple; and vice versa. </p> <p> Thus, I'm not going to use more words on this isomorphism. </p> <h3 id="2afad24d481348ecbc0bc08c4e5b82bb"> Summary <a href="#2afad24d481348ecbc0bc08c4e5b82bb" title="permalink">#</a> </h3> <p> Argument lists, Parameter Objects, and tuples are isomorphic. This has a few interesting implications, first of which is that because all these refactorings exist, you can employ them. If a method's argument list is inconvenient, consider introducing a Parameter Object. If your Parameter Object starts to look <a href="http://blog.ploeh.dk/2015/08/17/when-x-y-and-z-are-great-variable-names">so generic that you have a hard time coming up with good names for its elements</a>, perhaps a tuple is more appropriate. On the other hand, if you have a tuple, but it's unclear what role each unnamed element plays, consider refactoring to an argument list or Parameter Object. </p> <p> Another important result is that since these three ways to model arguments are isomorphic, we can treat them as interchangeable in analysis. For instance, from category theory we can learn about the properties of tuples. These properties, then, also apply to C# and Java argument lists. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/02/05/uncurry-isomorphisms">Uncurry isomorphisms</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Function isomorphisms http://blog.ploeh.dk/2018/01/22/function-isomorphisms 2018-01-22T14:37:00+00:00 Mark Seemann <div id="post"> <p> <em>Instance methods are isomorphic to functions.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. </p> <p> While I have already, in <a href="http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional">an earlier article</a>, quoted the following parable about Anton, Qc Na, objects, and closures, it's too good a fit to the current topic to pass up, so please pardon the duplication. </p> <blockquote> <p> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." </p> <p> Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. </p> <p> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. </p> <p> - <a href="http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html">Anton van Straaten</a> </p> </blockquote> <p> The point is that objects and closures are two ways of looking at a thing. In a nutshell, objects are data with behaviour, whereas closures are behaviour with data. I've <a href="http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional">already shown an elaborate C# example of this</a>, so in this article, you'll get a slightly more formal treatment of the subject. </p> <h3 id="a9dcce40867242509b9ed82b3bb71481"> Isomorphism <a href="#a9dcce40867242509b9ed82b3bb71481" title="permalink">#</a> </h3> <p> In object-oriented design, you often bundle operations as methods that belong to objects. These are isomorphic to static methods, because a lossless translation exists. We can call such static methods <em>functions</em>, although they aren't guaranteed to be <a href="https://en.wikipedia.org/wiki/Pure_function">pure</a>. </p> <p> <img src="/content/binary/function-isomorphism.png" alt="Diagram showing isomorphism between instance method and function."> </p> <p> In the spirit of <a href="http://amzn.to/YPdQDf">Refactoring</a>, we can describe each translation as a refactoring, because that's what it is. I don't think the book contains a specific refactoring that describes how to translate from an instance method to a static method, but we could call it <em>Replace Object with Argument</em>. </p> <p> Going the other way is, on the other hand, already described, so we can use Refactoring's <em>Move Method</em>. </p> <h3 id="e8be3efbe29e44dc97d5dd8ecd2928c2"> Replace Object with Argument <a href="#e8be3efbe29e44dc97d5dd8ecd2928c2" title="permalink">#</a> </h3> <p> While the concept of refactoring ought to be neutral across paradigms, the original book is about object-oriented programming. In object-oriented programming, objects are the design ideal, so it didn't make much sense to include, in the book, a refactoring that turns an instance method into a static method. </p> <p> Nevertheless, it's straightforward: <ol> <li>Add an argument to the instance method. Declare the argument as the type of the hosting class.</li> <li>In the method body, change all calls to <code>this</code> and <code>base</code> to the new argument.</li> <li>Make the method static.</li> </ol> As an example, imagine that you start with an instance method like this <code>Baz</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Other&nbsp;members...</span> }</pre> </p> <p> You'll first introduce a new <code>Foo foo</code> argument to <code>Baz</code>, change the method body to use <code>foo</code> instead of <code>this</code>, and then make the method static. The result is this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Foo</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:#2b91af;">Foo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Other&nbsp;members...</span> }</pre> </p> <p> Once you have a static method, you can always move it to another class, if you'd like. This can, however, cause some problems with accessibility. In C#, for example, you'd no longer be able to access <code>private</code> or <code>protected</code> members from a method outside the class. You can choose to leave the static method reside on the original class, or you can make the member in question available to more clients (make it <code>internal</code> or <code>public</code>). </p> <h3 id="aa46d8dc81e844f6bb0691c0fcb4db91"> Move Method <a href="#aa46d8dc81e844f6bb0691c0fcb4db91" title="permalink">#</a> </h3> <p> The book Refactoring doesn't contain a recipe like the above, because the goal of that book is better object-oriented design. It would consider a static method, like the second variation of <code>Baz</code> above, a code smell named <em>Feature Envy</em>. You have this code smell when it looks as if a method is more interested in one of its arguments than in its host object. In that case, the book suggests using the <em>Move Method</em> refactoring. </p> <p> The book already describes this refactoring, so I'm not going to repeat it here. Also, there's no sense in showing you the code example, because it's literally the same two code examples as above, only in the opposite order. You start with the static method and end with the instance method. </p> <p> C# developers are most likely already aware of this relationship between static methods and objects, because you can use the <code>this</code> keyword in a static method to make it look like an instance method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Bar</span>&nbsp;Baz(<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;foo,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux,&nbsp;<span style="color:#2b91af;">Corge</span>&nbsp;corge) </pre> </p> <p> The addition of <code>this</code> in front of the <code>Foo foo</code> argument enables the C# compiler to treat the <code>Baz</code> method as though it's an instance method on a <code>Foo</code>object: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;bar&nbsp;=&nbsp;foo.Baz(qux,&nbsp;corge);</pre> </p> <p> This is only syntactic sugar. The method is still compiled as a static method, and if you, as a client developer, wish to use it as a static method, that's still possible. </p> <h3 id="cc678b065323453f96a9a16b8576a14d"> Functions <a href="#cc678b065323453f96a9a16b8576a14d" title="permalink">#</a> </h3> <p> A static method like <code>public static Bar Baz(Foo foo, Qux qux, Corge corge)</code> looks a lot like a function. If refactored from object-oriented design, that function is likely to be impure, but its shape is function-like. </p> <p> In C#, for example, you could model it as a variable of a delegate type: </p> <p> <pre><span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Foo</span>,&nbsp;<span style="color:#2b91af;">Qux</span>,&nbsp;<span style="color:#2b91af;">Corge</span>,&nbsp;<span style="color:#2b91af;">Bar</span>&gt;&nbsp;baz&nbsp;=&nbsp;(foo,&nbsp;qux,&nbsp;corge)&nbsp;=&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff,&nbsp;return&nbsp;bar</span> };</pre> </p> <p> Here, <code>baz</code> is a function with the same signature as the above static <code>Baz</code> method. </p> <p> Have you ever noticed something odd about the various <code>Func</code> delegates in C#? </p> <p> They take the return type as the <em>last</em> type argument, which is contrary to C# syntax, where you have to declare the return type before the method name and argument list. Since C# is the dominant .NET language, that's surprising, and even counter-intuitive. </p> <p> It does, however, nicely align with an ML language like <a href="http://fsharp.org">F#</a>. As we'll see in a future article, the above <code>baz</code> function translates to an F# function with the type <code>Foo * Qux * Corge -&gt; Bar</code>, and to <a href="https://www.haskell.org">Haskell</a> as a function with the type <code>(Foo, Qux, Corge) -&gt; Bar</code>. Notice that the return type comes last, just like in the C# <code>Func</code>. </p> <h3 id="daef5921b96646258260c0c18cee856f"> Closures <a href="#daef5921b96646258260c0c18cee856f" title="permalink">#</a> </h3> <p> <em>...but,</em> you may say, <em>what about data with behaviour?</em> One of the advantages, after all, of objects is that you can associate a particular collection of data with some behaviour. The above <code>Foo</code> class could have data members, and you may sometimes have a need for passing both data and behaviour around as a single... well... <em>object</em>. </p> <p> That seems to be much harder with a static <code>Baz</code> method. </p> <p> Don't worry, write a closure: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;foo&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;{&nbsp;<span style="color:green;">/*&nbsp;initialize&nbsp;members&nbsp;here&nbsp;*/</span>&nbsp;}; <span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Qux</span>,&nbsp;<span style="color:#2b91af;">Corge</span>,&nbsp;<span style="color:#2b91af;">Bar</span>&gt;&nbsp;baz&nbsp;=&nbsp;(qux,&nbsp;corge)&nbsp;=&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Do&nbsp;stuff&nbsp;with&nbsp;foo,&nbsp;qux,&nbsp;and&nbsp;corge;&nbsp;return&nbsp;bar</span> };</pre> </p> <p> In this variation, <code>baz</code> closes over <code>foo</code>. Inside the function body, you can use <code>foo</code> like you can use <code>qux</code> and <code>corge</code>. As I've <a href="http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional">already covered in an earlier article</a>, the C# compiler compiles this to an IL class, making it even more obvious that objects and closures are two sides of the same coin. </p> <h3 id="73c4fa8bdc3240608d80bb0817af80a2"> Summary <a href="#73c4fa8bdc3240608d80bb0817af80a2" title="permalink">#</a> </h3> <p> Object-oriented instance methods are isomorphic to both static methods and function values. The translations that transforms your code from one to the other are <em>refactorings</em>. Since you can move in both directions without loss of information, these refactorings constitute an isomorphism. </p> <p> This is another important result about the relationship between object-oriented design and functional programming, because this enables us to reduce any method to a canonical form, in the shape of a function. From a language like Haskell, we know a lot about the relationship between category theory and functional programming. With isomorphisms like the present, we can begin to extend that knowledge to object-oriented design. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">Argument list isomorphisms</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Unit isomorphisms http://blog.ploeh.dk/2018/01/15/unit-isomorphisms 2018-01-15T07:33:00+00:00 Mark Seemann <div id="post"> <p> <em>The C# and Java keyword 'void' is isomorphic to a data type called 'unit'.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms">a series of articles about software design isomorphisms</a>. </p> <p> Many programming languages, such as C# and Java, distinguish between methods that return something, and methods that don't return anything. In C# and Java, a method must be declared with a return type, but if it doesn't return anything, you can use the special keyword <code>void</code> to indicate that this is the case: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Foo(<span style="color:blue;">int</span>&nbsp;bar)</pre> </p> <p> This is a C# example, but it would look similar (isomorphic?) in Java. </p> <h3 id="ed0cfa4cffe640fb91d0ee6eb8513408"> Two kinds of methods <a href="#ed0cfa4cffe640fb91d0ee6eb8513408" title="permalink">#</a> </h3> <p> In C# and Java, <code>void</code> isn't a type, but a keyword. This means that there are two distinct types of methods: <ul> <li>Methods that return something</li> <li>Methods that return nothing</li> </ul> In C#, methods that return something declare their return type before the method name: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Bar(<span style="color:#2b91af;">Baz</span>&nbsp;baz,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux)</pre> </p> <p> On the other hand, methods that return nothing must use the special <code>void</code> keyword: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Bar(<span style="color:#2b91af;">Baz</span>&nbsp;baz,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux)</pre> </p> <p> If you want to generalise, you can use generics like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Foo&lt;<span style="color:#2b91af;">T</span>,&nbsp;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>&gt;(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y)</pre> </p> <p> Such a method could return <em>anything</em>, but, surprisingly, not <em>nothing</em>. In C# and Java, <em>nothing</em> is special. You can't generalise all methods to a common set. Even with generics, you must model methods that return nothing in a different way: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Foo&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T2</span>&gt;(<span style="color:#2b91af;">T1</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T2</span>&nbsp;y)</pre> </p> <p> In C#, for example, this leads to the distinction between <a href="https://msdn.microsoft.com/en-us/library/bb549151">Func</a> and <a href="https://msdn.microsoft.com/en-us/library/018hxwa8">Action</a>. You can't reconcile these two fundamentally distinct types of methods into one. </p> <p> Visual Basic .NET makes the same distinction, but uses the keywords <code>Sub</code> and <code>Function</code> instead of <code>void</code>. </p> <p> Sometimes, particularly when writing code with generics, this dichotomy is really annoying. Wouldn't it be nice to be able to generalise all methods? </p> <h3 id="f2edc83a82bb40bbaf52c5e313b54770"> Unit <a href="#f2edc83a82bb40bbaf52c5e313b54770" title="permalink">#</a> </h3> <p> While I don't recall the source, I've read somewhere the suggestion that the keyword <code>void</code> was chosen to go with <code>null</code>, because <em>null and void</em> is an English (legal) idiom. That choice is, however, unfortunate. </p> <p> In <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a>, the term <em>void</em> denotes a type or set with <em>no</em> inhabitants (e.g. an empty set). That sounds like the same concept. The problem, from a programming perspective, is that if you have a (static) type with no inhabitants, you can't create an instance of it. See <a href="https://bartoszmilewski.com">Bartosz Milewski</a>'s article <a href="https://bartoszmilewski.com/2014/11/24/types-and-functions">Types and Functions</a> for a great explanation and more details. </p> <p> Functional programming languages like <a href="http://fsharp.org">F#</a> and <a href="https://www.haskell.org">Haskell</a> instead model <em>nothing</em> by a type called <em>unit</em> (often rendered as empty brackets: <code>()</code>). This type is a type with exactly one inhabitant, a bit like a <a href="https://en.wikipedia.org/wiki/Singleton_pattern">Singleton</a>, but with the extra restriction that the inhabitant carries no information. It simply is. </p> <p> It may sound strange and counter-intuitive that a singleton value represents <em>nothing</em>, but it turns out that this is, indeed, isomorphic to C# or Java's <code>void</code>. </p> <p> This is admirably illustrated by F#, which consistently uses <code>unit</code> instead of <code>void</code>. F# is a multi-paradigmatic language, so you can write classes with methods as well as functions: </p> <p> <pre><span style="color:blue;">member</span>&nbsp;<span style="color:#9d9d9d;">this</span>.<span style="color:navy;">Bar</span>&nbsp;(<span style="color:#9d9d9d;">x</span>&nbsp;:&nbsp;<span style="color:teal;">int</span>)&nbsp;=&nbsp;()</pre> </p> <p> This <code>Bar</code> method has the return type <code>unit</code>. When you compile F# code, it becomes <a href="https://en.wikipedia.org/wiki/Common_Intermediate_Language">Intermediate Language</a>, which you can decompile into C#. If you do that, the above F# code becomes: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;Bar(<span style="color:blue;">int</span>&nbsp;x)</pre> </p> <p> The inverse translation works as well. When you use F#'s interoperability features to interact with objects written in C# or Visual Basic, the F# compiler interprets <code>void</code> methods as if they return <code>unit</code>. For example, calling <a href="https://msdn.microsoft.com/en-us/library/y46kxc5e">GC.Collect</a> returns <code>unit</code> in F#, although C# sees it as 'returning' <code>void</code>: </p> <p> <pre>&gt; GC.Collect 0;; val it : unit = ()</pre> </p> <p> F#'s <code>unit</code> is isomorphic to C#'s <code>void</code> keyword, but apart from that, there's nothing special about it. It's a value like any other, and can be used in generically typed functions, like the built-in <code>id</code> function: </p> <p> <pre>&gt; id 42;; val it : int = 42 &gt; id "foo";; val it : string = "foo" &gt; id ();; val it : unit = ()</pre> </p> <p> The built-in function <code>id</code> simply returns its input argument. It has the type <code>'a -&gt; 'a</code>, and as the above F# Interactive session demonstrates, you can call it with <code>unit</code> as well as with <code>int</code>, <code>string</code>, and so on. </p> <h3 id="4657dbd4b5fc4abda6e8dee2cac67ea9"> Monoid <a href="#4657dbd4b5fc4abda6e8dee2cac67ea9" title="permalink">#</a> </h3> <p> Unit, by the way, forms a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. This is most evident in Haskell, where this is encoded into the type. In general, a monoid is a binary operation, and not a type, but what could the combination of two <code>()</code> (unit) values be, other than <code>()</code>? </p> <p> <pre>λ&gt; mempty :: () () λ&gt; mappend () () ()</pre> </p> <p> In fact, the above (rhetorical) question is imprecise, since there aren't <em>two</em> unit values. There's only one, but used twice. </p> <p> Since only a single <em>unit</em> value exists, any binary operation is automatically associative, because, after all, it can only return <em>unit</em>. Likewise, <em>unit</em> is the identity (<code>mempty</code>) for the operation, because it doesn't change the output. Thus, the monoid laws hold, and <em>unit</em> forms a monoid. </p> <p> This result is interesting when you start to think about composition, because a monoid can always be used to reduce (aggregate) multiple values to a single value. With this result, and unit isomorphism, we've already explained why <a href="http://blog.ploeh.dk/2011/03/22/CommandsareComposable">Commands are composable</a>. </p> <h3 id="8677103c217347c6b40cec336a581aff"> Summary <a href="#8677103c217347c6b40cec336a581aff" title="permalink">#</a> </h3> <p> Since <em>unit</em> is a type only inhabited by a single value, people (including me) often use the word <em>unit</em> about both the type and its only value. Normally, the context surrounding such use is enough to dispel any ambiguity. </p> <p> <em>Unit</em> is isomorphic to C# or Java <code>void</code>. This is an important result, because if we're to study software design and code structure, we don't have to deal with two distinct cases (methods that return nothing, and methods that return something). Instead, we can ignore methods that return nothing, because they can instead be modelled as methods that return <em>unit</em>. </p> <p> The reason I've titled this article in the plural is that you could view the isomorphism between F# <code>unit</code> and C# <code>void</code> as a different isomorphism than the one between C# and Java <code>void</code>. Add Haskell's <code>()</code> (unit) type and Visual Basic's <code>Sub</code> keyword to the mix, and it should be clear that there are many translations to the category theory concept of <em>Unit</em>. </p> <p> <img src="/content/binary/unit-isomorphisms.png" alt="Isormorphisms between the Unit concept and constructs in selected languages: C#, Java, Visual Basic, F#, Haskell."> </p> <p> Unit isomorphism is an example of an interlingual isomorphism, in the sense that C# <code>void</code> maps to F# <code>unit</code>, and vice versa. In the next example, you'll see an isomorphism that mostly stays within a single language, although a translation between languages is also pertinent. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">Function isomorphisms</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Software design isomorphisms http://blog.ploeh.dk/2018/01/08/software-design-isomorphisms 2018-01-08T08:35:00+00:00 Mark Seemann <div id="post"> <p> <em>When programming, you can often express the same concept in multiple ways. If you can losslessly translate between two alternatives, it's an isomorphism. An introduction for object-oriented programmers.</em> </p> <p> This article series is part of <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">an even larger series of articles about the relationship between design patterns and category theory.</a> </p> <p> There's a school of functional programming that looks to <a href="https://en.wikipedia.org/wiki/Category_theory">category theory</a> for inspiration, verification, abstraction, and cross-pollination of ideas. Perhaps you're put off by terms like <a href="https://twitter.com/jamesiry/status/598547781515485184">zygohistomorphic prepromorphism</a> (a joke), but you shouldn't be. There are often <a href="http://blog.ploeh.dk/2015/08/17/when-x-y-and-z-are-great-variable-names">good reasons for using abstract naming</a>. In any case, one term from category theory that occasionally makes the rounds is <em>isomorphism</em>. </p> <h3 id="656b60e2fac7490f833dd2fde9709173"> Equivalence <a href="#656b60e2fac7490f833dd2fde9709173" title="permalink">#</a> </h3> <p> Don't let the terminology daunt you. An <em>isomorphism</em> is an easy enough concept to grasp. In essence, two things are isomorphic if you can translate losslessly back and forth between them. It's a formalisation of <em>equivalence</em>. </p> <p> Many programming languages, like C# and Java, offer a multitude of alternative ways to do things. Just consider this C# example from <a href="https://cleancoders.com/episode/humane-code-real-episode-1/show">my Humane Code video</a>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsSatisfiedBy(<span style="color:#2b91af;">Customer</span>&nbsp;candidate) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">bool</span>&nbsp;retVal; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(candidate.TotalPurchases&nbsp;&gt;=&nbsp;10000) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;retVal&nbsp;=&nbsp;<span style="color:blue;">true</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">else</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;retVal&nbsp;=&nbsp;<span style="color:blue;">false</span>; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;retVal; }</pre> </p> <p> which is equivalent to this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">bool</span>&nbsp;IsSatisfiedBy(<span style="color:#2b91af;">Customer</span>&nbsp;candidate) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;candidate.TotalPurchases&nbsp;&gt;=&nbsp;10000; }</pre> </p> <p> An outside observer can't tell the difference between these two implementations, because they have exactly the same externally visible behaviour. You can always refactor from one implementation to the other without loss of information. Thus, we could claim that they're isomorphic. </p> <h3 id="44e9ca73a4374c188991f292d6c59f0a"> Terminology <a href="#44e9ca73a4374c188991f292d6c59f0a" title="permalink">#</a> </h3> <p> If you're an object-oriented programmer, then you already know the word <a href="https://en.wikipedia.org/wiki/Polymorphism_(computer_science)">polymorphism</a>, which sounds similar to <em>isomorphism</em>. Perhaps you've also heard the word <a href="https://en.wikipedia.org/wiki/Xenomorph">xenomorph</a>. It's all Greek. <em>Morph</em> means <em>form</em> or <em>shape</em>, and while <em>poly</em> means <em>many</em>, <em>iso</em> means <em>equal</em>. So <em>isomorphism</em> means 'being of equal shape'. </p> <p> This is most likely the explanation for the term <a href="https://en.wikipedia.org/wiki/Isomorphic_JavaScript">Isomorphic JavaScript</a>. The people who came up with that term knew (enough) Greek, but apparently not mathematics. In mathematics, and particularly category theory, an isomorphism is a translation with an inverse. That's still not a formal definition, but just my attempt at presenting it without too much jargon. </p> <p> Category theory uses the word <em>object</em> to describe a member of a category. I'm going to use that terminology here as well, but you should be aware that <em>object</em> doesn't imply object-oriented programming. It just means 'thing', 'item', 'element', 'entity', etcetera. </p> <p> In category theory, a <em>morphism</em> is a mapping or translation of an object to another object. If, for all objects, there's an inverse morphism that leads back to the origin, then it's an isomorphism. </p> <p> <img src="/content/binary/isomorphism.png" alt="Isomorphism diagram."> </p> <p> In this illustration, the blue arrows going from left to right indicate a single morphism. It's a mapping of objects on the blue left side to objects on the green right side. The green arrows going from right to left is another morphism. In this case, the green right-to-left morphism is an inverse of the blue left-to-right morphism, because by applying both morphisms, you end where you started. It doesn't matter if you start at the blue left side or the green right side. </p> <p> Another way to view this is to say that a lossless translation exists. When a translation is lossless, it means that you don't lose information by performing the translation. Since all information is still present after a translation, you can go back to the original representation. </p> <h3 id="ccf56c166177427785d71baf7cb7158f"> Software design isomorphisms <a href="#ccf56c166177427785d71baf7cb7158f" title="permalink">#</a> </h3> <p> When programming, you can often solve the same problem in different ways. Sometimes, the alternatives are isomorphic: you can go back and forth between two alternatives without loss of information. </p> <p> <a href="https://martinfowler.com">Martin Fowler</a>'s book <a href="http://amzn.to/YPdQDf">Refactoring</a> contains several examples. For instance, you can apply <em>Extract Method</em> followed by <em>Inline Method</em> and be back where you started. </p> <p> There are many other isomorphisms in programming. Some are morphisms in the same language, as is the case with the above C# example. This is also the case with the isomorphisms in <em>Refactoring</em>, because a refactoring, by definition, is a change applied to a particular code base, be it C#, Java, Ruby, or Python. </p> <p> Other programming isomorphisms go between languages, where a concept can be modelled in one way in, say, C++, but in another way in Clojure. The <a href="http://blog.ploeh.dk">present blog</a>, for instance, contains several examples of translating between C# and <a href="http://fsharp.org">F#</a>, and between F# and <a href="https://www.haskell.org">Haskell</a>. </p> <p> Being aware of software design isomorphisms can make you a better programmer. It'll enable you to select the best alternative for solving a particular problem. Identifying programming isomorphisms is also important because it'll enable us to formally think about code structure by reducing many alternative representations to a canonical representation. For these reasons, this article presents a catalogue of software design isomorphisms: <ul> <li><a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">Unit isomorphisms</a></li> <li><a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">Function isomorphisms</a></li> <li><a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">Argument list isomorphisms</a></li> <li><a href="http://blog.ploeh.dk/2018/02/05/uncurry-isomorphisms">Uncurry isomorphisms</a></li> <li><a href="http://blog.ploeh.dk/2018/02/12/object-isomorphisms">Object isomorphisms</a></li> <li><a href="http://blog.ploeh.dk/2018/02/19/abstract-class-isomorphism">Abstract class isomorphism</a></li> <li><a href="http://blog.ploeh.dk/2018/02/26/inheritance-composition-isomorphism">Inheritance-composition isomorphism</a></li> </ul> In general, I've tried to name each isomorphism after its canonical representation. For instance, by <em>unit isomorphisms</em>, I mean isomorphisms to the unit value. It is, however, not an entirely consistent naming strategy. </p> <p> Many more software design isomorphisms exist, so if you revisit this article in the future, I may have added more items to this catalogue. In no way should you consider this catalogue exhaustive. </p> <h3 id="d23d37f6eea548c7b7873b19e7d79fe4"> Summary <a href="#d23d37f6eea548c7b7873b19e7d79fe4" title="permalink">#</a> </h3> <p> An isomorphism is a mapping for which an inverse mapping also exists. It's a way to describe equivalence. </p> <p> In programming, you often have the choice to implement a particular feature in more than one way. These alternatives may be equivalent, in which case they're isomorphic. That's one of the reasons that many code bases come with a style guide. </p> <p> Understanding how code is isomorphic to other code enables us to reduce many alternatives to a canonical representation. This makes analysis easier, because we can narrow our analysis to the canonical form, and generalise from there. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/01/15/unit-isomorphisms">Unit isomorphisms</a>. </p> </div> <div id="comments"> <hr> <h2 id="comments-header"> Comments </h2> <div class="comment" id="b8af8786402b4fcab0ffffa883304ba2"> <div class="comment-author"><a href="https://github.com/srogovtsev">Sergey Rogovtsev</a></div> <div class="comment-content"> Funny thing, I had a discussion about refactoring as an isomorphism a bit ago. While I like the idea of using isomorphisms to reason about code, I still stand by the point that refactoring is an isomorphism <em>limited to functionality</em>; i.e. refactoring the code may change its other aspects (readability is the first one to come to mind, performance is the second), so two different representations are no longer totally equal. Or, as another argument, using Inline Method in fact loses some information (the descriptive method name, limited variable scopes), so the translation is not (sorry) lossless. </div> <div class="comment-date">2018-01-13 08:39 UTC</div> </div> <div class="comment" id="d32e657ba46c48c4a5df7664d24b5321"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Sergey, thank you for writing. Good point, you're right that viewed as a general-purpose translation, <em>Inline Method</em> is indeed lossy. When you look at the purpose of refactoring code, the motivation is mostly (if not always) to make the code better in some way. Particularly when the purpose is make the code more readable, a refactoring introduces clarity. Thus, going the opposite way would remove that clarity, so I think it's fair to argue that such a change would be lossy. </p> <p> It's perfectly reasonable to view a refactoring like <em>Inline Method</em> as a general-purpose algorithm, in which case you're right that it's lossy. I don't dispute that. </p> <p> My agenda with this article series, however, is different. I'm not trying to make multiple angels dance on a pinhead; it's not my intent to try to redefine the word <em>refactoring</em>. The purpose with this series of articles is to describe how the same behaviour can be implemented in many different ways. The book <em>Refactoring</em> is one source of such equivalent representations. </p> <p> One quality of morphisms is that there can be several translations between two objects. One such translation could be the general-purpose refactoring that you so rightly point out is lossy. Another translation could be one that 'remembers' the name of the original method. </p> <p> Take, as an example, the isomorphism described under the heading <em>Roster isomorphism</em> in my article <a href="http://blog.ploeh.dk/2017/10/30/tuple-monoids">Tuple monoids</a>. When you consider the method <code>ToTriple</code>, you could, indeed, argue that it's lossy, because it 'forgets' that the label associated with the first integer is <em>Girls</em>, that the label associated with the second integer is <em>Boys</em>, and so on. The reverse translation, however, 'remembers' that information, as you can see in the implementation of <code>FromTriple</code>. </p> <p> This isn't necessarily a 'safe' translation. You could easily write a method like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Roster</span>&nbsp;FromTriple(<span style="color:#2b91af;">Tuple</span>&lt;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">int</span>,&nbsp;<span style="color:blue;">string</span>[]&gt;&nbsp;triple) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Roster</span>(triple.Item2,&nbsp;triple.Item1,&nbsp;triple.Item3); }</pre> </p> <p> This compiles, but it translates triples created by <code>ToTriple</code> the wrong way. </p> <p> On the other hand, the pair of translations that I do show in the article <em>is</em> an isomorphism. The point is that an isomorphism exists; not that it's the only possible set of morphisms. </p> <p> The same argument can be applied to specific pairs of <em>Extract Method</em> and <em>Inline Method</em>. As a general-purpose algorithm, I still agree that <em>Inline Method</em> is lossy. That doesn't preclude that specific pairs of translations exist. For instance, in <a href="http://blog.ploeh.dk/2014/08/07/why-dry">an article</a>, I discuss how some people refactor Guard Clauses like this: </p> <p> <pre><span style="color:blue;">if</span>&nbsp;(subject&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:#a31515;">&quot;subject&quot;</span>);</pre> </p> <p> to something like this: </p> <p> <pre><span style="color:#2b91af;">Guard</span>.AgainstNull(subject,&nbsp;<span style="color:#a31515;">&quot;subject&quot;</span>);</pre> </p> <p> Again, an isomorphism exists: a translation from a Null Guard to <code>Guard.AgainstNull</code>, and another from <code>Guard.AgainstNull</code> to a Null Guard. Those are specific incarnations of <em>Extract Method</em> and <em>Inline Method</em>. </p> <p> This may not be particularly useful as a refactoring, I admit, but that's also not the agenda of these articles. The programme is to show how particular software behaviour can be expressed in various different ways that are equivalent to each other. </p> </div> <div class="comment-date">2018-01-14 14:26 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Colour-mixing magma http://blog.ploeh.dk/2018/01/02/colour-mixing-magma 2018-01-02T08:36:00+00:00 Mark Seemann <div id="post"> <p> <em>Mixing RGB colours forms a magma. An example for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">a larger series about monoids, semigroups, and other group-like algebraic structures</a>. In this article, you'll see an example of a <a href="http://blog.ploeh.dk/2017/12/27/magmas">magma</a>, which is a binary operation without additional constraints. </p> <h3 id="9970a480d34249568b228407c5f1a506"> RGB colours <a href="#9970a480d34249568b228407c5f1a506" title="permalink">#</a> </h3> <p> The opening article about monoids, semigropus, and their friends emphasised Eric Evans' pigment mixing example from <a href="http://amzn.to/WBCwx7">Domain-Driven Design</a>. The following article series then promptly proceeded to ignore that example. The reason is that while the example has <em>Closure of Operations</em>, it exhibits precious few other properties. It's neither <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>, <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a>, <a href="http://blog.ploeh.dk/2017/12/18/quasigroups">quasigroup</a>, nor any other named binary operation, apart from being a magma. </p> <p> Instead of <em>pigments</em>, consider a more primitive, but well-understood colour model: that of <a href="https://en.wikipedia.org/wiki/RGB_color_model">RGB colours</a>. In C#, you can model RGB colours using a <code>struct</code> that holds three <code>byte</code> fields. In my final code base, I ended up implementing <code>==</code>, <code>!=</code>, <code>Equals</code>, and so on, but I'm not going to bore you with all of those details. Here's the <code>RgbColor</code> constructor, so that you can get a sense of the type: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">byte</span>&nbsp;red; <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">byte</span>&nbsp;green; <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">byte</span>&nbsp;blue; <span style="color:blue;">public</span>&nbsp;RgbColor(<span style="color:blue;">byte</span>&nbsp;red,&nbsp;<span style="color:blue;">byte</span>&nbsp;green,&nbsp;<span style="color:blue;">byte</span>&nbsp;blue) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.red&nbsp;=&nbsp;red; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.green&nbsp;=&nbsp;green; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.blue&nbsp;=&nbsp;blue; }</pre> </p> <p> As you can see, <code>RgbColor</code> holds three <code>byte</code> fields, one for red, green, and blue. If you want to mix two colours, you can use the <code>MixWith</code> instance method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>&nbsp;MixWith(<span style="color:#2b91af;">RgbColor</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newRed&nbsp;=&nbsp;((<span style="color:blue;">int</span>)<span style="color:blue;">this</span>.red&nbsp;+&nbsp;(<span style="color:blue;">int</span>)other.red)&nbsp;/&nbsp;2m; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newGreen&nbsp;=&nbsp;((<span style="color:blue;">int</span>)<span style="color:blue;">this</span>.green&nbsp;+&nbsp;(<span style="color:blue;">int</span>)other.green)&nbsp;/&nbsp;2m; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newBlue&nbsp;=&nbsp;((<span style="color:blue;">int</span>)<span style="color:blue;">this</span>.blue&nbsp;+&nbsp;(<span style="color:blue;">int</span>)other.blue)&nbsp;/&nbsp;2m; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(<span style="color:blue;">byte</span>)<span style="color:#2b91af;">Math</span>.Round(newRed), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(<span style="color:blue;">byte</span>)<span style="color:#2b91af;">Math</span>.Round(newGreen), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(<span style="color:blue;">byte</span>)<span style="color:#2b91af;">Math</span>.Round(newBlue)); }</pre> </p> <p> <a href="http://blog.ploeh.dk/2017/10/06/monoids">This is a binary operation</a>, because it's an instance method on <code>RgbColor</code>, taking another <code>RgbColor</code> as input, and returning <code>RgbColor</code>. Since it's a binary operation, it's a magma, but could it be another, stricter category of operation? </p> <h3 id="ace361b86ee249599ede4d43098e6329"> Lack of associativity <a href="#ace361b86ee249599ede4d43098e6329" title="permalink">#</a> </h3> <p> Could <code>MixWith</code>, for instance, be a semigroup? In order to be a semigroup, the binary operation must be associative, and while it can be demanding to prove that an operation is <em>always</em> associative, it only takes a single counter-example to prove that it's not: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;MixWithIsNotAssociative() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(&nbsp;67,&nbsp;108,&nbsp;&nbsp;13); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(&nbsp;33,&nbsp;114,&nbsp;130); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;z&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(&nbsp;38,&nbsp;104,&nbsp;245); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.NotEqual( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.MixWith(y).MixWith(z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.MixWith(y.MixWith(z))); }</pre> </p> <p> This <a href="https://xunit.github.io">xUnit.net</a> unit test passes, thereby demonstrating that <code>MixWith</code> is <em>not</em> associative. When you mix <code>x</code> with <code>y</code>, you get <span style="color:#326F48">#326F48</span>, and when you mix that with <code>z</code> you get <span style="color:#2C6C9E">#2C6C9E</span>. On the other hand, when you mix <code>y</code> with <code>z</code> you get <span style="color:#246DBC">#246DBC</span>, which, combined with <code>x</code>, gives <span style="color:#346C64">#346C64</span>. <span style="color:#2C6C9E">#2C6C9E</span> is not equal to <span style="color:#346C64">#346C64</span>, so the <code>NotEqual</code> assertion passes. </p> <p> Because of this counter-example, <code>MixWith</code> isn't associative, and therefore not a semigroup. Since monoid requires associativity as well, we can also rule out that <code>MixWith</code> is a monoid. </p> <h3 id="22eeac6a82124dcf9b39da28134322bc"> Lack of invertibility <a href="#22eeac6a82124dcf9b39da28134322bc" title="permalink">#</a> </h3> <p> While <code>MixWith</code> isn't a semigroup, could it be a quasigroup? In order to be a quasigroup, a binary operation must be invertible. This means that for <em>any</em> two elements <code>a</code> and <code>b</code>, there must exist two other elements <code>x</code> and <code>y</code> that turns <code>a</code> into <code>b</code>. </p> <p> This property must hold for all values involved in the binary operation, so again, a single counter-example suffices to demonstrate that <code>MixWith</code> isn't invertible, either: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;MixWithIsNotInvertible() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(&nbsp;94,&nbsp;&nbsp;35,&nbsp;172); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;b&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(151,&nbsp;185,&nbsp;&nbsp;&nbsp;7); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:#2b91af;">RgbColor</span>.All.Any(x&nbsp;=&gt;&nbsp;a.MixWith(x)&nbsp;==&nbsp;b)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:#2b91af;">RgbColor</span>.All.Any(y&nbsp;=&gt;&nbsp;y.MixWith(a)&nbsp;==&nbsp;b)); }</pre> </p> <p> This xUnit.net-based test also passes. It uses brute force to demonstrate that for all <code>RgbColor</code> values, there's no <code>x</code> and <code>y</code> that satisfy the invertibility property. The test actually takes a while to execute, because <code>All</code> returns all 16,777,216 possible <code>RgbColor</code> values: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>[]&nbsp;all; <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">object</span>&nbsp;syncLock&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:blue;">object</span>(); <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">RgbColor</span>&gt;&nbsp;All { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span> &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(all&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">lock</span>&nbsp;(syncLock) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(all&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;max&nbsp;=&nbsp;256&nbsp;*&nbsp;256&nbsp;*&nbsp;256; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;all&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>[max]; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;i&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Enumerable</span>.Range(0,&nbsp;max)) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;all[i]&nbsp;=&nbsp;(<span style="color:#2b91af;">RgbColor</span>)i; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;all; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> For performance reasons, the <code>All</code> property uses lazy initialisation with <a href="https://en.wikipedia.org/wiki/Double-checked_locking">double-checked locking</a>. It simply counts from <code>0</code> to <code>256 * 256 * 256</code> (16,777,216) and converts each integer to an <code>RgbColor</code> value using this explicit conversion: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">explicit</span>&nbsp;<span style="color:blue;">operator</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(<span style="color:blue;">int</span>&nbsp;i) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;red&nbsp;=&nbsp;(i&nbsp;&amp;&nbsp;0xFF0000)&nbsp;/&nbsp;0x10000; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;green&nbsp;=&nbsp;(i&nbsp;&amp;&nbsp;0xFF00)&nbsp;/&nbsp;0x100; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;blue&nbsp;=&nbsp;i&nbsp;&amp;&nbsp;0xFF; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>((<span style="color:blue;">byte</span>)red,&nbsp;(<span style="color:blue;">byte</span>)green,&nbsp;(<span style="color:blue;">byte</span>)blue); }</pre> </p> <p> The bottom line, though, is that the test passes, thereby demonstrating that for the chosen counter-example, no <code>x</code> and <code>y</code> satisfies the invertibility property. Therefore, <code>MixWith</code> isn't a quasigroup. </p> <h3 id="fe4afba417e64d38b454d409e8ce4098"> Lack of identity <a href="#fe4afba417e64d38b454d409e8ce4098" title="permalink">#</a> </h3> <p> Since <code>MixWith</code> is neither associative nor invertible, it's not really any named algebraic construct, other than a magma. It's neither group, semigroup, quasigroup, monoid, loop, groupoid, etc. Does it have <em>any</em> properties at all, apart from being a binary operation? </p> <p> It doesn't have identity either, which you can illustrate with another counter-example: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;MixWithHasNoIdentity() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;nearBlack&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(1,&nbsp;1,&nbsp;1); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;identityCandidates&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;e&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>.All &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">where</span>&nbsp;nearBlack.MixWith(e)&nbsp;==&nbsp;nearBlack &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;e; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Verify&nbsp;that&nbsp;there&#39;s&nbsp;only&nbsp;a&nbsp;single&nbsp;candidate:</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;identityCandidate&nbsp;=&nbsp;<span style="color:#2b91af;">Assert</span>.Single(identityCandidates); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Demonstrate&nbsp;that&nbsp;the&nbsp;candidate&nbsp;does&nbsp;behave&nbsp;like&nbsp;identity&nbsp;for</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;nearBlack:</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(nearBlack,&nbsp;nearBlack.MixWith(identityCandidate)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(nearBlack,&nbsp;identityCandidate.MixWith(nearBlack)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;counterExample&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">RgbColor</span>(3,&nbsp;3,&nbsp;3); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.NotEqual( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;counterExample,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;counterExample.MixWith(identityCandidate)); }</pre> </p> <p> The counter-example starts with a near-black colour. The reason I didn't pick absolute black (<code>new RgbColor(0, 0, 0)</code>) is that, due to rounding when mixing, there are eight candidates for absolute black, but only one for <code>nearBlack</code>. This is demonstrated by the <code>Assert.Single</code> assertion. <code>identityCandidate</code>, by the way, is also <code>new RgbColor(1, 1, 1)</code>, and further <a href="http://xunitpatterns.com/Guard%20Assertion.html">Guard Assertions</a> demonstrate that <code>identityCandidate</code> behaves like the identity for <code>nearBlack</code>. </p> <p> You can now pick another colour, such as <code>new RgbColor(3, 3, 3)</code> and demonstrate that <code>identityCandidate</code> does <em>not</em> behave like the identity for the counter-example. Notice that the assertion is <code>Assert.NotEqual</code>. </p> <p> If an identity exists for a magma, it must behave as the identity for all possible values. That's demonstrably not the case for <code>MixWith</code>, so it doesn't have identity. </p> <h3 id="a8d8c29298fc4ee0b2be40d6ec94c609"> Commutativity <a href="#a8d8c29298fc4ee0b2be40d6ec94c609" title="permalink">#</a> </h3> <p> While <code>MixWith</code> is neither associative, invertible, nor has identity, it does have at least one property: it's commutative. This means that the order of the input values doesn't matter. In other words, for any two <code>RgbColor</code> values <code>x</code> and <code>y</code>, this assertion always passes: </p> <p> <pre><span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;x.MixWith(y), &nbsp;&nbsp;&nbsp;&nbsp;y.MixWith(x));</pre> </p> <p> Since <code>x.MixWith(y)</code> is equal to <code>y.MixWith(x)</code>, <code>MixWith</code> is commutative. </p> <h3 id="87d46ebbea434bd1bfb77ea49399feb3"> Summary <a href="#87d46ebbea434bd1bfb77ea49399feb3" title="permalink">#</a> </h3> <p> The <code>MixWith</code> operation is a commutative magma, but while, for example, we call an associative magma a <em>semigroup</em>, there's no fancy word for a commutative magma. </p> <p> In this article, you got another, fairly realistic, example of a binary operation. Throughout the overall article series on monoids, semigroup, and other group-like algebraic structures, you've seen many examples, and you've learned how to analyse binary operations for the presence or absence of various properties. The present article concludes the series. You can, however, continue reading the <a href="http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory">even more overall article series</a>. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/03/19/functors-applicatives-and-friends">Functors, applicatives, and friends</a> </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Rock Paper Scissors magma http://blog.ploeh.dk/2017/12/28/rock-paper-scissors-magma 2017-12-28T11:22:00+00:00 Mark Seemann <div id="post"> <p> <em>The Rock Paper Scissors game forms a magma. An example for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">a larger series about monoids, semigroups, and other group-like algebraic structures</a>. In this article, you'll see an example of a <a href="http://blog.ploeh.dk/2017/12/27/magmas">magma</a>, which is a binary operation without additional constraints. </p> <h3 id="74a24da2f36d413a9882eb9ecd648b05"> Rock Paper Scissors <a href="#74a24da2f36d413a9882eb9ecd648b05" title="permalink">#</a> </h3> <p> When my first child was born, my wife and I quickly settled on a first name, but we couldn't agree on the surname, since we don't share the same surname. She wanted our daughter to have her surname, and I wanted her to have mine. We couldn't think of any rational arguments for one or the other, so we decided to settle the matter with a game of <a href="https://en.wikipedia.org/wiki/Rock%E2%80%93paper%E2%80%93scissors">Rock Paper Scissors</a>. I lost, so my daughter has my wife's surname. </p> <p> Despite that outcome, I still find that Rock Paper Scissors is a great way to pick between two equally valid alternatives. You could also flip a coin, or throw a die, but most people have their hands handy, so to speak. </p> <p> In C#, you can model the three shapes of rock, paper, and scissors like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">abstract</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Rps</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;Rock&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">R</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;Paper&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">P</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;Scissors&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">S</span>(); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;Rps()&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">R</span>&nbsp;:&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">P</span>&nbsp;:&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">S</span>&nbsp;:&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;{&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members...</span> }</pre> </p> <p> I've seen more than one example where people use an <col>enum</col> to model the three shapes, but I believe that this is wrong, because <code>enum</code>s have an order to them, including a maximum and a minimum value (by default, <code>enum</code> is implemented with a 32-bit integer). That's not how Rock Paper Scissors work, so instead, I chose a different model where <code>Rock</code>, <code>Paper</code>, and <code>Scissors</code> are <a href="https://en.wikipedia.org/wiki/Singleton_pattern">Singletons</a>. </p> <p> This design works for the example, although I'm not entirely happy with it. The problem is that Rock, Paper, and Scissors should be a finite set, but by making <code>Rps</code> abstract, another developer could, conceivably, create additional derived classes. A finite <a href="https://en.wikipedia.org/wiki/Tagged_union">sum type</a> would have been better, but this isn't easily done in C#. In a language with <a href="https://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data types</a>, you can make a prettier implementation, like <a href="https://math.stackexchange.com/a/2342043/250481">this Haskell example</a>. F# would be another good language option. </p> <h3 id="466fc4446f774405ba31f8659915c577"> Binary operation <a href="#466fc4446f774405ba31f8659915c577" title="permalink">#</a> </h3> <p> When playing the game of Rock Paper Scissors, each round is a <em>throw</em> that compares two shapes. You can model a throw as a binary operation that returns the winning shape: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;Throw(<span style="color:#2b91af;">Rps</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Rps</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Rock&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Rock) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Rock; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Rock&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Paper) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Paper; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Rock&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Scissors) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Rock; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Paper&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Paper) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Paper; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Paper&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Scissors) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Scissors; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Paper&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Rock) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Paper; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Scissors&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Scissors) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Scissors; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(x&nbsp;==&nbsp;Scissors&nbsp;&amp;&amp;&nbsp;y&nbsp;==&nbsp;Rock) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Rock; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;Scissors; }</pre> </p> <p> To a C# programmer, perhaps the method name <code>Throw</code> is bewildering, because you might expect the method to throw an exception, but I chose to use the domain language of the game. </p> <p> Because this method takes two <code>Rps</code> values as input and returns an <code>Rps</code> value as output, <a href="http://blog.ploeh.dk/2017/10/06/monoids">it's a binary operation</a>. Thus, you already know it's a magma, but could it, also, be another, stricter binary operations, such as a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a> or <a href="http://blog.ploeh.dk/2017/12/18/quasigroups">quasigroup</a>? </p> <h3 id="04e968f2575d419cb519f72a7985aafd"> Lack of associativity <a href="#04e968f2575d419cb519f72a7985aafd" title="permalink">#</a> </h3> <p> In order to be a semigroup, the binary operation must be associative. You can easily demonstrate that <code>Throw</code> isn't associative by use of a counter-example: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;ThrowIsNotAssociative() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.NotEqual( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Paper,&nbsp;<span style="color:#2b91af;">Rps</span>.Rock),&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Paper,&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Rock,&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors))); }</pre> </p> <p> This <a href="https://xunit.github.io">xUnit.net</a> unit test passes, thereby demonstrating that <code>Throw</code> is <em>not</em> associative. The result of paper versus rock is paper, which, pitted against scissors yields scissors. On the other hand, paper versus the result of rock versus scissors is paper, because rock versus scissors is rock, and rock versus paper is paper. </p> <p> Since <code>Throw</code> isn't associative, it's not a semigroup (and, by extension, not a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>). Could it be a quasigroup? </p> <h3 id="ee92870510dc4a449aec03048f2356ba"> Lack of invertibility <a href="#ee92870510dc4a449aec03048f2356ba" title="permalink">#</a> </h3> <p> A binary operation must be invertible in order to be a quasigroup. This means that for <em>any</em> two elements <code>a</code> and <code>b</code>, there must exist two other elements <code>x</code> and <code>y</code> that turns <code>a</code> into <code>b</code>. </p> <p> This property must hold for all values involved in the binary operation - in this case <code>Rock</code>, <code>Paper</code>, and <code>Scissors</code>. A single counter-example is enough to show that <code>Throw</code> is <em>not</em> invertible: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;ThrowIsNotInvertible() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:#2b91af;">Rps</span>.Rock; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;b&nbsp;=&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:#2b91af;">Rps</span>.All.Any(x&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(a,&nbsp;x)&nbsp;==&nbsp;b)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.False(<span style="color:#2b91af;">Rps</span>.All.Any(y&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(y,&nbsp;a)&nbsp;==&nbsp;b)); }</pre> </p> <p> This (passing) unit test utilises an <code>All</code> property on <code>Rps</code>: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Rps</span>&gt;&nbsp;All { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span>&nbsp;{&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;Rock,&nbsp;Paper,&nbsp;Scissors&nbsp;};&nbsp;} }</pre> </p> <p> For a counter-example, pick <code>Rock</code> as <code>a</code> and <code>Scissors</code> as <code>b</code>. There's no value in <code>All</code> that satisfies the invertibility property. Therefore, <code>Throw</code> is not a quasigroup, either. </p> <h3 id="c09067193472434cb292fd2cc97e4e09"> Lack of identity <a href="#c09067193472434cb292fd2cc97e4e09" title="permalink">#</a> </h3> <p> Since <code>Throw</code> is neither associative nor invertible, it's not really any named algebraic construct, other than a magma. It's neither group, semigroup, quasigroup, monoid, loop, groupoid, etc. Does it have <em>any</em> properties at all, apart from being a binary operation? </p> <p> It doesn't have identity either, which you can illustrate with another counter-example: </p> <p> <pre>[<span style="color:#2b91af;">Fact</span>] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;ThrowHasNoIdentity() { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Find&nbsp;all&nbsp;identity&nbsp;candidates&nbsp;for&nbsp;Rock</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;rockIdentities&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;e&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Rps</span>.All &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">where</span>&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(e,&nbsp;<span style="color:#2b91af;">Rps</span>.Rock)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Rock &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Rock,&nbsp;e)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Rock &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;e; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Narrow&nbsp;for&nbsp;Paper</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;paperIdentities&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;e&nbsp;<span style="color:blue;">in</span>&nbsp;rockIdentities &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">where</span>&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(e,&nbsp;<span style="color:#2b91af;">Rps</span>.Paper)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Paper &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Paper,&nbsp;e)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Paper &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;e; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;None&nbsp;of&nbsp;those&nbsp;candidates&nbsp;are&nbsp;the&nbsp;identity&nbsp;for&nbsp;Scissors</span> &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;scissorIdentities&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;e&nbsp;<span style="color:blue;">in</span>&nbsp;paperIdentities &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">where</span>&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(e,&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(<span style="color:#2b91af;">Rps</span>.Scissors,&nbsp;e)&nbsp;==&nbsp;<span style="color:#2b91af;">Rps</span>.Scissors &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;e; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Empty(scissorIdentities); }</pre> </p> <p> First, you use <code>Rps.All</code> to find all the values that behave as an identity element for <code>Rps.Rock</code>. Recall that the identity is an element that doesn't change the input. In other words it's a value that when combined with <code>Rps.Rock</code> in <code>Throw</code> still returns <code>Rps.Rock</code>. There are two values that fulfil that property: <code>Rps.Rock</code> and <code>Rps.Scissors</code>. Those are the two values contained in <code>rockIdentities</code>. </p> <p> In order to be an identity, the value must behave as a neutral element for <em>all</em> possible values, so next, filter <code>rockIdentities</code> to find those elements that also behave as identities for <code>Rps.Paper</code>. Between <code>Rps.Rock</code> and <code>Rps.Scissors</code>, only <code>Rps.Rock</code> behaves like an identity for <code>Rps.Paper</code>, so <code>paperIdentities</code> is a collection containing only the single value <code>Rps.Rock</code>. </p> <p> Is <code>Rps.Rock</code> an identity for <code>Rps.Scissors</code>, then? It's not. <code>scissorIdentities</code> is empty. There's no element in <code>Rps.All</code> that acts an identity for all values in <code>Rps.All</code>. Therefore, by brute force, the test <code>ThrowHasNoIdentity</code> demonstrates (as it says on the tin) that throw has no identity. </p> <h3 id="b519901e883b4aea815fe682f6f04d9f"> Commutativity <a href="#b519901e883b4aea815fe682f6f04d9f" title="permalink">#</a> </h3> <p> While <code>Throw</code> is neither associative, invertible, nor has identity, it does have at least one property: it's commutative. This means that the order of the input values doesn't matter. In other words, for any two <code>Rps</code> values <code>x</code> and <code>y</code>, this assertion always passes: </p> <p> <pre><span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(x,&nbsp;y), &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Rps</span>.Throw(y,&nbsp;x));</pre> </p> <p> Since <code>Rps.Throw(x, y)</code> is equal to <code>Rps.Throw(y, x)</code>, <code>Throw</code> is commutative. </p> <h3 id="3ff6230db4c8449c819f757a3c87a4ac"> Summary <a href="#3ff6230db4c8449c819f757a3c87a4ac" title="permalink">#</a> </h3> <p> The Rock Paper Scissors <code>Throw</code> operation is a commutative magma, but while, for example, we call an associative magma a <em>semigroup</em>, there's no fancy word for a commutative magma. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/01/02/colour-mixing-magma">Colour-mixing magma</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Magmas http://blog.ploeh.dk/2017/12/27/magmas 2017-12-27T08:32:00+00:00 Mark Seemann <div id="post"> <p> <em>A binary operation with no constraints on its behaviour is called a magma. An introduction for object-oriented programmers.</em> </p> <p> In the <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">overall article series about group-like algebraic structures</a>, you've so far seen examples of <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a>, <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroups</a>, and <a href="http://blog.ploeh.dk/2017/12/18/quasigroups">quasigroups</a>. Common to all of these structures is that they are binary operations governed by at least one law. The laws are different for the different categories, but there <em>are</em> rules. </p> <p> What if you have a binary operation that follows none of those rules? </p> <p> <img src="/content/binary/magmas-quasigroups-semigroups-monoids.png" alt="Monoids are a subset of semigroups, which are subsets of magmas. Quasigroups are also a subset of magmas, but can overlap semigroups and monoids."> </p> <p> All binary operations are <a href="https://en.wikipedia.org/wiki/Magma_(algebra)">magmas</a>. If they have additional properties, we may call them <em>quasigroups</em>, or <em>monoids</em>, or some such, depending on the specific properties, but they're still all magmas. This is the most inclusive category. </p> <p> You've already seen examples of monoids and semigroups, but what about magma examples? In a sense, you've already seen those as well, because all the examples you've seen so far have also been magma examples. After all, since all monoids are magmas, all the monoid examples you've seen have also been magma examples. </p> <p> Still, it's not that hard to come up with some programming examples of magmas that aren't semi- or quasigroups. In the next articles, you'll see some examples. <ul> <li><a href="http://blog.ploeh.dk/2017/12/28/rock-paper-scissors-magma">Rock Paper Scissors magma</a></li> <li><a href="http://blog.ploeh.dk/2018/01/02/colour-mixing-magma">Colour-mixing magma</a></li> </ul> Particularly the second example is fairly realistic, which demonstrates that as programmers, we can benefit from having vocabulary that enables us to describe any binary operation that doesn't obey any particular laws. In fact, establishing a vocabulary has been my primary motivation for writing this article series. </p> <p> <strong>Next: </strong> <a href="http://blog.ploeh.dk/2017/12/28/rock-paper-scissors-magma">Rock Paper Scissors magma</a> </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Quasigroups http://blog.ploeh.dk/2017/12/18/quasigroups 2017-12-18T13:31:00+00:00 Mark Seemann <div id="post"> <p> <em>A brief introduction to quasigroups for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">a larger series about monoids, semigroups, and other group-like algebraic structures</a>. In this article, you'll get acquainted with the concept of a quasigroup. I don't think it plays that big of a role in software design, but it <em>is</em> a thing, and I thought that I'd cover it briefly with a well known-example. </p> <p> During all this talk of <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoids</a> and <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroups</a>, you've seen that normal arithmetic operations like addition and multiplication form monoids. Perhaps you've been wondering where subtraction fits in. </p> <p> Subtraction forms a quasigroup. </p> <p> What's a quasigroup? It's an invertible binary operation. </p> <h3 id="bfc345d0a2c34954a254e4de21253380"> Inversion <a href="#bfc345d0a2c34954a254e4de21253380" title="permalink">#</a> </h3> <p> What does it mean for a binary operation to be invertible? It means that for any two elements <code>a</code> and <code>b</code>, there must exist two other elements <code>x</code> and <code>y</code> that turns <code>a</code> into <code>b</code>. </p> <p> This is true for subtraction, as this <a href="https://fscheck.github.io/FsCheck">FsCheck</a>-based test demonstrates: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;SubtractionIsInvertible(<span style="color:blue;">int</span>&nbsp;a,&nbsp;<span style="color:blue;">int</span>&nbsp;b) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;a&nbsp;-&nbsp;b; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;a&nbsp;+&nbsp;b; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(a&nbsp;-&nbsp;x&nbsp;==&nbsp;b); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(y&nbsp;-&nbsp;a&nbsp;==&nbsp;b); }</pre> </p> <p> This example uses the <a href="https://www.nuget.org/packages/FsCheck.Xunit">FsCheck.Xunit</a> glue library for <a href="https://xunit.github.io">xUnit.net</a>. Notice that although FsCheck is written in F#, you can also use it from C#. This test (as well as all other tests in this article) passes. </p> <p> For any <code>a</code> and <code>b</code> generated by FsCheck, we can calculate unique <code>x</code> and <code>y</code> that satisfy <code>a - x == b</code> and <code>y - a == b</code>. </p> <p> Subtraction isn't the only invertible binary operation. In fact, addition is also invertible: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AdditionIsInvertible(<span style="color:blue;">int</span>&nbsp;a,&nbsp;<span style="color:blue;">int</span>&nbsp;b) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;b&nbsp;-&nbsp;a; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;b&nbsp;-&nbsp;a; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(a&nbsp;+&nbsp;x&nbsp;==&nbsp;b); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.True(y&nbsp;+&nbsp;a&nbsp;==&nbsp;b); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;y); }</pre> </p> <p> Here I added a third assertion that demonstrates that for addition, the inversion is symmetric; <code>x</code> and <code>y</code> are equal. </p> <p> Not only is integer addition a monoid - it's also a quasigroup. In fact, it's a <a href="https://en.wikipedia.org/wiki/Group_(mathematics)">group</a>. Being associative or having identity doesn't preclude a binary operation from being a quasigroup, but these properties aren't required. </p> <h3 id="5b8c084b14f5432a89e26a34a7654e27"> No identity <a href="#5b8c084b14f5432a89e26a34a7654e27" title="permalink">#</a> </h3> <p> No identity element exists for integer subtraction. For instance, <em>3 - 0</em> is <em>3</em>, but <em>0 - 3</em> is <em>not 3</em>. Therefore, subtraction can't be a monoid. </p> <h3 id="c568fdbfa6de4c65a99a97bd82cba4e5"> No associativity <a href="#c568fdbfa6de4c65a99a97bd82cba4e5" title="permalink">#</a> </h3> <p> Likewise, subtraction is not an associative operation. You can easily convince yourself of that by coming up with a counter-example, such as <em>(3 - 2) - 1</em>, which is <em>0</em>, but different from <em>3 - (2 - 1)</em>, which is <em>2</em>. Therefore, it can't be a semigroup either. </p> <h3 id="697353c1095c446380f28ef029663238"> Summary <a href="#697353c1095c446380f28ef029663238" title="permalink">#</a> </h3> <p> A quasigroup is an invertible binary operation. Invertibility is the only <em>required</em> property of a quasigroup (apart from being a binary operation), but if it has other properties (like associativity), it's still a quasigroup. </p> <p> I haven't had much utility from thinking about software design in terms of quasigroups, but I wanted to include it in case you were wondering how subtraction fits into all of this. </p> <p> What if, however, you have a binary operation with <em>no other</em> properties? </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/12/27/magmas">Magmas</a>. </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Semigroups accumulate http://blog.ploeh.dk/2017/12/11/semigroups-accumulate 2017-12-11T08:28:00+00:00 Mark Seemann <div id="post"> <p> <em>You can accumulate an arbitrary, non-zero number of semigroup values to a single value. An article for object-oriented programmers.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">series about semigroups</a>. In short, a <em>semigroup</em> is an associative binary operation. </p> <p> As you've learned in <a href="http://blog.ploeh.dk/2017/11/20/monoids-accumulate">a previous article</a>, you can accumulate an arbitrary number of monoidal values to a single value. A corresponding property holds for semigroups. </p> <h3 id="bea7cebd9f2246f0a55ddcaaa708961d"> Monoid accumulation <a href="#bea7cebd9f2246f0a55ddcaaa708961d" title="permalink">#</a> </h3> <p> When an instance method <code>Op</code> forms a monoid, you can easily write a function that accumulates an arbitrary number of <code>Foo</code> values: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Accumulate(<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Foo</span>&gt;&nbsp;foos) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;Identity; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;f&nbsp;<span style="color:blue;">in</span>&nbsp;foos) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;acc.Op(f); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> Notice how this generally applicable algorithm starts with the <code>Identity</code> value. One implication of this is that when <code>foos</code> is empty, the return value will be <code>Identity</code>. When <code>Op</code> is a semigroup, however, there's no identity, so this doesn't quite work. You need a value to start the accumulation; something you can return if the collection is empty. </p> <h3 id="e2aadaf2b69c48a88a3f0b1ac0459fd4"> Semigroup accumulation <a href="#e2aadaf2b69c48a88a3f0b1ac0459fd4" title="permalink">#</a> </h3> <p> From <a href="https://www.haskell.org">Haskell</a> you can learn that if you have a semigroup, you can accumulate any non-empty collection: </p> <p> <code>sconcat :: Semigroup a =&gt; NonEmpty a -&gt; a</code> </p> <p> You can read this as: for any generic type <code>a</code>, when <code>a</code> forms a <code>Semigroup</code>, the <code>sconcat</code> function takes a non-empty list of <code>a</code> values, and reduces them to a single <code>a</code> value. <code>NonEmpty a</code> is a list with at least one element. </p> <h3 id="68b942712506472ebe4c6933ca7dbd56"> NotEmptyCollection <a href="#68b942712506472ebe4c6933ca7dbd56" title="permalink">#</a> </h3> <p> You can also define a <code>NotEmptyCollection&lt;T&gt;</code> class in C#: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NotEmptyCollection</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;:&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">T</span>&gt; { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;NotEmptyCollection(<span style="color:#2b91af;">T</span>&nbsp;head,&nbsp;<span style="color:blue;">params</span>&nbsp;<span style="color:#2b91af;">T</span>[]&nbsp;tail) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(head&nbsp;==&nbsp;<span style="color:blue;">null</span>) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">throw</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">ArgumentNullException</span>(<span style="color:blue;">nameof</span>(head)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Head&nbsp;=&nbsp;head; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Tail&nbsp;=&nbsp;tail; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Head&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;Tail&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Count&nbsp;{&nbsp;<span style="color:blue;">get</span>&nbsp;=&gt;&nbsp;<span style="color:blue;">this</span>.Tail.Count&nbsp;+&nbsp;1;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">IEnumerator</span>&lt;<span style="color:#2b91af;">T</span>&gt;&nbsp;GetEnumerator() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">yield</span>&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.Head; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;item&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:blue;">this</span>.Tail) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">yield</span>&nbsp;<span style="color:blue;">return</span>&nbsp;item; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IEnumerator</span>&nbsp;<span style="color:#2b91af;">IEnumerable</span>.GetEnumerator() &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">this</span>.GetEnumerator(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Because of the way the constructor is defined, you <em>must</em> supply at least one element in order to create an instance. You can provide any number of extra elements via the <code>tail</code> array, but one is minimum. </p> <p> The <code>Count</code> property returns the number of elements in <code>Tail</code>, plus one, because there's always a <code>Head</code> value. </p> <p> The <code>GetEnumerator</code> method returns an iterator that always starts with the <code>Head</code> value, and proceeds with all the <code>Tail</code> values, if there are any. </p> <h3 id="260996225d1249a9847065f4e4b23f40"> Finding the maximum of a non-empty collection <a href="#260996225d1249a9847065f4e4b23f40" title="permalink">#</a> </h3> <p> As you've already learned, <code>Math.Max</code> is a semigroup. Although the .NET Base Class Library has built-in methods for this, you can use a generally applicable algorithm to find the maximum value in a non-empty list of integers. </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Accumulate(<span style="color:#2b91af;">NotEmptyCollection</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;numbers) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;numbers.Head; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;n&nbsp;<span style="color:blue;">in</span>&nbsp;numbers.Tail) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Max(acc,&nbsp;n); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> Notice how similar this algorithm is to monoid accumulation! The only difference is that instead of using <code>Identity</code> to get started, you can use <code>Head</code>, and then loop over all elements of <code>Tail</code>. </p> <p> You can use it like this: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;nec&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">NotEmptyCollection</span>&lt;<span style="color:blue;">int</span>&gt;(42,&nbsp;1337,&nbsp;123); <span style="color:blue;">var</span>&nbsp;max&nbsp;=&nbsp;Accumulate(nec);</pre> </p> <p> Here, <code>max</code> is obviously <code>1337</code>. </p> <p> As usual, however, this is much nicer, and more succinct in Haskell: </p> <p> <pre>Prelude Data.Semigroup Data.List.NonEmpty&gt; getMax $ sconcat $ fmap Max $ 42 :| [1337, 123] 1337</pre> </p> <p> That's hardly <a href="http://blog.ploeh.dk/2015/08/03/idiomatic-or-idiosyncratic">the idiomatic</a> way of getting a maximum element in Haskell, but it does show how you can 'click together' concepts in order to achieve a goal. </p> <h3 id="f80749af4347478e905f55c0169687b4"> Aggregate <a href="#f80749af4347478e905f55c0169687b4" title="permalink">#</a> </h3> <p> Perhaps the observant reader will, at this point, have recalled to him- or herself that the .NET Base Class Library already includes an <code>Aggregate</code> extension method, with an overload that takes a seed. In general, the simpliest <code>Aggregate</code> method doesn't gracefully handle empty collections, but using the overload that takes a seed is more robust. You can rewrite the above <code>Accumulate</code> method using <code>Aggregate</code>: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Accumulate(<span style="color:#2b91af;">NotEmptyCollection</span>&lt;<span style="color:blue;">int</span>&gt;&nbsp;numbers) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;numbers.Tail.Aggregate( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;numbers.Head, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(x,&nbsp;y)&nbsp;=&gt;&nbsp;<span style="color:#2b91af;">Math</span>.Max(x,&nbsp;y)); }</pre> </p> <p> Notice how you can pass <code>Head</code> as the seed, and accumulate the <code>Tail</code> using that starting point. The <code>Aggregate</code> method is more like Haskell's <code>sconcat</code> for semigroups than <code>mconcat</code> for monoids. </p> <h3 id="722406b862374867afdcbb71671c80bf"> Summary <a href="#722406b862374867afdcbb71671c80bf" title="permalink">#</a> </h3> <p> A semigroup operation can be used to reduce values to a single value, just like a monoid can. The only difference is that a semigroup operation can't reduce an empty collection, whereas a monoid can. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/12/18/quasigroups">Quasigroups</a> </p> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Bounding box semigroup http://blog.ploeh.dk/2017/12/04/bounding-box-semigroup 2017-12-04T08:40:00+00:00 Mark Seemann <div id="post"> <p> <em>A semigroup example for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">a larger series about monoids, semigroups, and other group-like algebraic structures</a>. In this article, you'll see a non-trivial example of a <a href="http://blog.ploeh.dk/2017/11/27/semigroups">semigroup</a> that's <em>not</em> a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. In short, a semigroup is an associative binary operation. </p> <h3 id="199878a42aa845749aa23d6b728bf452"> Shapes <a href="#199878a42aa845749aa23d6b728bf452" title="permalink">#</a> </h3> <p> Imagine that you're developing a library of two-dimensional shapes, and that, for various reasons, each shape should have a <em>bounding box</em>. For example, here's a blue circle with a green bounding box: </p> <p> <img src="/content/binary/circle-with-bounding-box.png" alt="Circle with bounding box."> </p> <p> The code for a circle shape could look like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">Circle</span>&nbsp;:&nbsp;<span style="color:#2b91af;">ICanHasBox</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Radius&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;Circle(<span style="color:blue;">int</span>&nbsp;x,&nbsp;<span style="color:blue;">int</span>&nbsp;y,&nbsp;<span style="color:blue;">int</span>&nbsp;radius) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Radius&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Abs(radius); &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>&nbsp;BoundingBox &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">get</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.X&nbsp;-&nbsp;<span style="color:blue;">this</span>.Radius, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Y&nbsp;-&nbsp;<span style="color:blue;">this</span>.Radius, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Radius&nbsp;*&nbsp;2, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.Radius&nbsp;*&nbsp;2); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> In addition to the <code>Circle</code> class, you could have other shapes, such as rectangles, triangles, or even irregular shapes, each of which have a bounding box. </p> <h3 id="ae4945c2dffa4c34b8707c1fc03cdac4"> Bounding box unions <a href="#ae4945c2dffa4c34b8707c1fc03cdac4" title="permalink">#</a> </h3> <p> If you have two shapes, you also have two (green) bounding boxes, but perhaps you'd like to find the (orange) bounding box of the union of both shapes. </p> <p> <img src="/content/binary/union-of-bounding-boxes.png" alt="Union of two shapes with bounding boxes."> </p> <p> That's fairly easy to do: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>&nbsp;Unite(<span style="color:#2b91af;">BoundingBox</span>&nbsp;other) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newX&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Min(<span style="color:blue;">this</span>.X,&nbsp;other.X); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newY&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Min(<span style="color:blue;">this</span>.Y,&nbsp;other.Y); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newRightX&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Max(<span style="color:blue;">this</span>.rightX,&nbsp;other.rightX); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;newTopY&nbsp;=&nbsp;<span style="color:#2b91af;">Math</span>.Max(<span style="color:blue;">this</span>.topY,&nbsp;other.topY); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;newX, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;newY, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;newRightX&nbsp;-&nbsp;newX, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;newTopY&nbsp;-&nbsp;newY); }</pre> </p> <p> The <code>Unite</code> method is an instance method on the <code>BoundingBox</code> class, so <a href="http://blog.ploeh.dk/2017/10/06/monoids">it's a binary operation</a>. It's also associative, because for all <code>x</code>, <code>y</code>, and <code>z</code>, <code>isAssociative</code> is <code>true</code>: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;isAssociative&nbsp;=&nbsp;x.Unite(y).Unite(z)&nbsp;==&nbsp;x.Unite(y.Unite(z));</pre> </p> <p> Since the operation is associative, it's at least a semigroup. </p> <h3 id="9c3f6fd178b641008b45d61dc7ca0e5a"> Lack of identity <a href="#9c3f6fd178b641008b45d61dc7ca0e5a" title="permalink">#</a> </h3> <p> Is <code>Unite</code> also a monoid? In order to be a monoid, a binary operation must not only be associative, but also have an identity element. In <a href="http://blog.ploeh.dk/2017/10/23/convex-hull-monoid">a previous article</a>, you saw how the union of two <a href="https://en.wikipedia.org/wiki/Convex_hull">convex hulls</a> formed a monoid. A bounding box seems to be conceptually similar to a convex hull, so you'd be excused to think that our previous experience applies here as well. </p> <p> It doesn't. </p> <p> There's no <em>identity bounding box</em>. The difference between a convex hull and a bounding box is that it's possible to define an empty hull as an empty set of coordinates. A bounding box, on the other hand, always has a coordinate and a size. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">struct</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">int</span>&nbsp;rightX; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">int</span>&nbsp;topY; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;X&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Y&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Width&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:blue;">int</span>&nbsp;Height&nbsp;{&nbsp;<span style="color:blue;">get</span>;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;More&nbsp;members,&nbsp;including&nbsp;Unite...</span> }</pre> </p> <p> An identity element, if one exists, is one where if you <code>Unite</code> it with another <code>BoundingBox</code> object, the return value will be the other object. </p> <p> Consider, then, a (green) <code>BoundingBox x</code>. Any other <code>BoundingBox</code> inside of of <code>x</code>, including <code>x</code> itself, is a candidate for an identity element: </p> <p> <img src="/content/binary/bounding-box-with-identity-candidates.png" alt="Bounding box with candidates for an identity element."> </p> <p> In a <a href="https://en.wikipedia.org/wiki/Real_number">real</a> coordinate system, there's infinitely many candidates contained in <code>x</code>. As long as a candidate is wholly contained within <code>x</code>, then the union of the candidate and <code>x</code> will return <code>x</code>. </p> <p> In the code example, however, coordinates are 32-bit integers, so for any bounding box <code>x</code>, there's only a finite number of candidates. Even for the smallest possible bounding box, though, the box itself is an identity candidate. </p> <p> In order to be an identity element, however, the <em>same</em> element must behave as the identity element for <em>all</em> bounding boxes. It is, therefore, trivial to find a counter-example: </p> <p> <img src="/content/binary/bounding-box-identity-counter-example.png" alt="Bounding box identity element counter-example."> </p> <p> Just pick any other <code>BoundingBox y</code> outside of <code>x</code>. Every identity candidate must be within <code>x</code>, and therefore the union of the candidate and <code>y</code> cannot be <code>y</code>. </p> <p> In code, you can demonstrate the lack of identity with an <a href="https://fscheck.github.io/FsCheck">FsCheck</a>-based test like this: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Property</span>&nbsp;UniteHasNoIdentity(<span style="color:#2b91af;">PositiveInt</span>&nbsp;w,&nbsp;<span style="color:#2b91af;">PositiveInt</span>&nbsp;h) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;genCandidate&nbsp;=&nbsp;<span style="color:blue;">from</span>&nbsp;xi&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Gen</span>.Choose(1,&nbsp;w.Get) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;yi&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Gen</span>.Choose(1,&nbsp;h.Get) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;wi&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Gen</span>.Choose(1,&nbsp;w.Get&nbsp;-&nbsp;xi&nbsp;+&nbsp;1) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">from</span>&nbsp;hi&nbsp;<span style="color:blue;">in</span>&nbsp;<span style="color:#2b91af;">Gen</span>.Choose(1,&nbsp;h.Get&nbsp;-&nbsp;yi&nbsp;+&nbsp;1) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">select</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>(xi,&nbsp;yi,&nbsp;wi,&nbsp;hi); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:#2b91af;">Prop</span>.ForAll( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;genCandidate.ToArbitrary(), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;identityCandidate&nbsp;=&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;x&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>(1,&nbsp;1,&nbsp;w.Get,&nbsp;h.Get); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Show&nbsp;that&nbsp;the&nbsp;candidate&nbsp;behaves&nbsp;like&nbsp;identity&nbsp;for&nbsp;x</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;x.Unite(identityCandidate)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;identityCandidate.Unite(x)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Counter-example</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;y&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">BoundingBox</span>(0,&nbsp;0,&nbsp;1,&nbsp;1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.NotEqual(y,&nbsp;y.Unite(identityCandidate)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}); }</pre> </p> <p> This example uses the <a href="https://www.nuget.org/packages/FsCheck.Xunit">FsCheck.Xunit</a> glue library for <a href="https://xunit.github.io">xUnit.net</a>. Notice that although FsCheck is written in F#, you can also use it from C#. This test passes. </p> <p> It follows the above 'proof' by first generating an identity candidate for <code>x</code>. This is any <code>BoundingBox</code> contained within <code>x</code>, including <code>x</code> itself. In order to keep the code as simple as possible, <code>x</code> is always placed at the coordinate <em>(1, 1)</em>. </p> <p> The test proceeds to utilise two <a href="http://xunitpatterns.com/Guard%20Assertion.html">Guard Assertions</a> to show that <code>identityCandidate</code> does, indeed, behave like an identity for <code>x</code>. </p> <p> Finally, the test finds a trivial counter-example in <code>y</code>, and verifies that <code>y.Unite(identityCandidate)</code> is not equal to <code>y</code>. Therefore, <code>identityCandidate</code> is <em>not</em> the identity for <code>y</code>. </p> <p> <code>Unite</code> is a semigroup, but not a monoid, because no identity element exists. </p> <h3 id="9e0e4b0fbb4f4852a121f5239964a779"> Summary <a href="#9e0e4b0fbb4f4852a121f5239964a779" title="permalink">#</a> </h3> <p> This article demonstrates (via an example) that non-trivial semigroups exist in normal object-oriented programming. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/12/11/semigroups-accumulate">Semigroups accumulate</a>. </p> </div> <div id="comments"> <hr /> <h2 id="comments-header">Comments</h2> <div class="comment" id="3e9d723101964a1d87ade48be37aa841"> <div class="comment-author"><a href="http://criticalsoftwareblog.com/">Yacoub Massad</a></div> <div class="comment-content"> Thank you for writing about category theory. I just have a small note. "Just pick any other BoundingBox y partially or wholly outside of x." I think that one should pick a BoundingBox y wholly outside of x. Other wise the intersection between x and y would return x or y when we pass it to x.Unite or y.Unite respectively. <br> Thanks <br> </div> <div class="comment-date">2017-12-08 16:04 UTC</div> </div> <div class="comment" id="436c4737eef246bdb6c3fa6e2a74b70d"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Yacoub, thank you for writing. The operation used here isn't the <em>intersection</em>, but rather the <em>union</em> of two bounding boxes; that's the reason I called the method <code>Unite</code>. </p> </div> <div class="comment-date">2017-12-09 12:55 UTC</div> </div> <div class="comment" id="fcb5896e9ff24747b0a1486b96352abd"> <div class="comment-author"><a href="http://criticalsoftwareblog.com/">Yacoub Massad</a></div> <div class="comment-content"> <p> Hello Mark. I am aware of this, but maybe I did not explain my self correctly. <br> What I am trying to say is that when coming up with a counter-example, we should choose a BoundingBox y wholly outside of x (not just partially outside of x). <br> If we choose a BoundingBox y partially outside of x, then the intersection between x and y (the BoundingBox z = the area shared between x and y) is a valid identity element. <br> </p> </div> <div class="comment-date">2017-12-09 13:05 UTC</div> </div> <div class="comment" id="67c835a3e5074adfa82d0d2305dd6042"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Yacoub, I think you're right; sorry about that! </p> <p> Perhaps I should have written <em>Just pick any other <code>BoundingBox y</code> partially or wholly outside of the candidate.</em> Would that have been correct? </p> </div> <div class="comment-date">2017-12-09 13:57 UTC</div> </div> <div class="comment" id="555484d5e0344147aa106a60236a9b7c"> <div class="comment-author"><a href="http://criticalsoftwareblog.com/">Yacoub Massad</a></div> <div class="comment-content"> <p> That would be correct. I am not sure though if this is the best way to explain it. <br> <br> y being wholly ourside of x seems better to me. <br> </p> </div> <div class="comment-date">2017-12-09 14:15 UTC</div> </div> <div class="comment" id="0b61842b0c0d4dcfb10d883145428847"> <div class="comment-author"><a href="http://blog.ploeh.dk">Mark Seemann</a></div> <div class="comment-content"> <p> Yacoub, I've corrected the text in the article. Thank you for the feedback! </p> </div> <div class="comment-date">2017-12-09 15:21 UTC</div> </div> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Semigroups http://blog.ploeh.dk/2017/11/27/semigroups 2017-11-27T12:39:00+00:00 Mark Seemann <div id="post"> <p> <em>Introduction to semigroups for object-oriented programmers.</em> </p> <p> This article is part of <a href="http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends">a larger series about monoids, semigroups, and other group-like algebraic structures</a>. In this article, you'll learn what a semigroup is, and what distinguishes it from a <a href="http://blog.ploeh.dk/2017/10/06/monoids">monoid</a>. </p> <p> <img src="/content/binary/monoids-subset-of-semigroups.png" alt="Monoids are a subset of semigroups."> </p> <p> Semigroups form a superset of monoids. They are associative binary operations. While monoids additionally require that an identity element exists, no such requirement exist for semigroups. In other words, all monoids are semigroups, but not all semigroups are monoids. </p> <p> This article gives you an overview of semigroups, as well as a few small examples. A supplemental article will show a more elaborate example. </p> <h3 id="e9c36eb52d394b8989aacd1b6c783cb9"> Minimum <a href="#e9c36eb52d394b8989aacd1b6c783cb9" title="permalink">#</a> </h3> <p> An operation that returns the smallest of two values form a semigroup. In the .NET Base Class Library, such an operation is already defined for many numbers, for example 32-bit integers. Since associativity is a property of a semigroup, it makes sense to demonstrate it with a property-based test, here using <a href="https://fscheck.github.io/FsCheck">FsCheck</a>: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;IntMinimumIsAssociative(<span style="color:blue;">int</span>&nbsp;x,&nbsp;<span style="color:blue;">int</span>&nbsp;y,&nbsp;<span style="color:blue;">int</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Math</span>.Min(<span style="color:#2b91af;">Math</span>.Min(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Math</span>.Min(x,&nbsp;<span style="color:#2b91af;">Math</span>.Min(y,&nbsp;z))); }</pre> </p> <p> This example uses the <a href="https://www.nuget.org/packages/FsCheck.Xunit">FsCheck.Xunit</a> glue library for <a href="https://xunit.github.io">xUnit.net</a>. Notice that although FsCheck is written in F#, you can also use it from C#. This test (as well as all other tests in this article) passes. </p> <p> For mathematical integers, no identity element exists, so the minimum operation doesn't form a monoid. In practice, however, .NET 32-bit integers <em>do</em> have an identity element: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;MimimumIntHasIdentity(<span style="color:blue;">int</span>&nbsp;x) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;<span style="color:#2b91af;">Math</span>.Min(<span style="color:blue;">int</span>.MaxValue,&nbsp;x)); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal(x,&nbsp;<span style="color:#2b91af;">Math</span>.Min(x,&nbsp;<span style="color:blue;">int</span>.MaxValue)); }</pre> </p> <p> <a href="https://msdn.microsoft.com/en-us/library/system.int32.maxvalue">Int32.MaxValue</a> is the maximum possible 32-bit integer value, so it effectively behaves as the identity for the 32-bit integer minimum operation. All 32-bit numbers are smaller than, or equal to, <code>Int32.MaxValue</code>. This effectively makes <code>Math.Min(int, int)</code> a monoid, but conceptually, it's not. </p> <p> This may be clearer if, instead of 32-bit integers, you consider <a href="https://msdn.microsoft.com/en-us/library/system.numerics.biginteger">BigInteger</a>, which is an arbitrarily large (or small) integer. The <em>minimum</em> operation is still associative: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BigIntMinimumIsAssociative( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;y, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>.Min(<span style="color:#2b91af;">BigInteger</span>.Min(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>.Min(x,&nbsp;<span style="color:#2b91af;">BigInteger</span>.Min(y,&nbsp;z))); }</pre> </p> <p> No identity element exists, however, because no matter which integer you have, you can always find one that's bigger: no maximum value exists. This makes <code>BigInteger.Min</code> a semigroup, but not a monoid. </p> <h3 id="0424d23ed0714d70a3c2cfe5e4660aa5"> Maximum <a href="#0424d23ed0714d70a3c2cfe5e4660aa5" title="permalink">#</a> </h3> <p> Like <em>minimum</em>, the <em>maximum</em> operation forms a semigroup, here demonstrated by <code>BigInteger.Max</code>: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;BigIntMaximumIsAssociative( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;y, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>.Max(<span style="color:#2b91af;">BigInteger</span>.Max(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">BigInteger</span>.Max(x,&nbsp;<span style="color:#2b91af;">BigInteger</span>.Max(y,&nbsp;z))); }</pre> </p> <p> Again, like minimum, no identity element exists because the set of integers is infinite; you can always find a bigger or smaller number. </p> <p> Minimum and maximum operations aren't limited to primitive numbers. If values can be compared, you can always find the smallest or largest of two values, here demonstrated with <code>DateTime</code> values: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;DateTimeMaximumIsAssociative( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">DateTime</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">DateTime</span>&nbsp;y, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">DateTime</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">DateTime</span>,&nbsp;<span style="color:#2b91af;">DateTime</span>,&nbsp;<span style="color:#2b91af;">DateTime</span>&gt;&nbsp;dtMax&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(dt1,&nbsp;dt2)&nbsp;=&gt;&nbsp;dt1&nbsp;&gt;&nbsp;dt2&nbsp;?&nbsp;dt1&nbsp;:&nbsp;dt2; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dtMax(dtMax(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dtMax(x,&nbsp;dtMax(y,&nbsp;z))); }</pre> </p> <p> As was the case with 32-bit integers, however, the presence of <a href="https://msdn.microsoft.com/en-us/library/system.datetime.minvalue">DateTime.MinValue</a> effectively makes <code>dtMax</code> a monoid, but <em>conceptually</em>, no identity element exists, because dates are infinite. </p> <h3 id="79a13456ce5d48468169ba9985bf767f"> First <a href="#79a13456ce5d48468169ba9985bf767f" title="permalink">#</a> </h3> <p> Another binary operation simply returns the first of two values: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;First&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x; }</pre> </p> <p> This may seem pointless, but <code>First</code> <em>is</em> associative: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;FirstIsAssociative(<span style="color:#2b91af;">Guid</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Guid</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">Guid</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;First(First(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;First(x,&nbsp;First(y,&nbsp;z))); }</pre> </p> <p> On the other hand, there's no identity element, because there's no <em>left identity</em>. The <em>left identity</em> is an element <code>e</code> such that <code>First(e, x) == x</code> for any <code>x</code>. Clearly, for any generic type <code>T</code>, no such element exists because <code>First(e, x)</code> will only return <code>x</code> when <code>x</code> is equal to <code>e</code>. (There are, however, degenerate types for which an identity exists for <code>First</code>. Can you find an example?) </p> <h3 id="023edbd730b64bef9f8358bd95d4a9bd"> Last <a href="#023edbd730b64bef9f8358bd95d4a9bd" title="permalink">#</a> </h3> <p> Like <code>First</code>, a binary operation that returns the last (second) of two values also forms a semigroup: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Last&lt;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">T</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y; }</pre> </p> <p> Similar to <code>First</code>, <code>Last</code> is associative: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;LastIsAssociative(<span style="color:#2b91af;">String</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">String</span>&nbsp;y,&nbsp;<span style="color:#2b91af;">String</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Last(Last(x,&nbsp;y),&nbsp;z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Last(x,&nbsp;Last(y,&nbsp;z))); }</pre> </p> <p> As is also the case for <code>First</code>, no identity exists for <code>Last</code>, but here the problem is the lack of a <em>right identity</em>. The <em>right identity</em> is an element <code>e</code> for which <code>Last(x, e) == x</code> for all <code>x</code>. Clearly, <code>Last(x, e)</code> can only be equal to <code>x</code> if <code>e</code> is equal to <code>x</code>. </p> <h3 id="15d6faf006fe4b95a34b2d83c713151e"> Aggregation <a href="#15d6faf006fe4b95a34b2d83c713151e" title="permalink">#</a> </h3> <p> Perhaps you think that operations like <code>First</code> and <code>Last</code> seem useless in practice, but when you have a semigroup, you can reduce any non-empty sequence to a single value. In C#, you can use the <a href="https://msdn.microsoft.com/en-us/library/bb548651">Aggregate</a> LINQ method for this. For example </p> <p> <pre><span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;1,&nbsp;0,&nbsp;1337,&nbsp;-10,&nbsp;42&nbsp;}.Aggregate(<span style="color:#2b91af;">Math</span>.Min); </pre> </p> <p> returns <code>-10</code>, while </p> <p> <pre><span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;1,&nbsp;0,&nbsp;1337,&nbsp;-10,&nbsp;42&nbsp;}.Aggregate(<span style="color:#2b91af;">Math</span>.Max); </pre> </p> <p> returns <code>1337</code>. Notice that the input sequence is the same in both examples, but the semigroup differs. Likewise, you can use <code>Aggregate</code> with <code>First</code>: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;1,&nbsp;0,&nbsp;1337,&nbsp;-10,&nbsp;42&nbsp;}.Aggregate(First); </pre> </p> <p> Here, <code>a</code> is <code>1</code>, while </p> <p> <pre><span style="color:blue;">var</span>&nbsp;a&nbsp;=&nbsp;<span style="color:blue;">new</span>[]&nbsp;{&nbsp;1,&nbsp;0,&nbsp;1337,&nbsp;-10,&nbsp;42&nbsp;}.Aggregate(Last); </pre> </p> <p> returns <code>42</code>. </p> <p> LINQ has specialised methods like <a href="https://msdn.microsoft.com/en-us/library/bb352408">Min</a>, <a href="https://msdn.microsoft.com/en-us/library/bb358775">Last</a>, and so on, but from the perspective of behaviour, <code>Aggregate</code> would have been enough. While there may be performance reasons why some of those specialised methods exist, you can think of all of them as being based on the same abstraction: that of a semigroup. </p> <p> <code>Aggregate</code>, and many of the specialised methods, throw an exception if the input sequence is empty. This is because there's no identity element in a semigroup. The method doesn't know how to create a value of the type <code>T</code> from an empty list. </p> <p> If, on the other hand, you have a monoid, you can return the identity element in case of an empty sequence. <a href="https://www.haskell.org">Haskell</a> explicitly makes this distinction with <code>sconcat</code> and <code>mconcat</code>, but I'm not going to go into that now. </p> <h3 id="4ae02c6fbede45b0829ce9bed19603d0"> Summary <a href="#4ae02c6fbede45b0829ce9bed19603d0" title="permalink">#</a> </h3> <p> Semigroups are associative binary operations. In the previous <a href="http://blog.ploeh.dk/2017/10/06/monoids">article series about monoids</a> you saw plenty of examples, and since all monoids are semigroups, you've already seen more than one semigroup example. In this article, however, you saw four examples of semigroups that are <em>not</em> monoids. </p> <p> All four examples in this article are simple, and may not seem like 'real-world' examples. In the next article, then, you'll get a more realistic example of a semigroup that's not a monoid. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2017/12/04/bounding-box-semigroup">Bounding box semigroup</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Monoids accumulate http://blog.ploeh.dk/2017/11/20/monoids-accumulate 2017-11-20T08:00:00+00:00 Mark Seemann <div id="post"> <p> <em>You can accumulate an arbitrary number of monoidal values to a single value. An article for object-oriented programmers.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/10/06/monoids">series about monoids</a>. In short, a <em>monoid</em> is an associative binary operation with a neutral element (also known as <em>identity</em>). </p> <p> Recall that a binary operation is an operation involving two arguments of the same type, and returning a value of that type. </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Op(<span style="color:#2b91af;">Foo</span>&nbsp;x,&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;y)</pre> </p> <p> Notice that such an operation reduces two <code>Foo</code> values to a single <code>Foo</code> value. </p> <h3 id="a7ab99d4b96c4f8d8a57bf5dde29714b"> Accumulation <a href="#a7ab99d4b96c4f8d8a57bf5dde29714b" title="permalink">#</a> </h3> <p> Since you have an operation that can reduce two values to a single value, you can use that single value as the input for yet another binary operation. This enables you to accumulate, or aggregate, an arbitrary number of values. </p> <p> Consider the instance variation of the above <code>Op</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Op(<span style="color:#2b91af;">Foo</span>&nbsp;foo)</pre> </p> <p> This is another representation of the operation, but instead of being a static method, it's an instance method on the <code>Foo</code> class. </p> <p> When <code>Op</code> is a monoid, you can easily write a function that accumulates an arbitrary number of <code>Foo</code> values: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Accumulate(<span style="color:#2b91af;">IReadOnlyCollection</span>&lt;<span style="color:#2b91af;">Foo</span>&gt;&nbsp;foos) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;acc&nbsp;=&nbsp;Identity; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">foreach</span>&nbsp;(<span style="color:blue;">var</span>&nbsp;f&nbsp;<span style="color:blue;">in</span>&nbsp;foos) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;acc&nbsp;=&nbsp;acc.Op(f); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;acc; }</pre> </p> <p> You start with the <code>Identity</code> value, which also becomes the return value if <code>foos</code> is empty. Then you simply loop over each value in <code>foos</code> and use <code>Op</code> with the value accumulated so far (<code>acc</code>) and the current element in the sequence. </p> <p> Once you're done looping, you return the accumulator. </p> <p> This implementation isn't always guaranteed to be the most efficient, but you can <em>always</em> write accumulation like that. Sometimes, a more efficient algorithm exists, but that doesn't change the overall result that you can always reduce an arbitrary number of values whenever a monoid exists for those values. </p> <h3 id="4d836a93139e4b94918378a7f605392e"> Generalisation <a href="#4d836a93139e4b94918378a7f605392e" title="permalink">#</a> </h3> <p> You can do this with any monoid. In <a href="https://www.haskell.org">Haskell</a>, this function is called <code>mconcat</code>, and it has this type: </p> <p> <pre>mconcat :: Monoid a =&gt; [a] -&gt; a</pre> </p> <p> The way you can read this is that for any monoid <code>a</code>, <code>mconcat</code> is a function that takes a linked list of <code>a</code> values as input, and returns a single <code>a</code> value as output. </p> <p> This function seems both more general, and more constrained, than the above C# example. It's more general than the C# example because it works on any monoid, instead of just <code>Foo.Op</code>. On the other hand, it seems more limited because it works only on Haskell lists. The C# example, in contrast, can accumulate any <code>IReadOnlyCollection&lt;Foo&gt;</code>. Could you somehow combine those two generalisations? </p> <p> Nothing stops you from doing that, but it's already in Haskell's <code>Data.Foldable</code> module: </p> <p> <pre>fold :: (Monoid m, Foldable t) =&gt; t m -&gt; m</pre> </p> <p> The way to read this is that there's a function called <code>fold</code>, and it accumulates any monoid <code>m</code> contained in any 'foldable' data container <code>t</code>. That a data container is 'foldable' means that there's a way to somehow fold, or aggregate, the element(s) in the container into a value. </p> <p> Linked lists, arrays, and other types of sequences are foldable, as are <a href="http://blog.ploeh.dk/2018/03/26/the-maybe-functor">Maybe</a> and trees. </p> <p> In fact, there's little difference between Haskell's <code>Foldable</code> type class and .NET's <code>IEnumerable&lt;T&gt;</code>, but as the names suggest, their foci are different. In Haskell, the focus is being able to fold, accumulate, or aggregate a data structure, whereas on .NET the focus is on being able to enumerate the values inside the data structure. Ultimately, though, both abstractions afford the same capabilities. </p> <p> In .NET, the focal abstraction is the <a href="https://en.wikipedia.org/wiki/Iterator_pattern">Iterator pattern</a>, which enables you to enumerate the values in the data container. On top of that abstraction, you can derive other behaviour, such as the ability to <a href="https://msdn.microsoft.com/en-us/library/system.linq.enumerable.aggregate">Aggregate</a> data. </p> <p> In Haskell, the focus is on the ability to fold, but from that central abstraction follows the ability to convert the data container into a linked list, which you can then enumerate. </p> <h3 id="3a34228e6ed44c1d957284c4e3f94831"> Summary <a href="#3a34228e6ed44c1d957284c4e3f94831" title="permalink">#</a> </h3> <p> You can accumulate an arbitrary number of monoidal values as long as they're held in a container that enables you to 'fold' it. This includes all sorts of lists and arrays. </p> <p> This article concludes the article series about monoids. In the next series of articles, you'll learn about a related category of operations. </p> <p> <strong>Next: </strong> <a href="http://blog.ploeh.dk/2017/11/27/semigroups">Semigroups</a>. </p> </div> <div id="comments"> <hr /> <h2 id="comments-header">Comments</h2> <div class="comment" id="db96e1b2e6fd43c88285a9c299570dd0"> <div class="comment-author"><a href="https://about.me/carsten.koenig">Carsten König</a></div> <div class="comment-content"> <p> <a href="https://twitter.com/ploeh">@ploeh</a> as always I loved your blog post but I don't 100% agree on your comparison of the iterator pattern with Foldable - the iterator pattern allows usually sideeffects and you have Traversable for that - you might also like this: <a href="http://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf">http://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf</a> … </p> <p> (Comment <a href="https://twitter.com/CarstenK_Dev/status/932597257584676864">submitted via Twitter</a>) </p> </div> <div class="comment-date">2017-11-20 13:11 UTC</div> </div> </div><hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Endomorphism monoid http://blog.ploeh.dk/2017/11/13/endomorphism-monoid 2017-11-13T07:10:00+00:00 Mark Seemann <div id="post"> <p> <em>A method that returns the same type of output as its input forms a monoid. An article for object-oriented programmers.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/10/06/monoids">series about monoids</a>. In short, a <em>monoid</em> is an associative binary operation with a neutral element (also known as <em>identity</em>). Methods that return the same type of value as their input form monoids over composition. The formal term for such an operation is an <a href="https://en.wikipedia.org/wiki/Endomorphism">endomorphism</a>. </p> <h3 id="691b9a4afaab4c63b648f6891bcf7f1d"> Scheduling example <a href="#691b9a4afaab4c63b648f6891bcf7f1d" title="permalink">#</a> </h3> <p> Imagine that you have to develop some functionality for scheduling events in the future. As a concrete example, I recently wrote about adjusting dates while <a href="http://blog.ploeh.dk/2017/04/24/simple-holidays">taking bank holidays into account</a>. For instance, if you want to find the latest bank day <em>before</em> a given date, you could call the <code>AdjustToLatestPrecedingDutchBankDay</code> method. If you give it a normal bank day (say, a Thursday), it'll simply return the input date, but if you give it a Sunday, it'll return the preceding Friday. That is, unless that particular Friday is a bank holiday, in which case it'll return the Thursday before - as long as that's not also a bank holiday, and so on. </p> <p> In that previous article, the <code>AdjustToLatestPrecedingDutchBankDay</code> method is an extension method, but you can also model it as an instance method, like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">var</span>&nbsp;candidate&nbsp;=&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">while</span>&nbsp;(!(IsDutchBankDay(candidate.DateTime))) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;candidate&nbsp;=&nbsp;candidate.AddDays(-1); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;candidate; }</pre> </p> <p> This method would be part of a class that implements an interface: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">interface</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value); }</pre> </p> <p> You can make other implementations of this interface. Here's one that adjusts a date and time to business hours: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">BusinessHoursAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">TimeSpan</span>&nbsp;startOfBussiness&nbsp;=&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">TimeSpan</span>.FromHours(9); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">TimeSpan</span>&nbsp;endOfBusiness&nbsp;=&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">TimeSpan</span>.FromHours(17); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;Warning:&nbsp;May&nbsp;not&nbsp;handle&nbsp;DST&nbsp;changes&nbsp;appropriately!</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:green;">//&nbsp;It&#39;s&nbsp;only&nbsp;example&nbsp;code...</span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(value.TimeOfDay&nbsp;&lt;&nbsp;startOfBussiness) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;value&nbsp;-&nbsp;value.TimeOfDay&nbsp;+&nbsp;startOfBussiness; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">if</span>&nbsp;(endOfBusiness&nbsp;&lt;&nbsp;value.TimeOfDay) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;(value&nbsp;-&nbsp;value.TimeOfDay&nbsp;+&nbsp;startOfBussiness).AddDays(1); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> To keep the example simple, business hours are hard-coded to 9-17. </p> <p> You could also <a href="https://en.wikipedia.org/wiki/Adapter_pattern">adapt</a> conversion to UTC: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">UtcAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;value.ToUniversalTime(); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Or add a month: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">NextMonthAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;value.AddMonths(1); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> Notice that the <code>Adjust</code> method returns a value of the same type as its input. So far when discussing monoids, we've been looking at binary operations, but <code>Adjust</code> is a <em>unary</em> operation. </p> <p> An operation that returns the same type as its input is called an <em>endomorphism</em>. Those form monoids. </p> <h3 id="cc6d8ea6464e4730953c692c262151bf"> Composing adjustments <a href="#cc6d8ea6464e4730953c692c262151bf" title="permalink">#</a> </h3> <p> It's easy to connect two adjustments. Perhaps, for example, you'd like to first use <code>BusinessHoursAdjustment</code>, followed by the bank day adjustment. This will adjust an original input date and time to a date and time that falls on a bank day, within business hours. </p> <p> You can do this in a general-purpose, reusable way: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;Append( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;y) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">AppendedAdjustment</span>(x,&nbsp;y); } <span style="color:blue;">private</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">AppendedAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">private</span>&nbsp;<span style="color:blue;">readonly</span>&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;AppendedAdjustment( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;y) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.x&nbsp;=&nbsp;x; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">this</span>.y&nbsp;=&nbsp;y; &nbsp;&nbsp;&nbsp;&nbsp;} &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;y.Adjust(x.Adjust(value)); &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> The <code>Append</code> method takes two <code>IDateTimeOffsetAdjustment</code> values and combines them by wrapping them in a private implementation of <code>IDateTimeOffsetAdjustment</code>. When <code>AppendedAdjustment.Adjust</code> is called, it first calls <code>Adjust</code> on <code>x</code>, and then calls <code>Adjust</code> on <code>y</code> with the return value from the first call. </p> <p> In order to keep the example simple, I omitted null guards, but apart from that, <code>Append</code> should work with any two implementations of <code>IDateTimeOffsetAdjustment</code>. In other words, it obeys the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle">Liskov Substitution Principle</a>. </p> <h3 id="45a1de760dbb4b99aca3ee90515b173e"> Associativity <a href="#45a1de760dbb4b99aca3ee90515b173e" title="permalink">#</a> </h3> <p> The <code>Append</code> method is a binary operation. It takes two <code>IDateTimeOffsetAdjustment</code> values and returns an <code>IDateTimeOffsetAdjustment</code>. It's also associative, as a test like this demonstrates: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AppendIsAssociative( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;x, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;y, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;z) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.Append(y).Append(z), &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.Append(y.Append(z))); }</pre> </p> <p> As usual in this article series, such a test doesn't <em>prove</em> that <code>Append</code> is associative for all values of <code>IDateTimeOffsetAdjustment</code>, but if you run it as a property-based test, it demonstrates that it's quite likely. </p> <h3 id="d29cfb1ecd4949f3a1e60462963ce19f"> Identity <a href="#d29cfb1ecd4949f3a1e60462963ce19f" title="permalink">#</a> </h3> <p> In true monoidal fashion, <code>IDateTimeOffsetAdjustment</code> also has an identity element: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">class</span>&nbsp;<span style="color:#2b91af;">IdentityDateTimeOffsetAdjustment</span>&nbsp;:&nbsp;<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span> { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;Adjust(<span style="color:#2b91af;">DateTimeOffset</span>&nbsp;value) &nbsp;&nbsp;&nbsp;&nbsp;{ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;value; &nbsp;&nbsp;&nbsp;&nbsp;} }</pre> </p> <p> This implementation simply returns the input value without modifying it. That's a neutral operation, as a test like this demonstrates: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">void</span>&nbsp;AppendHasIdentity(<span style="color:#2b91af;">IDateTimeOffsetAdjustment</span>&nbsp;x) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;x.Append(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">IdentityDateTimeOffsetAdjustment</span>()),&nbsp;x); &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">IdentityDateTimeOffsetAdjustment</span>().Append(x),&nbsp;x); }</pre> </p> <p> These two assertions verify that left and right identity holds. </p> <p> Since <code>Append</code> is associative and has identity, it's a monoid. </p> <p> This holds generally for any method (or function) that returns the same type as it takes as input, i.e. <code>T SomeOperation(T x)</code>. This matches the built-in library in <a href="https://www.haskell.org">Haskell</a>, where <code>Endo</code> is a <code>Monoid</code>. </p> <h3 id="5e1a85ad892b4cd5b9ef269038c1d992"> Conclusion <a href="#5e1a85ad892b4cd5b9ef269038c1d992" title="permalink">#</a> </h3> <p> A method that returns a value of the same type as its (singular) input argument is called an endomorphism. You can compose two such unary operations together in order to get a composed operation. You simply take the output of the first method and use it as the input argument for the second method. That composition is a monoid. Endomorphisms form monoids. </p> <p> <strong>Next:</strong> <a href="http://blog.ploeh.dk/2018/04/03/maybe-monoids">Maybe monoids</a>. </p> </div> <hr> This blog is totally free, but if you like it, please <a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=NZEPYW8KVZ8WL">buy me a cup of coffee</a>. Function monoids http://blog.ploeh.dk/2017/11/06/function-monoids 2017-11-06T06:11:00+00:00 Mark Seemann <div id="post"> <p> <em>Methods are monoids if they return monoids. An article for object-oriented programmers.</em> </p> <p> This article is part of a <a href="http://blog.ploeh.dk/2017/10/06/monoids">series about monoids</a>. In short, a <em>monoid</em> is an associative binary operation with a neutral element (also known as <em>identity</em>). </p> <h3 id="31733b9bd9914ae68fc18afbe8b79e10"> Functions <a href="#31733b9bd9914ae68fc18afbe8b79e10" title="permalink">#</a> </h3> <p> In statically typed C-languages, like C# or Java, methods are typically declared like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Foo</span>&nbsp;Bar(<span style="color:#2b91af;">Baz</span>&nbsp;baz,&nbsp;<span style="color:#2b91af;">Qux</span>&nbsp;qux)</pre> </p> <p> As you'll see in another article, however, <a href="http://blog.ploeh.dk/2018/01/29/argument-list-isomorphisms">you can refactor any method to a method that takes a single argument as input</a>, and returns a single (possibly complex) value as output. In abstract form, we can write it like this: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">Out1</span>&nbsp;Op1(<span style="color:#2b91af;">In1</span>&nbsp;arg) </pre> </p> <p> Another way to abstract a method is by using generics: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:#2b91af;">T</span>&nbsp;Op1&lt;<span style="color:#2b91af;">T1</span>,&nbsp;<span style="color:#2b91af;">T</span>&gt;(<span style="color:#2b91af;">T1</span>&nbsp;x) </pre> </p> <p> Another article demonstrates how <a href="http://blog.ploeh.dk/2018/01/22/function-isomorphisms">this is similar to a generic function</a>. In <a href="http://fsharp.org">F#</a>, for instance, the type of the function would be written as <code>'a -&gt; 'b</code>, whereas in <a href="https://www.haskell.org">Haskell</a> it'd be written <code>a -&gt; b</code>. The way to read this is that the function takes a value of the generic type <code>T1</code>/<code>'a</code>/<code>a</code> as input, and returns a value of the generic type <code>T</code>/<code>'b</code>/<code>b</code> as output. For the rest of this article, I'll favour the Haskell syntax, since it has minimal noise. </p> <p> To be clear, however, although I favour the Haskell syntax because of its succinctness, I don't mean to imply that the functions that I discuss are exclusively <a href="https://en.wikipedia.org/wiki/Pure_function">pure</a> - think of an F# function <code>'a -&gt; 'b</code> which may or may not be pure. </p> <h3 id="6fad691a152f45858592605dd2f9de76"> Binary combination of functions <a href="#6fad691a152f45858592605dd2f9de76" title="permalink">#</a> </h3> <p> A function <code>a -&gt; b</code> is a monoid if <code>b</code> is a monoid. This means that you can combine two functions with the same type. In an object-oriented context, it means that you can combine two methods with the same signature into one method as long as the return type forms a monoid. </p> <p> Consider the following (facetious) C# example. You're trying to establish how secure a <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">GUID</a> is. Primes are important in cryptography, so the more primes a GUID contains, the better... right? </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">const</span>&nbsp;<span style="color:blue;">string</span>&nbsp;primes&nbsp;=&nbsp;<span style="color:#a31515;">&quot;2357bd&quot;</span>; <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;CountPrimes(<span style="color:#2b91af;">Guid</span>&nbsp;g) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;g.ToString(<span style="color:#a31515;">&quot;N&quot;</span>).Count(primes.Contains); }</pre> </p> <p> The <code>CountPrimes</code> method counts the number of prime digits in a given GUID. So far so good, but you also think that hexadecimal notation is more exotic than decimal notation, so surely, the digits A-F are somehow more secure, being more unfamiliar. Thus, you have a method to count those as well: </p> <p> <pre><span style="color:blue;">private</span>&nbsp;<span style="color:blue;">const</span>&nbsp;<span style="color:blue;">string</span>&nbsp;letters&nbsp;=&nbsp;<span style="color:#a31515;">&quot;abcdef&quot;</span>; <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:blue;">int</span>&nbsp;CountLetters(<span style="color:#2b91af;">Guid</span>&nbsp;g) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;g.ToString(<span style="color:#a31515;">&quot;N&quot;</span>).Count(letters.Contains); }</pre> </p> <p> Good, but both of these numbers are, clearly, excellent indicators of how secure a GUID is. Which one should you choose? Both of them, of course! </p> <p> Can you combine <code>CountPrimes</code> and <code>CountLetters</code>? Yes, you can, because, while GUIDs don't form a monoid, the return type <code>int</code> forms a monoid over addition. This enables you to write a <code>Combine</code> method: </p> <p> <pre><span style="color:blue;">public</span>&nbsp;<span style="color:blue;">static</span>&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;Combine( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;f, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;g) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:blue;">return</span>&nbsp;x&nbsp;=&gt;&nbsp;f(x)&nbsp;+&nbsp;g(x); }</pre> </p> <p> Notice that <code>Combine</code> takes two <code>Func&lt;Guid, int&gt;</code> values and return a new <code>Func&lt;Guid, int&gt;</code> value. It's a binary operation. Here's an example of how to use it: </p> <p> <pre><span style="color:blue;">var</span>&nbsp;calculateSecurity&nbsp;=&nbsp;Combine(CountPrimes,&nbsp;CountLetters); <span style="color:blue;">var</span>&nbsp;actual&nbsp;=&nbsp;calculateSecurity(<span style="color:blue;">new</span>&nbsp;<span style="color:#2b91af;">Guid</span>(<span style="color:#a31515;">&quot;10763FF5-E3C8-46D1-A70F-6C1D9EDA8120&quot;</span>)); <span style="color:#2b91af;">Assert</span>.Equal(21,&nbsp;actual);</pre> </p> <p> Now you have an excellent measure of the security strength of GUIDs! 21 isn't <em>that</em> good, though, is it? </p> <p> Antics aside, <code>Combine</code> is a binary function. Is it a monoid? </p> <h3 id="e30b61e234e042efae981ff82df5cc5a"> Monoid laws <a href="#e30b61e234e042efae981ff82df5cc5a" title="permalink">#</a> </h3> <p> In order to be a monoid, <code>Combine</code> must be associative, and it is, as the following <a href="https://fscheck.github.io/FsCheck">FsCheck</a> property demonstrates: </p> <p> <pre>[<span style="color:#2b91af;">Property</span>(QuietOnSuccess&nbsp;=&nbsp;<span style="color:blue;">true</span>)] <span style="color:blue;">public</span>&nbsp;<span style="color:blue;">void</span>&nbsp;CombineIsAssociative( &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;f, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;g, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Func</span>&lt;<span style="color:#2b91af;">Guid</span>,&nbsp;<span style="color:blue;">int</span>&gt;&nbsp;h, &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Guid</span>&nbsp;guid) { &nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2b91af;">Assert</span>.Equal( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Combine(Combine(f,&nbsp;g),&nbsp;h)(guid), &nbsp;&