The Algebra of Patterns (Extended Version)

I prefer a slightly different algebra of patterns, which works nicely[0] as long as sets of clauses are <i>simplicial</i>[1], which is to say that if any two clauses have patterns that properly intersect, the intersection also occurs as a pattern in the set of clauses: clauses match if their pattern, and no more precise[2] patterns, do.<p><pre><code> isWeekend : Day → String isWeekend(x) := show(x) ++ &quot; is not on the weekend&quot; isWeekend(x &amp; (Sa||Su)) := show(x) ++ &quot; is on the weekend&quot; </code></pre> In exchange for that complication on the structure of well-formed sets of clauses, we get the following simplifications: (a) <i>default</i> need not be special, but is expressed by <i>_</i>[3], and (b) the programmer need only use positive patterns[4].<p>[0] as with Dijkstra&#x27;s def&#x27;ns of <i>if..fi</i> and <i>do..od</i> it&#x27;s possible to extend the order-independence&#x2F;commutativity to non-simplicial sets of clauses without losing runtime determinativeness but at the cost of introducing arbitrariness.<p>[1] this is not quite accurate to the geometric use; does anyone have a better adjective?<p>[2] pedantically speaking, a pattern P is more specific than a pattern Q iff P is congruent to P &amp; Q.<p>[3] as all clauses, not just <i>default</i>, exclude more specific matches<p>[4] negative patterns might still be useful for codegen, but they needn&#x27;t be part of the developer experience. I still need to look at <a href="https:&#x2F;&#x2F;lirias.kuleuven.be&#x2F;retrieve&#x2F;262314&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lirias.kuleuven.be&#x2F;retrieve&#x2F;262314&#x2F;</a> to see how it relates to all this...