10 Sep 13:15 2013

## resources on static analysis

```Dear list,

I am interested in learning more about static analysis of Haskell code.
Specifically of the relation between arguments of recursive and
non-recursive calls.

For example if we look at the ++ function from Prelude:

(++) []     ys = ys
(++) (x:xs) ys = x : xs ++ ys

amongst others, we could infer the relations:

ys_i+1     = ys_i
(x:xs)_i+1 = xs_i

Searching the web I found several tools (HLint, Haskabelle,
Sourcegraph), but I am interested in the theory behind this. If you
could recommend a paper or a book on this topic I would be grateful.

Thanks,
```
10 Sep 13:21 2013

### Re: resources on static analysis

Not specifically about Haskell, but I read some lecture notes on this topic yesterday (by Michael Schwartzbach, PDF here: http://lara.epfl.ch/web2010/_media/sav08:schwartzbach.pdf).  The notes do a good job of explaining how you set up lattices for various kinds of analyses, and how calculating fixed points over those lattices can yield various sorts of interesting information.  Most of the examples are based on a simple imperative language, but much of the analysis is applicable to Haskell as well.

On 10 September 2013 13:15, Maarten Faddegon wrote:
Dear list,

I am interested in learning more about static analysis of Haskell code. Specifically of the relation between arguments of recursive and non-recursive calls.

For example if we look at the ++ function from Prelude:

(++) []     ys = ys
(++) (x:xs) ys = x : xs ++ ys

amongst others, we could infer the relations:

ys_i+1     = ys_i
(x:xs)_i+1 = xs_i

Searching the web I found several tools (HLint, Haskabelle, Sourcegraph), but I am interested in the theory behind this. If you could recommend a paper or a book on this topic I would be grateful.

Thanks,
_______________________________________________

--
```_______________________________________________
```
10 Sep 13:57 2013

### Re: resources on static analysis

If you are interested in general program analysis, I recommend you the book "Principles of Program Analysis" ]http://www.amazon.com/Principles-Program-Analysis-Flemming-Nielson/dp/3540654100]. It's very complete, and covers the most important kind of analyses that you can do (data-flow, constraint-based, abstract interpretation and type-and-effect systems - the latter is the nearest to Haskell).

If you are interested in analyses that infer relations such as the one shown above, you can check at size and cost analyses. Here are some pointers:
- RAML [http://raml.tcs.ifi.lmu.de/] is based on ML, and includes in its types information about the memory used by each function,
- The PhD thesis of Vasconcelos [http://www.ncc.up.pt/~pbv/research/PB_Vasconcelos_PhD_thesis.pdf] uses types with sizes to infer relations between the sizes of the arguments in a call. It uses Haskell, so it may be the most relevant one,
- In my group we've done some work about size and resource analysis [http://arxiv.org/abs/1308.3940]. It's Prolog-based, but the ideas are general and could be applied to your case.

2013/9/10 Ian Ross
Not specifically about Haskell, but I read some lecture notes on this topic yesterday (by Michael Schwartzbach, PDF here: http://lara.epfl.ch/web2010/_media/sav08:schwartzbach.pdf).  The notes do a good job of explaining how you set up lattices for various kinds of analyses, and how calculating fixed points over those lattices can yield various sorts of interesting information.  Most of the examples are based on a simple imperative language, but much of the analysis is applicable to Haskell as well.

On 10 September 2013 13:15, Maarten Faddegon wrote:
Dear list,

I am interested in learning more about static analysis of Haskell code. Specifically of the relation between arguments of recursive and non-recursive calls.

For example if we look at the ++ function from Prelude:

(++) []     ys = ys
(++) (x:xs) ys = x : xs ++ ys

amongst others, we could infer the relations:

ys_i+1     = ys_i
(x:xs)_i+1 = xs_i

Searching the web I found several tools (HLint, Haskabelle, Sourcegraph), but I am interested in the theory behind this. If you could recommend a paper or a book on this topic I would be grateful.

Thanks,
_______________________________________________

--

_______________________________________________
```_______________________________________________