[Haskell] monods

I have recently read "all about monods". The first chapter provides an example to illustrate that the introduction of Monod is very common and surprising, its example is as follows:

Suppose there is a data type named sheep, and now there is a demand for the father of sheep. We will soon write out the function:

 
Father: sheep-> sheepfather sheep = sheep's dad
 

I'm glad to have finished writing the function. I can test it for QA. The next day, QA rushed over and said, "You can't pass the unit test! Father Dolly goat = Father of Dolly goat. Have you ever been to High School? Dolly goat is cloned! As you can see, Pure Functional Languages are always so embarrassing in real world. There are too many exceptions. It is really difficult for an input to correspond to a definite output. It is useless to complain.CodeRight. This time, we changed the return value of the father function to maybe sheep:

 
Father: sheep-> maybe sheepfather clonesheep = nothingfather Other = Father of just other
 

Well, the function is finally working. But the new demands are coming. They want a function for Grandpa! Write it now

 
GRANDFATHER: sheep-> maybe sheepgrandfather sheep = case (father sheep) of nothing-> nothing just papa-> case papa Of nothing-> nothing just sheep-> father sheep
 

I'm a little nervous, right? It's just my grandfather. Two layers are indented. We can expect that my grandfather's demand will be indented by three layers, and my grandfather's demand will be indented by four layers, if one day you want to know who the goat's ancestor was during the Tang Dynasty, write a function? Good luck.

We all know that the Code is not written in this way. In any case, you have to abstract something. The problem with the above father and grandfather functions is that they do not wrap the details of nothing and just sheep. Once information is leaked, it is hard to control it, so we have to modify the code.

First, observe the grandfather function above. If the father function can receive sheep and nothing, then the two case branches to be processed after just Papa can be merged into one, for example:

 
Father: Maybe sheep-> maybe sheepfather nothing-> nothingfather just clone-> nothingfather just other-> father of other
 

Our grandpa function can be changed:

 
GRANDFATHER: Maybe sheep-> maybe sheepgrandfather M = father $ father m
 

Then it's easier to do things. My great grandfather is father $ Father M, and my high grandfather is father $ Father M. You can just add $, it can always be traced back to the ancestor of the Tang Dynasty. However, as mentioned above, real world is so disgusting that you can always find flaws in your code. For example, if we solve the problem of the parent, what about the mother-archive? What are you looking? What about goat's cousin? You have to write a series of mother functions, Brother functions, Sister functions, and so on. Every one of them has to be the same as the Father function. It honestly distinguishes nothing, just clone, and just other. You know... We cannot write code like this. The problem here is that although we have hidden the work of distinguishing nothing and just m in the father function, this hidden logic cannot be reused, we should put forward this differentiated logic so that everyone can use it.

We should split the father function into two. One is a pure relational function, and the other is a filter function. The relational function does not need to distinguish the input parameters, it determines that the input is not a nothing, nor a multi-profit goat. It must be a normal goat, which is more common than pleasant goat. Of course, its output value is still uncertain.

 
Father: sheep-> maybe sheepfather M = M's father
 

Then create a comb function to filter the results. This function needs to consider various situations, so its input and output values are both maybe sheep. It is also responsible for protecting functions such as father and sister from being crash in exceptional cases, so the function for finding a link should also be passed in as a parameter.

 
Comb: Maybe a-> (a-> maybe B)-> maybe bcomb nothing _-> nothingcomb (just clone) _-> nothingcomb (just other) F-> f Other
 

The first parameter is goat, and the second parameter is a relational function, such as father and sister. After the change, the grandfather's function becomes

 
GRANDFATHER: sheep-> maybe sheepgrandfather M = (just m) 'comb' father
 

If you require a grandfather, add a mother function similar to father. If you do this, you can skip the exception because the comb function has already been used for consideration.

To write this step, we have introduced monad without knowing it. The comb function is actually a> = function, plus the return function and> function, and it is officially promoted to monad. The so-called monad is similar to the design pattern. It defines some paradigms. If you write code based on this paradigm, it will save you a lot of time. Like the design pattern, monad is not mandatory. It is just a suggestion. However, if you write I/O Code and do not follow monad, you will only find trouble. So many exceptions, every function is written once? Please ~~~

----------

The above is my understanding of monad. The introduction of the comb function in "all about monads" is too abrupt, so I am confused for a while. After asking enthusiastic people in Haskell-cafe, I finally realized that,CommunityIt's really a good thing.