Version 1.1 of ais/ai-00244.txt

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

!standard 10.01.04 (05)          00-10-30 AI95-00244/01
!standard 10.01.04 (06)
!class binding interpretation 00-10-30
!status received 00-10-30
!priority Low
!difficulty Easy
!subject Legal units which depend on illegal units
!summary
!question
The permission (implicitly) granted in 10.1.4(5) for the compiler to accept a compilation unit as legal which depends on an illegal unit in the environment (as allowed by 10.1.4(6)) should be removed. It serves no useful purpose, since 10.2(27) prevents such a program from linking. It is harmful because it violates the design goals of detecting errors as early as possible and providing features that are intuitive to users.
For example, if a compiler inserts the following illegal unit in the environment:
package Error_Unit is Int : Integer := 5.0; -- Error: end Error_Unit;
then the following unit must be accepted without identification of an error:
with Error_Unit; package No_Error_Unit is Ch : Character; end No_Error_Unit;
even though no program can be constructed with this unit.
!recommendation
!wording
!discussion
Since it is implementation-dependent on whether illegal units are accepted into the environment, and since it is implementation-dependent as to how errors are identified, and since no legal program can exist which would be dependent on a consistent answer to this question, we don't answer it.
Note that an implementation could define that a message rejecting a unit depending on an illegal unit does not identify an error, and meet the letter of the standard as it currently exists.
--!corrigendum 10.1.4(5)
!ACATS test
To test this would require depending on both illegal behavior and on error messages: the effect of the language rules would be create a test that could not fail to be passed. This defines minimal value!
!appendix

From: Dan Eilers
Sent: Friday, October 20, 2000 12:23 PM

!topic dependency on illegal unit
!reference RM95-10.1.4(5,6)
!reference RM95-10.2(27)
!from Dan Eilers
!discussion

The permission (implicitly) granted in 10.1.4(5) for the compiler to
accept a compilation unit as legal which depends on an illegal unit
in the environment (as allowed by 10.1.4(6)) should be removed.
It serves no useful purpose, since 10.2(27) prevents such a program
from linking.  It is harmful because it violates the design goals
of detecting errors as early as possible and providing features
that are intuitive to users.

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

From: Tucker Taft
Sent: Friday, October 20, 2000 5:55 PM

It can be quite useful to add a unit to the environment even if it
depends on a unit with errors, so that
future compilations can make better progress.
It is no different, from my view, in saying it is
OK that a compiler keeps going after it encounters the
first error in a given unit, in the hopes of identifying
more errors that need fixing, rather than finding
exactly one error per run of the compiler.

Our compiler compiles multiple compilations per
run of the compiler, and we want it to keep going
even if there are errors detected in earlier units
that are "with"ed by later units.

> ...It is harmful because it violates the design goals
> of detecting errors as early as possible and providing features
> that are intuitive to users.

I think you can safely presume that the compiler will inform
the user that the current unit depends on one with errors.
It is continuing hoping that it can use whatever
information it was able to glean from the error-ful unit
to allow it to catch additional errors in the current unit.

In my experience, when doing a big batch compile of a bunch
of units, it is quite annoying if the compiler just ignores
all units that depend on an earlier unit that had, say,
one missing semicolon.

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

From: Dan Eilers
Sent: Saturday, October 21, 2000 11:54 AM

I am not complaining about the permission of 10.1.4(6) to add illegal
units to the environment.  This clearly is necessary because the
definition of environment is broad enough to included units that
have never even been compiled.  My complaint is that a unit that
depends on such an illegal or never-compiled unit in the library
should itself be considered illegal (even though it too can be entered
in the environment, whether or not it is considered illegal).
10.1.4(5) does not require this to be considered illegal.

> I think you can safely presume that the compiler will inform
> the user that the current unit depends on one with errors.

My complaint is that this should result in an error message
rather than an informational warning or possibly no message at all.

> It is continuing hoping that it can use whatever
> information it was able to glean from the error-ful unit
> to allow it to catch additional errors in the current unit.

Whether or not it is considered to be an error to depend on an
illegal unit has no bearing on whether the compiler continues to
look for further errors.  I am not claiming that this must be
considered to be the type of fatal error that prevents the compiler
from looking for further errors in this compilation unit or any
other compilation units submitted at the same time.

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

From: Robert Dewar
Sent: Saturday, October 21, 2000 7:15 PM

<<My complaint is that this should result in an error message
rather than an informational warning or possibly no message at all.
>>

"error message" is not a technical term, and has no meaning whatsoever
in the context of the RM.

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

From: Dan Eilers
Sent: Monday, October 23, 2000 3:04 AM

I wrote:
%                                  My complaint is that a unit that
% depends on such an illegal or never-compiled unit in the library
% should itself be considered illegal (even though it too can be entered
% in the environment, whether or not it is considered illegal).
% 10.1.4(5) does not require this to be considered illegal.
% ...
% My complaint is that this should result in an error message
% rather than an informational warning or possibly no message at all.

Robert Dewar wrote:
> "error message" is not a technical term, and has no meaning whatsoever
> in the context of the RM.

"Error" is of course a well-defined technical term, see for example 1.1.5,
which includes programs that are "illegal".  Such errors are required
to be detected by an implementation.

"Error message" is of course a message reporting the detection of an Error
by an implementation.

If it is not considered to be illegal for unit A to depend on an
illegal unit B in the environment, then no error messages would be
allowed while compiling A, unless A itself contained errors, just as
no error messages are allowed while compiling a unit C that instantiates
a generic for which the body does not exist, unless C itself contains
errors.

Properly detecting errors in a unit that depends on an illegal unit
is impossible as a practical matter.  Is an implementation allowed to
impose a restriction that the only objects in unit B that can be
referenced from A are those declared prior to the first error in B?

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

From: Robert A Duff
Sent: Monday, October 23, 2000 11:04 AM

Dan says:

> "Error" is of course a well-defined technical term, see for example 1.1.5,
> which includes programs that are "illegal".  Such errors are required
> to be detected by an implementation.

Robert is being a bit overly pedantic, I think.  To fight back, you must
exegete as follows: 1.1.5(2) requires legality errors to be "detected",
and that 1.1.3(4) requires those detected errors to be "identified".

Now, the RM does not say exactly *how* the impl must "identify" those
errors, so it's clearly implementation dependent, to a great extent.
However, if the implementation were to claim that it identifies errors
by doing nothing in the case of errors, and also doing nothing in the
absense of errors, I would say the implementation is clearly not
"identifying" anything.  And anyway, as a practical matter, you won't be
able to validate unless you "identify" errors in a way that people
examining the B test output can understand.

So basically, the issue is whether the implementation is required and/or
allowed to "identify" an error in something that depends on something
else that's illegal.

I must say, this issue is not exactly of the utmost importance.
But Dan is correct that it *is*, formally, a real issue.

I would object to an ACATS test pushing one way or the other.  Therefore
(taking my own advice from a previous meta-argument), I must say the ARG
should not answer the question, or make its priority so low as to never
be on a meeting agenda, or whatever.

> Properly detecting errors in a unit that depends on an illegal unit
> is impossible as a practical matter.  Is an implementation allowed to
> impose a restriction that the only objects in unit B that can be
> referenced from A are those declared prior to the first error in B?

Yes, you can do whatever you like in this regard.  (Just like, as you
well know, you can use whatever error-recovery technique you like
*within* a single unit.)

By the way, what's the "first error"?  Most compilers are multi-pass, so
they won't find the textually-first error first, if the first error is
detected during semantic analysis, and the second is detected during
parsing.  :-)

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

From: Dan Eilers
Sent: Monday, October 23, 2000 1:37 PM

Bob Duff wrote:
> Yes, you can do whatever you like in this regard.  (Just like, as you
> well know, you can use whatever error-recovery technique you like
> *within* a single unit.)

If there is an unwritten implementation permission to reject a unit
which depends on an illegal unit, then we have implementation-dependent
legality, which is anathema.

It's fine to recommend that an implementation try its best to do
error recovery, and its fine to allow an illegal unit to be entered
into the environment, but it serves no purpose to require that a unit
that depends on an illegal unit be considered legal, (as the RM
apparently requires), or even to allow it to be considered legal
(as you propose).

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

From: Robert Dewar
Sent: Tuesday, October 24, 2000 6:20 AM

<<Robert is being a bit overly pedantic, I think.  To fight back, you must
exegete as follows: 1.1.5(2) requires legality errors to be "detected",
and that 1.1.3(4) requires those detected errors to be "identified".
>>

Of *course* there is no such requirement, and if anyone had suggested
that it be put in, there would have been serious objections, from me
if no one else.

Here is the quote:

    4  Identify all programs or program units that contain errors whose
       detection is required by tbvhis International Standard;

That's VERY VERY different from identifying the errors. For example an
implementation can identify the program units that contain errors simply
by not generating code for them with no other identification of any
kind and that CLEARLY meets the above requirement. Please don't invent
what is not there!

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

From: Robert A Duff
Sent: Tuesday, October 24, 2000 8:50 AM

> Of *course* there is no such requirement, ...

Yes, of course I should have said "identify the units" rather than
"identify the [individual] errors".

The point is that Dan is correct in saying that the implementation has
to do *something*, depending on whether so-and-so unit is defined to be
illegal.

I happen to think it's too minor a point to worry about.

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

From: Randy Brukardt
Sent: Monday, October 30, 2000 9:22 PM

Bob Duff said:

> I must say, this issue is not exactly of the utmost importance.
> But Dan is correct that it *is*, formally, a real issue.
>
> I would object to an ACATS test pushing one way or the other. Therefore
> (taking my own advice from a previous meta-argument), I must say the ARG
> should not answer the question, or make its priority so low as to never
> be on a meeting agenda, or whatever.

I don't think you have to worry about an ACATS test here. It would only
apply to an implementation which claimed to allow illegal units in the
environment, and it could never have a value in a real program (because such
a program cannot be linked).

A B-Test something like:

    package Error_Unit is
	  Int : Integer := 5.0; -- Error:
    end Error_Unit;

    with Error_Unit; -- Error: N/A
    package No_Error_Unit is
        Ch : Character; -- OK.
    end No_Error_Unit;

would test it, I suppose.

It seems to me that it would be easy enought to fix the problem, but I'm
pretty sure it isn't worth the effort. Dan's concern about
implementation-dependence isn't a real one, given that all of this is
implementation-dependent anyway.

			Randy.

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

Questions? Ask the ACAA Technical Agent