<p><pre><code>  foo(X) -&gt;
      case X of 
          bar   -&gt; void;
          _Else -&gt; undefined
      end.
</code></pre>
&gt; <i>would become:</i><p><pre><code>  foo(X) -&gt; foo1(X).

  foo1(bar)   -&gt; void;
  foo1(_Else) -&gt; undefined.
</code></pre>
Incomprehensible rubbish, made more obfuscated by the second form. Okay, X appears to be an identifier bound as a parameter. So then why doesn&#x27;t bar behave that way in<p><pre><code>   foo1(bar)   -&gt; void
</code></pre>
is it because the X symbol is upper case? Or one letter wide? (Yuck, if so.) Or does it have something to do with that semicolon? (Double yuck.)<p>At a glance, how the heck do we know when a symbol denotes a binding, and when it denotes itself?<p>&quot;_Else&quot; is beautiful? It reminds one of the &quot;_Bool&quot; retch, vomited up in C99 by a drunken ISO C committee; but at least that is hidden by a #define bool _Bool that everyone halfway sane uses in its place.<p>In any event, splitting case statements into pattern matching functions isn&#x27;t &quot;lucid&quot;. Unless you&#x27;re doing OOP, it&#x27;s largely stupid. The case statement keeps the relevant cases together. It &quot;en-case-apsulates&quot;, pardon the pun. The only reason that the individual functions retain clarity is that they are grouped close together, so we, the readers, can reconstruct them as the case handling aggregate that they are.