As we have seen, the decision of implementing the HQBasis class or
not raises many incompatibilities among the four interfaces; for
instance, for generating system management, problems such as: when do
we compute the HQSysGen of a HQSet if it is included in, do we have
full support for access to constraints like in 
and PPL, or just
low level functions like in Octagon or matrix-based functions like in
New POLKA?
As an example, let us consider this problem: we choose
HQSet
HQSysConnbIneq or HQSet.getNbIneq. If we used the second
approach as currently do the four libraries, that is to say we expose
the getNbIneq function, which returns the number of inequalities
inside the HQSet, in the HQ interface, we somehow expose the nature of
the HQSet class. In our interface, we decided not to use the second
function because we want the HQSet to be as abstract as possible.
Another problem is that, when we call this function, we do not know whether the HQSet is minimized or not. Some transformations of the HQSet can result in different values of its number of inequalities. Therefore, for every operator, we need to pay attention to its detailed semantics.
As we have discussed in 4_subsec:octagons_polyhedra, problems concerning transfer functions are also not trivial. We need to justify our decisions for many other problems such as accessibility scope for objects like vectors, constraints, generators, constraint systems, generating systems, matrices, undefined objects, multiple arguments for the union, projection operators, object versus list of objects for constraints, generators, sets and expressions, signature in imperative mode with several effects, i.e. using returned code in PPL.
Another abstract domain introduced in PPL, the Not-Necessary-Closed, denoted NNC, is not considered in our work [BRZaH02].