Reading questions regarding abstract type inference.

===========================================================================

Consider the problem of literals, such as "nil" value or 0.
A program may have multiple occurrences of 0.  One line of code might compare a temperature against 0, and another might compare an array index against 0, but we don't want to conflate temperatures and array indices in the same abstract type.
How does the static approach (Lackwit) address this problem?
How does the dynamic approach (DynComp) address this problem?

Another problem is of multiple occurrences of "nil" in the source code.
The body of a list length routine would contain a single literal use of "nil".  This gets some type, and it is compared against the cons cells of every argument that is passed to the routine.  This would put every argument to the list length routine in the same abstract type, which is undesirable.
How does the static approach (Lackwit) address this problem?
How does the dynamic approach (DynComp) address this problem?

===========================================================================

Write an abstract interpretation that computes exactly the same result as Lackwit.  (Be sure to state, in English, the meanining of the domain elements.)

Why is Lackwit expressed as type inference rather than some other type of program analysis, such as an abstract interpretation?

===========================================================================

end.