Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
280 lines (210 sloc) 26.5 KB
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>10 The Hopelessly Egocentric Book Chapter</title>
<link href="stylesheet.css" type="text/css" rel="stylesheet" />
</head>
<body>
<div id="leanpub-main">
<h2 section-num="10" id="the-hopelessly-egocentric-book-chapter"><span class="section-number">10 </span>The Hopelessly Egocentric Book Chapter</h2>
<p>In Raymond Smullyan&#x2019;s delightful book on Combinatory logic, <a href="http://www.amazon.com/gp/product/0192801422?ie=UTF8&amp;tag=raganwald001-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0192801422">To Mock a Mockingbird</a>, Smullyan explains combinatory logic and derives a number of important results by presenting the various combinators as songbirds in a forest. One of his concepts is the Hopelessly Egocentric Bird:</p>
<blockquote>
<p>We call a bird B <em>hopelessly egocentric</em> if for <em>every</em> bird <code>x</code>, <code>Bx = B</code>. This means that whatever bird <code>x</code> you call out to <code>B</code> is irrelevant; it only calls <code>B</code> back to you! Imagine that the bird&#x2019;s name is Bertrand. When you call out &#x201C;Arthur,&#x201D; you get the response &#x201C;Bertrand&#x201D;; when you call out &#x201C;Raymond,&#x201D; you get the response &#x201C;Bertrand&#x201D;; when you call out &#x201C;Ann,&#x201D; you get the response &#x201C;Bertrand.&#x201D; All this bird can ever think about is itself!</p>
</blockquote>
<p>Some folks have proposed that by making Ruby&#x2019;s <code>nil</code> hopelessly egocentric, we can avoid the need for monadic idioms like <code>#andand</code>. Let&#x2019;s examine the idea and see what consequences this has.</p>
<h3 section-num="10.1" id="object-oriented-egocentricity"><span class="section-number">10.1 </span>Object-oriented egocentricity</h3>
<p>One of the tenets of OO programming is that programs consist of <em>objects</em> that respond to <em>messages</em> they send each other. A hopelessly egocentric object is easy to imagine: No matter what message you send it, the hopelessly egocentric object responds with itself:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">class</code> <code class="n">HopelesslyEgocentric</code> <code class="o">&lt;</code> <code class="n">BlankSlate</code>
<code class="n">def</code> <code class="n">method_missing</code><code class="p">(</code><code class="o">*</code><code class="n">arguments</code><code class="p">);</code> <code class="n">self</code><code class="p">;</code> <code class="k">end</code>
<code class="k">end</code>
</pre></div>
</div>
<p>Now you can create a hopelessly egocentric object with <code>HopelesslyEgocentric.new</code> and no matter what message you send it, you will get it back in response. And? What good is this? What can it do? Why should we put it in our Zoo? </p>
<p>In Objective C, nil is hopelessly egocentric. As <a href="http://cocoadevcentral.com/d/learn_objectivec/" title="Cocoa Dev Central: Learn Objective-C">Learn Objective-C</a> puts it, <em>You usually don&#x2019;t need to check for nil before calling a method on an object. If you call a method on nil that returns an object, you will get nil as a return value.</em> The idea here is that instead of getting a <code>NoMethodError</code> when we send a message to nil, we get nil back.</p>
<p>Some people like this so much they&#x2019;ve <a href="http://rubyenrails.nl/articles/2008/02/29/our-daily-method-18-nilclass-method_missing" title="NilClass#method_missing">composed the same semantics for Ruby</a>:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">class</code> <code class="n">NilClass</code>
<code class="n">def</code> <code class="n">method_missing</code><code class="p">(</code><code class="o">*</code><code class="n">args</code><code class="p">);</code> <code class="n">nil</code><code class="p">;</code> <code class="k">end</code>
<code class="k">end</code>
</pre></div>
</div>
<p>Now instead of writing <code>person &amp;&amp; person.name &amp;&amp; person.name.upcase</code> or <code>person.andand.name.andand.upcase</code>, you write <code>person.name.upcase</code> and either get the person&#x2019;s name in upper case or nil. Wonderful! Or is it? Let&#x2019;s take a look at what we&#x2019;re trying to accomplish and the limitations of this approach.</p>
<p>
<strong>queries</strong>
</p>
<p>Hopelessly egocentric nil works reasonably for querying <em>properties</em>, in other words sub-entities when an entity is constructed by composition, things like <code>.name</code>. I&#x2019;m quite happy if <code>person.name</code> returns nil whether we don&#x2019;t have a person or if the person doesn&#x2019;t have a name. And we can extend this to what I would call <em>purely functional transformations</em> like <code>.upcase</code>. Just as <code>''.upcase</code> is <code>''</code>, it is reasonable to think of <code>nil.upcase</code> as nil. </p>
<p>Now let&#x2019;s look at some things that aren&#x2019;t properties and aren&#x2019;t purely functional transformations. What do we do with methods that are intended to <em>update</em> their receiver? Consider a bank account object. Do we really want to write things like:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">account</code> <code class="p">=</code> <code class="n">nil</code>
<code class="n">person</code><code class="p">.</code><code class="n">account</code><code class="p">.</code><code class="n">increment_balance</code><code class="p">(</code>100<code class="p">)</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">nil</code>
</pre></div>
</div>
<p>This makes no sense. If we want to give them a hundred dollars, we had better have their actual account on hand! Clearly there is a huge difference between methods that are <em>queries</em> and methods that are <em>updates</em>. (Note that <code>andand</code> doesn&#x2019;t save us either, except by virtue of being explicit rather than magical so we can eschew it for update methods like <code>#increment_balance</code>.)</p>
<p>
<strong>updates</strong>
</p>
<p>Now that we are talking about methods with side-effects, let&#x2019;s be more specific. Our hopelessly egocentric nil does return nil to any method. But it has another property, it has no side-effects. This is sometimes what we want! Let&#x2019;s look at our nil account again. What about this code:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">account</code><code class="p">.</code><code class="n">update_attribute</code><code class="p">(:</code><code class="n">primary_email</code><code class="p">,</code> <code class="s">'reg@braythwayt.com'</code><code class="p">)</code>
</pre></div>
</div>
<p>To decide what we think of this, we need to be specific about the meaning of nil. Generally, nil means one of two things:</p>
<ol><li>NONE, meaning &#x201C;There isn&#x2019;t one of these,&#x201D; or;</li>
<li>UNKNOWN, meaning &#x201C;There <em>is</em> one of these, but we don&#x2019;t know what it is.&#x201D;</li>
</ol><p><code>person.account.update_attribute(:primary_email, 'reg@braythwayt.com')</code> is an example of why this difference matters. If <code>person.account</code> is an account, we want to update its primary email address, of course. And if <code>person.account</code> is NONE, we might be very happy not updating its primary email address. Perhaps our code looks like this:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">class</code> <code class="n">Person</code> <code class="o">&lt;</code> <code class="n">ActiveRecord</code><code class="p">::</code><code class="n">Base</code>
<code class="n">belongs_to</code> <code class="p">:</code><code class="n">account</code>
<code class="n">def</code> <code class="n">update_email</code><code class="p">(</code><code class="n">new_email</code><code class="p">)</code>
<code class="n">self</code><code class="p">.</code><code class="n">class</code><code class="p">.</code><code class="n">transaction</code> <code class="n">do</code>
<code class="n">update_attribute</code><code class="p">(:</code><code class="n">primary_email</code><code class="p">,</code> <code class="n">new_email</code><code class="p">)</code>
<code class="n">account</code><code class="p">.</code><code class="n">update_attribute</code><code class="p">(:</code><code class="n">primary_email</code><code class="p">,</code> <code class="n">new_email</code><code class="p">)</code>
<code class="k">end</code>
<code class="k">end</code>
# <code class="p">...</code>
<code class="k">end</code>
<code class="n">Person</code><code class="p">.</code><code class="nb">find</code><code class="p">(:</code><code class="n">first</code><code class="p">,</code> <code class="p">:</code><code class="n">conditions</code> <code class="p">=</code><code class="o">&gt;</code> <code class="p">{...}).</code><code class="n">update_email</code><code class="p">(</code><code class="s">'reg@braythwayt.com'</code><code class="o">\</code>
<code class="p">)</code>
</pre></div>
</div>
<p>Meaning, update our person&#x2019;s primary email address, and if they have an account, update it too. If nil means NONE, this works. But what if nil really means UNKNOWN rather than NONE? <strong>Now it is wrong to silently fail</strong>. Let me give you a very specific way this can happen. When performing a database query, we can specify the exact columns we want returned. In Active Record, we might write something like this:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code> <code class="p">=</code> <code class="n">Person</code><code class="p">.</code><code class="nb">find</code><code class="p">(:</code><code class="n">first</code><code class="p">,</code> <code class="p">:</code><code class="n">conditions</code> <code class="p">=</code><code class="o">&gt;</code> <code class="p">{...},</code> <code class="p">:</code><code class="n">select</code> <code class="p">=</code><code class="o">&gt;</code> <code class="s">'id, name'</code><code class="p">)</code>
</pre></div>
</div>
<p>What this means is that there is an <code>account_id</code> column in the <code>people</code> table, however we are deliberately not loading it into <code>person</code>. ActiveRecord will still supply us with a <code>#account</code> method, however it will return nil. This absolutely, positively means that <code>person.account</code> is UNKNOWN, not NONE. There could well be an account in our database for this person, and now if we write:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">update_email</code><code class="p">(</code><code class="s">'reg@braythwayt.com'</code><code class="p">)</code>
</pre></div>
</div>
<p>We do not want it to silently ignore the account email update, because we haven&#x2019;t loaded the <code>account</code> associated model. So for UNKNOWN, our two rules are:</p>
<ol><li>Querying UNKNOWN returns UNKNOWN;</li>
<li>All attempts to update UNKNOWN are errors.</li>
</ol><p>What about NONE? We gave two examples of updates, one of which was a really bad idea,<code>#increment_balance</code>, and the other of which was fine <code>update_attribute(:primary_email, new_email)</code>. Thus we have three rules for NONE:</p>
<ol><li>Querying NONE returns NONE;</li>
<li>Some updates to NONE may return NONE and have no side effects;</li>
<li>Some updates to NONE may be errors.</li>
</ol><p>With a little forethought and design, you may be able to construct one or more classes if your application for which all updates to NONE return NONE and have no side effects. But for all others, methods like <code>#increment_balance</code> represent a semantic problem with using a hopelessly egocentric nil to represent NONE. We also see a problem with writing a hopelessly egocentric nil to handle UNKNOWN: How does it know which methods are queries and which methods are updates?</p>
<p>If we work really hard and eliminate all possibility of an update to NONE being an error, are there any other issues with using a hopelessly egocentric nil? Let&#x2019;s return to our initial case:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">name</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">nil</code>
<code class="n">person</code><code class="p">.</code><code class="n">name</code><code class="p">.</code><code class="n">upcase</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">nil</code>
</pre></div>
</div>
<p>Makes sense. And then we write:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">name</code> <code class="o">+</code> "<code class="p">,</code> <code class="n">esq</code><code class="p">.</code>"
<code class="p">=</code><code class="o">&gt;</code> <code class="n">nil</code>
</pre></div>
</div>
<p>Dubious, but let&#x2019;s go with it. If this makes sense, we ought to be able to write this as well:</p>
<div class="code-block">
<div class="highlight"><pre>"<code class="n">Mister</code> " <code class="o">+</code> <code class="n">person</code><code class="p">.</code><code class="n">name</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">TypeError</code><code class="p">:</code> <code class="n">can</code><code class="o">'</code><code class="n">t</code> <code class="n">convert</code> <code class="n">nil</code> <code class="n">into</code> <code class="n">String</code>
</pre></div>
</div>
<p><a href="http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not-all.html" title="Too much of a good thing: not all functions should be object methods">Why is this an error?</a> Things don&#x2019;t get any better using a hopelessly egocentric nil to handle UNKNOWN. Even if we can get past the issue of update methods, we have another problem that is much more difficult to resolve. UNKNOWN introduces tri-value logic:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">UNKNOWN</code> <code class="o">==</code> <code class="n">Object</code><code class="p">.</code><code class="n">new</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
<code class="n">UNKNOWN</code> !<code class="p">=</code> <code class="n">Object</code><code class="p">.</code><code class="n">new</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
<code class="n">UNKNOWN</code> <code class="o">==</code> <code class="n">UNKNOWN</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
<code class="n">UNKNOWN</code> !<code class="p">=</code> <code class="n">UNKNOWN</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
<code class="n">Object</code><code class="p">.</code><code class="n">new</code> <code class="o">==</code> <code class="n">UNKNOWN</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
<code class="n">Object</code><code class="p">.</code><code class="n">new</code> !<code class="p">=</code> <code class="n">UNKNOWN</code>
<code class="p">=</code><code class="o">&gt;</code> <code class="n">UNKNOWN</code>
</pre></div>
</div>
<p>When you don&#x2019;t know something&#x2019;s value, it is neither equal to nor not equal to any other value, including another unknown value. And our fifth and sixth examples suffer from the same problem as <code>nil + ", esq."</code> vs. <code>"Mister " + nil</code>. We would need to patch all sorts of other objects to make equality testing many many other methods work. (What is <code>42 &lt; UNKNOWN</code>?) But things get worse:</p>
<p>How does <em>truthiness</em> work? In Ruby, you cannot override the way <code>and</code>, <code>or</code>, <code>if</code>, <code>unless</code>, <code>&amp;&amp;</code>, and <code>||</code> work. What are the semantics of <code>if UNKNOWN</code>? What do <code>true &amp;&amp; UNKNOWN</code> or <code>UNKNOWN or true</code> return? Before implementing a true UNKNOWN in any language, I would want those questions answered.</p>
<p>Finally, there is actually a fifth and sixth rule that we are ignoring because these examples are in Ruby rather than a language with an expressive type system. Consider:</p>
<div class="code-block">
<div class="highlight"><pre><code class="s">'Reg Braithwaite'</code><code class="p">.</code><code class="n">wealthy</code>?
<code class="p">=</code><code class="o">&gt;</code> <code class="n">NoMethodError</code><code class="p">:</code> <code class="n">undefined</code> <code class="n">method</code> `<code class="n">wealthy</code>?<code class="s">'</code><code class="err"> for "Reg Braithwaite":Strin\</code>
<code class="n">g</code>
</pre></div>
</div>
<p>And now we write:</p>
<div class="code-block">
<div class="highlight"><pre><code class="n">person</code><code class="p">.</code><code class="n">name</code><code class="p">.</code><code class="n">wealthy</code>? # <code class="n">or</code><code class="p">...</code>
<code class="n">person</code><code class="p">.</code><code class="n">name</code><code class="p">.</code><code class="n">andand</code><code class="p">.</code><code class="n">wealthy</code>?
</pre></div>
</div>
<p>What happens if <code>person.name</code> is NONE? What happens if <code>person.name</code> is UNKNOWN? Our problem here is that <code>#wealthy?</code> is never a valid message to send to something returned by <code>person.name</code>. Our behaviour ought to be:</p>
<ul><li>Sending an invalid message to NONE raises a <code>NoMethodError</code>;</li>
<li>Sending an invalid message to UNKNOWN raises a <code>NoMethodError</code>.</li>
</ul><p>There is no easy way to do this in Ruby, of course. Not only do we have trouble disambiguating queries from updates, we have trouble disambiguating valid from invalid messages.</p>
<p>For all of these reasons, I am loathe to implement a hopelessly egocentric nil and prefer to use an explicit idiom like <code>#andand</code> or <code>#try</code>. With explicit idioms, I can deal with the ambiguity between nil meaning NONE and nil meaning UNKNOWN and make sure my code does not violate the rules given here. But what I like about the <em>idea</em> of a hopelessly egocentric nil is that thinking the consequences provokes me to really think about the semantics of my data schemas.</p>
<p>Representing NONE and UNKNOWN values is a subtle problem requiring a deep and pervasive approach to typing similar to C++&#x2019;s <code>const</code> keyword and/or writing custom <a href="http://en.wikipedia.org/wiki/Null_Object_pattern" title="Null Object pattern - Wikipedia, the free encyclopedia">null objects</a> that understand which methods are safe to respond egocentrically and which are errors.</p>
</div>
<div id="leanpub-toc">
<h2>Table of Contents</h2>
<ol class="toc">
<li class="section"><a href="chap00.html#the-mit-license"><span class="section-number">0.1 </span>The MIT License</a></li>
<li class="section"><a href="chap00.html#preface"><span class="section-number">0.2 </span>Preface</a></li>
<li class="chapter"><a href="chap01.html#introduction"><span class="section-number">1 </span>Introduction</a></li>
<li class="chapter"><a href="chap02.html#kestrels"><span class="section-number">2 </span>Kestrels</a></li>
<li class="section"><a href="chap02.html#object-initializer-blocks"><span class="section-number">2.1 </span>Object initializer blocks</a></li>
<li class="section"><a href="chap02.html#inside-an-idiomatic-ruby-kestrel"><span class="section-number">2.2 </span>Inside, an idiomatic Ruby Kestrel</a></li>
<li class="section"><a href="chap02.html#the-enchaining-kestrel"><span class="section-number">2.3 </span>The Enchaining Kestrel</a></li>
<li class="section"><a href="chap02.html#the-obdurate-kestrel"><span class="section-number">2.4 </span>The Obdurate Kestrel</a></li>
<li class="section"><a href="chap02.html#kestrels-on-rails"><span class="section-number">2.5 </span>Kestrels on Rails</a></li>
<li class="section"><a href="chap02.html#rewriting-returning-in-rails"><span class="section-number">2.6 </span>Rewriting &#x201C;Returning&#x201D; in Rails</a></li>
<li class="chapter"><a href="chap03.html#the-thrush"><span class="section-number">3 </span>The Thrush</a></li>
<li class="section"><a href="chap03.html#let"><span class="section-number">3.1 </span>Let</a></li>
<li class="chapter"><a href="chap04.html#songs-of-the-cardinal"><span class="section-number">4 </span>Songs of the Cardinal</a></li>
<li class="section"><a href="chap04.html#building-a-cardinal-in-ruby"><span class="section-number">4.1 </span>Building a Cardinal in Ruby</a></li>
<li class="chapter"><a href="chap05.html#quirky-birds-and-meta-syntactic-programming"><span class="section-number">5 </span>Quirky Birds and Meta-Syntactic Programming</a></li>
<li class="section"><a href="chap05.html#a-limited-interpretation-of-the-quirky-bird-in-ruby"><span class="section-number">5.1 </span>A limited interpretation of the Quirky Bird in Ruby</a></li>
<li class="section"><a href="chap05.html#embracing-the-quirky-bird"><span class="section-number">5.2 </span>Embracing the Quirky Bird</a></li>
<li class="section"><a href="chap05.html#andand-even-more"><span class="section-number">5.3 </span>Andand even more</a></li>
<li class="chapter"><a href="chap06.html#aspect-oriented-programming-in-ruby-using-combinator-birds"><span class="section-number">6 </span>Aspect-Oriented Programming in Ruby using Combinator Birds</a></li>
<li class="section"><a href="chap06.html#giving-methods-advice"><span class="section-number">6.1 </span>Giving methods advice</a></li>
<li class="section"><a href="chap06.html#the-super-keyword-perhaps-youve-heard-of-it"><span class="section-number">6.2 </span>The super keyword, perhaps you&#x2019;ve heard of it?</a></li>
<li class="section"><a href="chap06.html#the-queer-bird"><span class="section-number">6.3 </span>The Queer Bird</a></li>
<li class="chapter"><a href="chap07.html#mockingbirds"><span class="section-number">7 </span>Mockingbirds</a></li>
<li class="section"><a href="chap07.html#duplicative-combinators"><span class="section-number">7.1 </span>Duplicative Combinators</a></li>
<li class="section"><a href="chap07.html#recursive-lambdas-in-ruby"><span class="section-number">7.2 </span>Recursive Lambdas in Ruby</a></li>
<li class="section"><a href="chap07.html#recursive-combinatorics"><span class="section-number">7.3 </span>Recursive Combinatorics</a></li>
<li class="section"><a href="chap07.html#recursive-combinators-in-idiomatic-ruby"><span class="section-number">7.4 </span>Recursive Combinators in Idiomatic Ruby</a></li>
<li class="section"><a href="chap07.html#the-mockingbird"><span class="section-number">7.5 </span>The Mockingbird</a></li>
<li class="chapter"><a href="chap08.html#refactoring-methods-with-recursive-combinators"><span class="section-number">8 </span>Refactoring Methods with Recursive Combinators</a></li>
<li class="section"><a href="chap08.html#divide-and-conquer"><span class="section-number">8.1 </span>Divide and Conquer</a></li>
<li class="section"><a href="chap08.html#the-merge-sort"><span class="section-number">8.2 </span>The Merge Sort</a></li>
<li class="section"><a href="chap08.html#separating-declaration-from-implementation"><span class="section-number">8.3 </span>Separating Declaration from Implementation</a></li>
<li class="section"><a href="chap08.html#practical-recursive-combinators"><span class="section-number">8.4 </span>Practical Recursive Combinators</a></li>
<li class="section"><a href="chap08.html#spicing-things-up"><span class="section-number">8.5 </span>Spicing things up</a></li>
<li class="section"><a href="chap08.html#building-on-a-legacy"><span class="section-number">8.6 </span>Building on a legacy</a></li>
<li class="section"><a href="chap08.html#seriously"><span class="section-number">8.7 </span>Seriously</a></li>
<li class="section"><a href="chap08.html#separating-implementation-from-declaration"><span class="section-number">8.8 </span>Separating Implementation from Declaration</a></li>
<li class="section"><a href="chap08.html#a-really-simple-recursive-combinator"><span class="section-number">8.9 </span>A Really Simple Recursive Combinator</a></li>
<li class="chapter"><a href="chap09.html#you-cant-be-serious"><span class="section-number">9 </span>You can&#x2019;t be serious!?</a></li>
<li class="section"><a href="chap09.html#string-to-proc"><span class="section-number">9.1 </span>String to Proc</a></li>
<li class="section"><a href="chap09.html#the-message"><span class="section-number">9.2 </span>The Message</a></li>
<li class="chapter"><a href="chap10.html#the-hopelessly-egocentric-book-chapter"><span class="section-number">10 </span>The Hopelessly Egocentric Book Chapter</a></li>
<li class="section"><a href="chap10.html#object-oriented-egocentricity"><span class="section-number">10.1 </span>Object-oriented egocentricity</a></li>
<li class="chapter"><a href="chap11.html#bonus-chapter-separating-concerns-in-coffeescript-using-aspect-oriented-programming"><span class="section-number">11 </span>Bonus Chapter: Separating Concerns in Coffeescript using Aspect-Oriented Programming</a></li>
<li class="chapter"><a href="chap12.html#appendix-finding-joy-in-combinators"><span class="section-number">12 </span>Appendix: Finding Joy in Combinators</a></li>
<li class="section"><a href="chap12.html#languages-for-combinatorial-logic"><span class="section-number">12.1 </span>Languages for combinatorial logic</a></li>
<li class="section"><a href="chap12.html#concatenative-languages"><span class="section-number">12.2 </span>Concatenative languages</a></li>
<li class="chapter"><a href="chap13.html#appendix-source-code"><span class="section-number">13 </span>Appendix: Source Code</a></li>
<li class="section"><a href="chap13.html#kestrels-1"><span class="section-number">13.1 </span>kestrels</a></li>
<li class="section"><a href="chap13.html#thrushes"><span class="section-number">13.2 </span>thrushes</a></li>
<li class="section"><a href="chap13.html#the-cardinal"><span class="section-number">13.3 </span>the cardinal</a></li>
<li class="section"><a href="chap13.html#quirky-birds"><span class="section-number">13.4 </span>quirky birds</a></li>
<li class="section"><a href="chap13.html#bluebirds"><span class="section-number">13.5 </span>bluebirds</a></li>
<li class="chapter"><a href="chap14.html#about-the-author"><span class="section-number">14 </span>About The Author</a></li>
<li class="section"><a href="chap14.html#contact"><span class="section-number">14.1 </span>contact</a></li>
</ol>
</div>
</body>
</html>