While APRON's members prefer to minimize the number of changes required to adopt the new interface, we are free of that obligation. This leads to several differences, among which the most observable is the way that we design the new interface and present the problems.
In HQ, we divide our approach into two different parts for clarity, and to simplify the problems. The first part focuses only on the interface, using a high level language like Java, with an object-oriented approach, thus hiding as many as possible implementation issues. The second part, alongside this interface, presents the problems not directly related to the interface, such as how we handle exceptions, how we convert from the javadoc-generated interface to other languages such as C, Ocaml, etc.
In APRON however, one immediately goes into details, by attacking the is_bottom operator! Then a black box called manager is designed in order to keep information of algorithm selection, exception flags, etc. An advantage of this approach is that we can analyze the problems in more details.
More important, HQ appoach is in fact PIPS-oriented, since the author
works in PIPS development group. The APRON approach is in fact a
layered aproach that needs to take into account other analyzers, since
its members are ASTREE and NBAC developers. In
4_fig:HQ_APRON_approaches, on the left hand side, we see
APRON approach with several levels among which, the APRON project
works on level 
. Level 
concerns the abstract domains'
implementations, which are in fact the existing libraries. On the
right hand side, we have HQ approach and the objective to be able to
use these available libraries.
Furthermore, a plus for the HQ approach is that it deals with the robustness issue, i.e. exception handling. In our opinion, these two approaches complement each other, at some levels; however, APRON's prototyped solution seems to be too specific, since many of its solutions are based on previous decisions that were made by APRON's members. For instance, the structure manager deals with too much information including exception handlers, while we would prefer a simpler, yet standard way that uses returned codes to indicate exceptions.
In conclusion, our HQ interface is built in order to serve the APRON's project to build the common interface, which itself will be accepted and implemented by APRON's members.
