99 days of code - Pattern Matching meditations
Tags: haskell, functional, 100daysofcode, patterns
Published: 2020-10-08 05:35:11

> Pattern matching consists of specifying patterns to which some data should conform and then checking to see if it does and deconstructing the data according to those patterns.

My first realization, the mini genesis of understanding, is that pattern matching is like comparing two random patterns, like gathering all the patterns, recognizing we have some patterns and then comparing them against each other, with each other. But, in the quote I see that I need to specify a pattern and then compare that with some data, after which if I find a match, if they fit, if they like each other, if they conform, meaning if the data conforms to some specific pattern then *we can deconstruct the data according to some patterns*. Now comes to me, why do we need to deconstruct the data? Do we now need new patterns for the deconstruction process. Why do I ask these questions, am I just adding words while inwardly I just hold this definition in my mind, because how can I hold it in silence and think about it. Maybe these are my thought, are they? How do we pattern match?

Pattern matching is like stringing together many `if then else` statements which individually define a kind of a pattern, maybe better say *define a pattern*, for there are *kind* types in Haskell I think, something kind is in Haskell. So each line of the code would consist of a definition, in a body, as a body of a function, describing a pattern, which are then checked from top to bottom. 

> what does from top to bottom mean? In the computer, as Flynn asked “The Grid. A digital frontier. I tried to picture clusters of information as they moved through the computer. What did they look like? Ships, motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then, one day I got in...” 

I remember hearing ?code is data, data is code", an ancient mantra from the time of lisp ages, it still lives, it still comes from time to time on hacker news. I am too still in silent awe of lisp, its essence being like a language for a language, enabling the programmer to create something that only from far away seems alive, not in a biological way anyway. 

> By time-sharing, I meant an operating system that permits each user of a computer to behave as though he were in sole control of a computer, not necessarily identical with the machine on which the operating system is running. (John McCarthy)

Haskell wikibooks gives a somewhat different definition, one that compares values against patterns, where there is a separation but also where value is also a pattern. Here the realization is described in layers, and then if desired, we can name a variable after a successful match. Are these variables now values? Are those values make a body of a function, are these functions connected, interlinked, with variable names. Yes, Haskell has names, but they are uniquely different, we cannot name two things with the same name, then our function, our whole process becomes polluted. In mathematics we have something called total or pure function, what I pay attention to are the words pure in pure functional programming, total function which sounds a bit dirtier that pure, but it is just a different view of the whole, a uniquely identifiable whole, where each speck of Haskell dust creates the whole picture, so pure functional programming enables one to zoom out further, to see the repeating steps and to remove the glitches, remove the steps that loop around. 

> In pattern matching, we attempt to match values against patterns and, if so desired, bind variables to successful matches. 

So how to create patterns? What would be the most basic pattern there is. Well, Anything could be a good pattern!
Haskell wiki uses the `map` definition:

```haskell
map _ []     = []
map f (x:xs) = f x : map f xs
```
So we have a name `map` which is the name of our function, and notice too that the name itself is a description of sort, a *mapping* as Hutton calls it in Programming Haskell, "a function is a *mapping*..." and mapping is like a *product* in the sense is that our steps seem to be complete, collectively covering the whole space, every cell in the domain gets interlinked with the codomain. So first we map anything with anything, it seems to me we do not know what we are mapping or we might also say we are mapping everything with everything, what ever we take that we give back, but first there one big nothing `map _ [] = []`. We even do not name it, we write the pattern as empty space, as an underline and that underline we bind with square brackets which seem to merely point towards the realization that true, we have nothing, meaning we can have anything. 

> In fact, formally, this process of enumerating all the possible ways to constuct a datatype for the purpose of scrutinizing it through a *case expressions* is called *pattern matching*. 

On googling the "pattern matching" I stumble upon the term two, three, four-way matching describing several patterns that happen in accounting, these patterns consist of complex bodies, that look like code, that are code, an algorithm, of six steps and six actions, in the middle with an `if then else` body defined like 

```haskell

if tolerances are 
  met then no holds are placed
  not met then a hold is placed

-- which could we realized in Haskell like

if tolerances are met
then no holds are placed
else hold is is placed
```

But are these holds of the same type? The accounting pattern is a real life situation, a reliance on the human to *typecheck* the tolerances, a job. Are jobs like various strictly defined types, and we human play the role of a typechecker, does our case analysis, our pattern definitions that make the body of a function, are they of the same type? A type like a natural, like a convertible, like a person, like something unique that makes many, like a pattern, an axiom from which we deconstruct our patterns of computation? 

P.s. Quotes are from A Type Of Programming book, and Learn You A Haskell for Great/greater? good