Version 1.1 of ais/ai-00212.txt

Unformatted version of ais/ai-00212.txt version 1.1
Other versions for file ais/ai-00212.txt

!standard 10.01.05 (09)          98-11-21 AI95-00212/00
!class confirmation 98-11-21
!status received 98-11-21
!priority Low
!difficulty Medium
!subject Restrictions on configuration pragmas.
!summary 98-11-21
!question 98-11-21
The permission 10.1.5(9) says "An implementation may place restrictions on configuration pragmas, so long as it allows them when the environment contains no library_items other than those of the predefined environment."
Does this apply when a configuration pragma is used in a compilation with other units (which then only applies to those units)? A poll of Ada experts has turned up a widely varying difference of opinion.
!response 98-11-21
!appendix

****************************************************************

From: 	Tucker Taft[SMTP:stt@inmet.com]
Sent: 	Wednesday, November 18, 1998 10:10 AM

> Depends on how you view the purpose of validation. If it is to ensure a
> higher degree of portability, such tests would be of rather marginal value.
> Reason: RM 10.1.5(9), which in effect is saying: "You want it portable, you
> have to provide the Restrictions pragma before all other compilations of the
> partition." and hence, testing more than that won't help portability.

Even with 10.1.5(9), there is still justification for having configuration
pragmas in a source file that has one or more compilation units.
10.1.5(9) was intended to apply only to pragmas in unitless source files,
I believe.

> Erhard

-Tuck

****************************************************************

From: 	Robert Dewar[SMTP:dewar@gnat.com]
Sent: 	Friday, November 20, 1998 9:21 AM

I agree with Tuck's assessment.

****************************************************************

From: 	Randy Brukardt[SMTP:Randy@rrsoftware.com]
Sent: 	Friday, November 20, 1998 2:01 PM

Tucker says:

>Even with 10.1.5(9), there is still justification for having configuration
>pragmas in a source file that has one or more compilation units.
>10.1.5(9) was intended to apply only to pragmas in unitless source files,
>I believe.

While I agree with Tucker's assessment, I find this last statement a bit
hard to swallow.  I can't imagine what benefit there would be to allowing the
rejection of some environment-wide restrictions pragmas, while requiring
them on specific compilation units. The final effect is the same: the partition
as a whole most obey the restriction.  And the implementation is the same.

Certainly, the wording of 10.1.5(9) does not to restrict its applicability to
certain cases, it applies to any use of a restrictions pragma.

OTOH, if this is the accepted meaning (and I think that the ARG would need
to discuss that), that makes it much easier to revise the tests to include
link-time checks. With the current "optional" meaning, I don't think we want
to change the existing tests, as doing so would compromise coverage of
the checking for the various restrictions.  In that case, adding a few .DEP
tests would be the best solution. If, however, 10.1.5(9) is ruled not to apply
to restrictions pragmas, then the best solution is to modify the existing tests.

					Randy.

****************************************************************

From: 	Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de]
Sent: 	Friday, November 20, 1998 10:09 PM


>Even with 10.1.5(9), there is still justification for having configuration
>pragmas in a source file that has one or more compilation units.
>10.1.5(9) was intended to apply only to pragmas in unitless source files,
>I believe.

I figured I let this rest, since it seemed that we had reached a point of
simply agreeing that we disagree, all being "right" from some valid 
viewpoint. But, as Randy picks it up again, let me chime in by saying that
I couldn't find a shred of evidence in the RM or AARM that
>10.1.5(9) was intended to apply only to pragmas in unitless source files.

I guess it very much depends on the environment model that an implementation
has, whether or not the link-time check is a good model to support. If the
environment "forces" a separation of units destined for a single partition
into a single "sub"environment, then that support seems totally useless -- I
might as well provide my config pragmas first. If, on the other hand, the
units of multiple partitions are compiled into a single otherwise
unstructured environment, from which multiple partitions are later linked,
then this support makes sense, I suppose.

Erhard

****************************************************************

From: 	Robert Dewar[SMTP:dewar@gnat.com]
Sent: 	Friday, November 20, 1998 6:06 PM

<<While I agree with Tucker's assessment, I find this last statement a bit
hard to swallow.  I can't imagine what benefit there would be to allowing the
rejection of some environment-wide restrictions pragmas, while requiring
them on specific compilation units. The final effect is the same: the partition
as a whole most obey the restriction.  And the implementation is the same.
>>

It is definitely important to be able to include configuration pragmas, not
all of which are partition wide, to individual units of a program.

****************************************************************

From: 	Robert Dewar[SMTP:dewar@gnat.com]
Sent: 	Friday, November 20, 1998 9:09 PM

Replying to Erhard, we have:

9   An implementation may place restrictions on configuration pragmas, so
long as it allows them when the environment contains no library_items other
than those of the predefined environment.



Now what does this mean about configuration pragmas that are placed as
part of a unit. Does it mean this unit can only be compiled into
an empty environment? If so, that's odd, note in particular that
there are configuration pragmas that are NOT required to apply to the
whole partition.

If the implementation works by taking config pragmas from such a unit and
making them apply to the parition, it had better be careful to make the
necessary distinction between those that apply to a full partition
anmd those that do not!

I think it is much more natural to read para 9 as Tuck did!

****************************************************************

From: 	Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de]
Sent: 	Saturday, November 21, 1998 10:43 AM

> 9   An implementation may place restrictions on configuration pragmas, so
> long as it allows them when the environment contains no library_items other
> than those of the predefined environment.

I simply read this as: It is legitimate to place the restrictions that
  a) configuration pragmas must be stand-alone units; and
  b) they must be compiled into the environment as the first units.

That plays back the minimum capability required by the Standard. Anything
more is optional. So, to answer your question:
> Now what does this mean about configuration pragmas that are placed as
> part of a unit. 
Easy. They violate the above restriction. 

Erhard

****************************************************************

From: 	Robert Dewar[SMTP:dewar@gnat.com]
Sent: 	Saturday, November 21, 1998 9:50 AM

<<That plays back the minimum capability required by the Standard. Anything
more is optional. So, to answer your question:
> Now what does this mean about configuration pragmas that are placed as
> part of a unit.
Easy. They violate the above restriction.
>>

I do not believe that this can possibly have been the intention, I guess
the ARG will have to discuss this.

****************************************************************

Questions? Ask the ACAA Technical Agent