This is Chapter 8 of the book PAIP. It still uses pattern-match and rules to design several simple algorithms to do symbolic math simplification. I just go through the ideas in the book, and design my own program to pass all the cases in the book. The code is in https://github.com/kainwen/paip/tree/master/sym_math2/.

## Run the code

```
~ cd sym_math2
~ make
~ make shell
```

```
1> sym_math_simplify:simplify("int{(2*x+1)/(x^2+x-1), x}").
{log_exp,{binop_exp,'-',
{binop_exp,'+',
{binop_exp,'^',{symbol,x},{number,2}},
{symbol,x}},
{number,1}}}
2> sym_math_simplify:simplify("int{sin{x}/(1+cos{x}), x}").
{negative_exp,{log_exp,{binop_exp,'+',
{cos_exp,{symbol,x}},
{number,1}}}}
```

## Thoughts

### Types are very important

Erlang is dynamic typing language but it provides type specification and dialyzer to do static analysis. But this still needs to pay much more attention and sometimes dialyzer cannot find all the potential issues (see https://stackoverflow.com/questions/43070330/why-erlang-dialyzer-cannot-find-type-error-in-the-following-code/43086266).

At first, I force myself to write type specification in details. But as more code added in, I do not keep this. I still suppose I should do it.

I never try use other static type functional programming language (like SML, Haskell) to write interpreters. Maybe they may provide different tastes.

### Abstract syntax tree

PAIP’s common lisp program depends on the S-exp as syntax tree heavily. Many lisp programmers believe the S-expression is the best part of lisp. But to me, current days, it is very easy to get the syntax tree using some tools, to keep it like a tree seems better for me.

### Rule based system

Any rule based system is just a language. How can we prove the language always give an answer? This is essential the halting problem. To design rules is to design a language. Let’s wait for more discussion on this in later chapters.