!ASIS Issue #100
!topic  A_Configuration_Compilation Unit_Kind
!reference  ASIS 95-3.12.1
!from  Gary Barnes  98-10-05
!keywords  A_Configuration_Compilation Unit_Kind configuration pragmas context
!discussion

From the June 1, 1998 ASIS 2.0.Q,

    A_Configuration_Compilation, -- Corresponds to the whole content of a
                                     -- compilation with no compilation_unit,
                                     -- but possibly containing comments,
                                     -- configuration pragmas, or both.
                                     -- Any Context can have at most one unit
                                     -- of A_Configuration_Compilation kind.
                                     -- A unit of A_Configuration_Compilation
                                     -- does not have a name. This unit
                                     -- represents configuration pragmas that
                                     -- are "in effect".

One curious thing about this compilation Unit_Kind is that there are
apparently no interfaces in the ASIS specification that are capable of
returning a unit having this Unit_Kind.  That would lead to the
question, why does this Unit_Kind exist since it serves no purpose for
the user of the interface?

A second curious thing is the comment that "Any Context can have at
most one unit of A_Configuration_Compilation kind."  Since a Context
is supposed to model an Ada compilation environment, and since Ada
places no restriction on the number of pragma-only configuration
compilations that may occur, why does ASIS create this restriction?

A specific example would be a compilation context that consists of a
user application area plus some number of separately compiled
libraries.  Each library may well have its own set (or sets) of
configuration pragmas and then the application area itself could have
a set (or sets).

Such a situation makes the above comment a bit problematic.  It also
forces the Configuration_Pragmas interface into a confusing position.

   function Configuration_Pragmas (The_Context : in Asis.Context)
                                 return Asis.Pragma_Element_List;

------------------------------------------------------------------------------
-- The_Context    - Specifies the Context to query
--
-- Returns a list of pragmas that apply to all future compilation_unit elements
-- compiled into The_Context.  Pragmas returned by this query should
-- have appeared in a compilation that had no compilation_unit elements.
-- To the extent that order is meaningful, the pragmas should be in
-- their order of appearance in the compilation.  (The order is implementation
-- dependent, many pragmas have the same effect regardless of order.)
--
-- Returns a Nil_Element_List if there are no such configuration pragmas.
--
-- Returns Element_Kinds:
--      A_Pragma
------------------------------------------------------------------------------

A particular Asis.Context may well have multiple separate sets of
configuration pragmas and deciding which set would apply to a future
compilation may well hinge on knowing the future location (which
Asis.Container perhaps?) of the future unit.

Even delving into the past is a problem.  An analysis program that
wished to know which configuration pragmas applied to which units
would be at a complete loss since it would not have any ready way to
know which units might have been affected by the particular set chosen
and returned.

So,

a) Am I correct that there are no interfaces for returning
   A_Configuration_Compilation unit?  (If not, I'd be most curious
   about why it exists as a Unit_Kind?)

b) Does ASIS really wish to pretend that at most one set of
   configuration pragmas can exist within a Context when that is not
   the case for Ada compilation systems?

c) If so, any advice on what to return given a validated compilation
   system capable of having many different sets of configuration
   pragmas within a Context?  (A Context may consist of nothing but a
   collection of libraries and have no obvious component that is "the
   main program", so determining the set affecting the main program
   may not be possible.  Any other choice seems reminiscent of
   flipping a coin.)

d) If not, how best to proceed?  I'm not excited by the idea of
   heading off and implementing an ASIS 2.0 superset if I can find a
   better way.

!resolution  Reject.

Incorporated via editorial changes.  Please see Comment c125.

Please see emails associated with this Issue for answers to the
above questions.