Check that a value definition does not violate any consumption constraints, via alias analysis.

This is a very subtle part of the language. The basic idea is "the result of an expression aliases everything that goes into it", but this is in practice too restrictive when we have functions (and polymorphic and higher-order functions!) as well. However, we also do not want to make the user-facing type system too complicated.

Our solution is to infer more precise function types, that directly talk about alias information, via parametricity. These never escape into the user-facing language.

Our overall philosophy is that soundness is (of course) non-negotiable, but simplicity is better than flexibility. Futhark is not a language for very fine-grained reasoning about aliasing.

As an example of the compromise, x |> copy works and produces a fresh result, whilst id >-> copy loses freshness information.

Further, we only infer freshness for fully saturated higher-order functions, so refactoring to take advantage of partial application may not work. Likewise, we infer only the freshness of the value a function returns, not of what a returned function in turn returns: that must be declared on the returned lambda itself.