Elaboration_check For Instantiations

Elaboration_check For Instantiations

[Charles H. Sampson]

     Apology in advance: I don't get to read this newsgroup as much as 
I would like.  I feel certain that my question has been discussed at 
great length, but I haven't been able to locate it in any FAQ.  If my 
feeling is right, just give me a reference, rather than opening the 
whole issue again.

     The instantiation in the following code was valid in Ada 83:

          PACKAGE Ginspec IS

             GENERIC
                Param : IN Integer;
             PROCEDURE Template;

             PROCEDURE Instantiation IS NEW Template (1);

          END Ginspec;

     If it wasn't valid, at least it worked in several compilers and I am 
aware of a healthy body of code that makes use of this capability.  It 
is no longer valid in Ada 95, thanks to 3.11(13).

     My question is, why was this change made?  Skimming the rationale, 
I see no mention of it.  I don't recall it being discussed in any paper 
on 83/95 incompatibilities that I've read.

 				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

     Sigh.  When I said that my sample code was legal in Ada 83, I 
thought I saw some loose wording in the LRM that would allow it, al-
though it appeared that the intent was to discourage it, at the least.  
Now, however, it seems to be illegal in Ada 83 as well, by 3.9(7).

     When I said that it worked in several compilers, I know of at 
least three.  When I said that a healthy body of code exists using the 
"feature", that body includes a large number of packages supplied by an 
Ada compiler vendor!

 				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Robert Dewar]

Charles says

          PACKAGE Ginspec IS

             GENERIC
                Param : IN Integer;
             PROCEDURE Template;

             PROCEDURE Instantiation IS NEW Template (1);

          END Ginspec;

was legal in Ada 83. That is true, it is also legal in Ada 95. However
in either version of the language it must raise Program_Error at runtime.
Indeed GNAT will say:

     1.           PACKAGE Ginspec IS
     2.
     3.              GENERIC
     4.                 Param : IN Integer;
     5.              PROCEDURE Template;
     6.
     7.              PROCEDURE Instantiation IS NEW Template (1);
                     |
        >>> warning: cannot instantiate "Template" before body seen
        >>> warning: Program_Error will be raised at run time

     8.
     9.           END Ginspec;

Any Ada 83 compiler that executes this code without raising a Program_Error
exception is seriously broken, assuming you have set the options for full
runtime checking according to the RM.

No Ada 83 compiler I have worked with was broken in this respect.

As to why this "restriction" is here, the point is that the model of
generics is that the body must be available to the compiler at the
point of instantiation, or more accurately that at runtime, the body
must have been elaborated. 

Just think about it. When you instantiate, you logically create a copy
of the body, which is elaborated at the point of the instantiation. How
could you create and elaborate the body of the instantiation if you have
not yet elaborated the body of the generic itself.

For example, consider that initializations in the body of the generic may
call functions within the body of the same generic. If the body is not
around, how could these calls be made?

Re: Elaboration_check For Instantiations

[Tucker Taft]

Charles H. Sampson (csampson@cod.nosc.mil) wrote:

:      Sigh.  When I said that my sample code was legal in Ada 83, I 
: thought I saw some loose wording in the LRM that would allow it, al-
: though it appeared that the intent was to discourage it, at the least.  
: Now, however, it seems to be illegal in Ada 83 as well, by 3.9(7).

Actually, it is not illegal.  It "simply" raises Program_Error
at run-time (in Ada 83 and Ada 95), due to violating the checks
regarding access before elaboration.  In any case, there was no
change in the rules in this area between Ada 83 and Ada 95.
Apparently the wording in Ada 95 is clearer on the subject 
(at least to you ;-).

:      When I said that it worked in several compilers, I know of at 
: least three.  When I said that a healthy body of code exists using the 
: "feature", that body includes a large number of packages supplied by an 
: Ada compiler vendor!

Well, then I guess these compilers all had a common bug.  Alternatively,
the code was compiled with Elaboration_Check suppressed.  You
could add "pragma Suppress(Elaboration_Check);" to the above code,
and it would probably not raise Program_Error (though it would then be
officially erroneous, per RM95 11.5(26)).

:  				Charlie
: --
: ******

:     If my user name appears as "csampson", remove the 'c' to get my
: correct e-mail address.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Elaboration_check For Instantiations

[Robert Dewar]

Tucker said

<<Well, then I guess these compilers all had a common bug.  Alternatively,
the code was compiled with Elaboration_Check suppressed.  You
could add "pragma Suppress(Elaboration_Check);" to the above code,
and it would probably not raise Program_Error (though it would then be
officially erroneous, per RM95 11.5(26)).>>


Actually, GNAT would still raise Program_Error. This particular case is
easily caught at compile time, and GNAT actually replaces the instantiation
by a "raise Program_Error" statement. There is no runtime check to be
suppressed, so the pragma Suppress has no effect!

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

     I suppose that the best thing to do when you make a very public 
boo-boo is to be quiet and hope that everybody forgets about it as soon 
as possible, but I'm too old to start that now.  I'll "contribute" to 
this thread a little longer.

In article <EIK5DE.JpG.0.-s@inmet.camb.inmet.com>,
Tucker Taft <stt@houdini.camb.inmet.com> wrote:
>Charles H. Sampson (csampson@cod.nosc.mil) wrote:
>
>:      Sigh.  When I said that my sample code was legal in Ada 83, I 
>: thought I saw some loose wording in the LRM that would allow it, al-
>: though it appeared that the intent was to discourage it, at the least.  
>: Now, however, it seems to be illegal in Ada 83 as well, by 3.9(7).
>
>Actually, it is not illegal.  It "simply" raises Program_Error
>at run-time (in Ada 83 and Ada 95), due to violating the checks
>regarding access before elaboration.  In any case, there was no
>change in the rules in this area between Ada 83 and Ada 95.
>Apparently the wording in Ada 95 is clearer on the subject 
>(at least to you ;-).

     You're right about that.  I do find the new wording clearer.
>
>:      When I said that it worked in several compilers, I know of at 
>: least three.  When I said that a healthy body of code exists using the 
>: "feature", that body includes a large number of packages supplied by an 
>: Ada compiler vendor!
>
>Well, then I guess these compilers all had a common bug.  Alternatively,
>the code was compiled with Elaboration_Check suppressed.  You
>could add "pragma Suppress(Elaboration_Check);" to the above code,
>and it would probably not raise Program_Error (though it would then be
>officially erroneous, per RM95 11.5(26)).

     One of the compilers that I thought accepted this construct actu-
ally disallows it, but in a non-standard manner.  (This is a very highly 
respected Ada 83 compiler.)  It compiles that entire package, specifica-
tion and body, with no warnings.  No "Execution of this construct will 
cause Program_error to be raised."  However, when you try to link the 
programs, you're told that the specification is obsolete.  In other 
words, the spec compiles o. k., but compiling the body obsoletes the 
spec.  Of course, recompiling the spec will obsolete the body, etc.

     I think I know where I went wrong on this whole issue.  We've been 
given the task of porting an Ada 83 program, moving it to Ada 95 at the 
same time.  As part of our contract we've been given the Ada 95 compiler 
that we must use and the existing Ada 83 code, but not the compiler that 
that code was compiled with.  We have been assured that this code is ex-
actly the code of the current running program.  I probably should have 
taken that assurance with a grain of salt.

 				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

In article <dewar.877716708@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Tucker said
>
><<Well, then I guess these compilers all had a common bug.  Alternatively,
>the code was compiled with Elaboration_Check suppressed.  You
>could add "pragma Suppress(Elaboration_Check);" to the above code,
>and it would probably not raise Program_Error (though it would then be
>officially erroneous, per RM95 11.5(26)).>>
>
>
>Actually, GNAT would still raise Program_Error. This particular case is
>easily caught at compile time, and GNAT actually replaces the instantiation
>by a "raise Program_Error" statement. There is no runtime check to be
>suppressed, so the pragma Suppress has no effect!

     Are you sure about that, Robert?  (Never fearing, he leaps back 
into the fray.)  11.5(2) says that language-defined checks, which in-
clude Elaboration_check, have to be made at run time and 3.11(14) says 
that Program_error is raised if Elaboration_check fails.

     Of course, 11.5(1) says that pragma Suppress "gives permission to 
an implementation" to omit the check, so the GNAT implementation is 
technically correct, at least.

 				Charlie


--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Robert Dewar]

Charles said

<<     One of the compilers that I thought accepted this construct actu-
ally disallows it, but in a non-standard manner.  (This is a very highly
respected Ada 83 compiler.)  It compiles that entire package, specifica-
tion and body, with no warnings.  No "Execution of this construct will
cause Program_error to be raised."  However, when you try to link the
programs, you're told that the specification is obsolete.  In other
words, the spec compiles o. k., but compiling the body obsoletes the
spec.  Of course, recompiling the spec will obsolete the body, etc.
>>

This is non-conforming behavior. It should be reported as a bug if the
vendor is still supporting the compiler. There is nothing illegal about
this construct (the warning that GNAT gives is of course just that, a 
warning).

This program *must* execute, and *must* raise Program_Error.

Re: Elaboration_check For Instantiations

[Robert Dewar]

Charlie says

<<     Are you sure about that, Robert?  (Never fearing, he leaps back
into the fray.)  11.5(2) says that language-defined checks, which in-
clude Elaboration_check, have to be made at run time and 3.11(14) says
that Program_error is raised if Elaboration_check fails.

     Of course, 11.5(1) says that pragma Suppress "gives permission to
an implementation" to omit the check, so the GNAT implementation is
technically correct, at least.>>


You are making a common mistake, GNAT is entirely correct. Detecting a check
that fails at compile time and compiling the appropriate raise is of course
completely permissible, and indeed highly desirable (note that annex H 
requires that a compiler that *does* detect such a situation at compile
time *must* output a warning).

Why is this correct? Becuase it is behaviorally equivalent to doing the
check at runtime. I often find that people do not understand the critical
as-if principle that applies to all compiler code generation. This is such
a case. Generating the raise of PE behaves *exactly* "as if" the check were
done at runtime and is therefore fine.

The whole point of 11.5(1) allowing you NOT to omit the check is precisely
to deal with cases like this, where it would take extra time and code to
omit the check. The purpose of Suppress is to permit the compiler to speed
up the code by omitting the check. It is *NOT* to guarantee that the 
exception will not be raised. 

So, yes, I am 100% sure!

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

In article <878068940.763599@wagasa.cts.com>,
Keith Thompson <kst@king.cts.com> wrote:
>Charles H. Sampson (me) wrote:
>[...]
>>      You are right, the GNAT implementation is entirely correct.  I 
>> must have mislead you when I said "technically correct".  Technically 
>> correct is correct, no doubt about it.  All I meant was that GNAT is not 
>> following the programmer's wishes.  If Suppress(Elaboration_check) is 
>> written, then the programmer doesn't want the check made; if the check 
>> is not made then Program_error can't be raised.  The programmer's wisdom 
>> in making such a request is another discussion.
>> 
>>  				Charlie
>
>As is the programmer's wisdom in assuming that pragma Suppress means
>the check won't be made.
>
>The intent of pragma Suppress is to improve the efficiency of generated
>code by inhibiting checks that the programmer knows will not fail.
>Suppressing a check that would fail if it were not suppressed, as in
>the following:
>
>    X : Some_Integer_Subtype := Some_Integer_Subtype'Last;
>
>    declare
>	pragma Suppress(Range_Check);
>    begin
>	X := X + 1;
>    end;
>
>is a misuse of the pragma, and results in erroneous execution (and
>arbitrarily nasty results).  For example, the compiler is entitled to
>assume that X is in the range of its subtype after the assignment, and
>to perform optimizations based on that assumption.  The more clever the
>compiler, and the more aggressively it optimizes, the more likely it is
>to mess things up.

     A bunch of very good points and I certainly don't want to be put 
into the position of defending anyone who tries to achieve some result 
by an erroneous execution.  I'm big on writing portable code and errone-
ous programs (forgive the ellipsis) are anathema to me.  However, I have 
never been happy as a programmer when a compiler says, "I'm smarter than 
you are and I'm not going to allow you to do what you want."  When I was 
a compiler writer, I tried to keep my compilers from doing that.

     Now that doesn't quite apply to the current case, because the RM 
allows the programmer's "suggestion" to be ignored.  Nevertheless, it's 
very close in spirit.  The existence of Suppress(Elaboration_check) 
strongly indicates that the programmer wants the check suppressed, as 
does Suppress(Range_check).  Any argument about erroneousness that is 
applicable to the former can also be made for the latter.

 				Charlie

--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Keith Thompson]

Charles H. Sampson (csampson@cod.nosc.mil) wrote:
[...]
>      You are right, the GNAT implementation is entirely correct.  I 
> must have mislead you when I said "technically correct".  Technically 
> correct is correct, no doubt about it.  All I meant was that GNAT is not 
> following the programmer's wishes.  If Suppress(Elaboration_check) is 
> written, then the programmer doesn't want the check made; if the check 
> is not made then Program_error can't be raised.  The programmer's wisdom 
> in making such a request is another discussion.
> 
>  				Charlie

As is the programmer's wisdom in assuming that pragma Suppress means
the check won't be made.

The intent of pragma Suppress is to improve the efficiency of generated
code by inhibiting checks that the programmer knows will not fail.
Suppressing a check that would fail if it were not suppressed, as in
the following:

    X : Some_Integer_Subtype := Some_Integer_Subtype'Last;

    declare
	pragma Suppress(Range_Check);
    begin
	X := X + 1;
    end;

is a misuse of the pragma, and results in erroneous execution (and
arbitrarily nasty results).  For example, the compiler is entitled to
assume that X is in the range of its subtype after the assignment, and
to perform optimizations based on that assumption.  The more clever the
compiler, and the more aggressively it optimizes, the more likely it is
to mess things up.

References:

RM95-11.5(26):
    If a given check has been suppressed, and the corresponding error
    situation occurs, the execution of the program is erroneous.

RM95-11.5(29) (a note):
    There is no guarantee that a suppressed check is actually removed;
    hence a pragma Suppress should be used only for efficience reasons.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com <*>
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
San Diego, California, USA
"Simba, you have forgotten me.  I am your father.  This is CNN." -- JEJ

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

Robert Dewar wrote:
>Charlie (me) says
>
><<     Are you sure about that, Robert?  (Never fearing, he leaps back
>into the fray.)  11.5(2) says that language-defined checks, which in-
>clude Elaboration_check, have to be made at run time and 3.11(14) says
>that Program_error is raised if Elaboration_check fails.
>
>     Of course, 11.5(1) says that pragma Suppress "gives permission to
>an implementation" to omit the check, so the GNAT implementation is
>technically correct, at least.>>
>
>
>You are making a common mistake, GNAT is entirely correct. Detecting a check
>that fails at compile time and compiling the appropriate raise is of course
>completely permissible, and indeed highly desirable (note that annex H 
>requires that a compiler that *does* detect such a situation at compile
>time *must* output a warning).

     I'm quite aware of this principle.  I call it the "no harm, no 
foul" principle: If the program executes correctly, it doesn't matter 
what kind of code was generated.  (That applies only to program seman-
tics.  When efficiency considerations arise, it can matter very much.)

     It's amazing how many don't understand this.  (A common mistake, 
as you characterized it.)  The developers of one ill-fated Ada 83 com-
piler insisted on generating code for initializing arrays one element at 
a time, claiming that this is what the RM required.  I was unable to 
convince them that, even if their interpretation were correct, if the 
compiler was able to determine that the initialization could not raise 
an exception then "pre-initialization" was o. k.

>Why is this correct? Becuase it is behaviorally equivalent to doing the
>check at runtime. I often find that people do not understand the critical
>as-if principle that applies to all compiler code generation. This is such
>a case. Generating the raise of PE behaves *exactly* "as if" the check were
>done at runtime and is therefore fine.
>
>The whole point of 11.5(1) allowing you NOT to omit the check is precisely
>to deal with cases like this, where it would take extra time and code to
>omit the check. The purpose of Suppress is to permit the compiler to speed
>up the code by omitting the check. It is *NOT* to guarantee that the 
>exception will not be raised. 
>
>So, yes, I am 100% sure!

     You are right, the GNAT implementation is entirely correct.  I 
must have mislead you when I said "technically correct".  Technically 
correct is correct, no doubt about it.  All I meant was that GNAT is not 
following the programmer's wishes.  If Suppress(Elaboration_check) is 
written, then the programmer doesn't want the check made; if the check 
is not made then Program_error can't be raised.  The programmer's wisdom 
in making such a request is another discussion.

 				Charlie

--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Robert Dewar]

Charlie said

<<     Now that doesn't quite apply to the current case, because the RM
allows the programmer's "suggestion" to be ignored.  Nevertheless, it's
very close in spirit.  The existence of Suppress(Elaboration_check)
strongly indicates that the programmer wants the check suppressed, as
does Suppress(Range_check).  Any argument about erroneousness that is
applicable to the former can also be made for the latter.>>

You are really trying hard to spread disinformation and confusion here :-)

Yes, of course the comments about erroneousness of course apply to
suppressing elaboration checks and suppressing range checks.

If you say

pragma Suppress (Elaboration_Check);

You are telling the compiler: I have analyzed my program carefully and I
am sure that there are no instances of access before elaboration. I am sure
enough that you may consider any instance of such access to be erroneous,
and do whatever you like. I hope you will be able to use this information
I am supplying to improve the quality of the generated code.

It sounds like Charlie thinks that the statement means something like

I really don't want you to check for access before elaboration. I want
you to skip that check, and then carry on and do the "right thing". The
trouble is that there is not the slightest hint in the RM of what the
"right thing" might be here, since the RM gives not the slightest clue
of the semantics of such a situation.

Charlie, you really need to adjust your whole view of pragma Suppress.
It is completely wrong!

Robert Dewar
Ada Core Technologies

Re: Elaboration_check For Instantiations

[W. Wesley Groleau x4923]

> .....  However, I have
> never been happy as a programmer when a compiler says, "I'm smarter 
> than you are and I'm not going to allow you to do what you want."  

This is the argument many C programmers use against Ada.  Those that
really understand C AND never make mistakes write working programs.
The rest spend their lives debugging.

If an Ada programmer takes this attitude, he'd better _really_ 
understand Ada--well enough to not misunderstand whatever 
non-intuitive construct slipped past the language designers.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Elaboration_check For Instantiations

[Tom Moran]

>> never been happy as a programmer when a compiler says, "I'm smarter 
>> than you are and I'm not going to allow you to do what you want."  

>This is the argument many C programmers use against Ada.  Those that
>really understand C AND never make mistakes write working programs.
  Unless the compiler is buggy, the fact it won't allow something the
programmer wrote is proof the programmer either did not understand the
language or made a mistake writing it.  So the compiler has
demonstrated that it is, in fact, smarter than the programmer. ;)

Re: Elaboration_check For Instantiations

[Robert Dewar]

Charles Sampson says

<<     You are right, the GNAT implementation is entirely correct.  I
must have mislead you when I said "technically correct".  Technically
correct is correct, no doubt about it.  All I meant was that GNAT is not
following the programmer's wishes.  If Suppress(Elaboration_check) is
written, then the programmer doesn't want the check made; if the check
is not made then Program_error can't be raised.  The programmer's wisdom
in making such a request is another discussion.

                                Charlie>>


No, that's an incorrect viewpoint. The programmer is NOT saying that
they do not WANT the check, they are saying they do not NEED the check.
(because they know that the checked condition cannot occur). That is
a HUGE difference.

pragma Suppress (x)

does NOT mean "please suppress all checks for x", it means "I know my
program has no instances of violations of check x, so feel free to
omit checks for x if this will speed up the code."

Note that if a program with Suppress fails a check, then it is erroneous,
so a programmer cannot be expressing a wish about how the erroneous program
is to be treated.

A programmer who writes pragma Suppress not understanding this is not
"unwise", just ignorant of the meaning of Suppress in Ada, a common
failing of understanding.

GNAT is *exactly* following the programmer's wishes, but only if the 
programmer knows Ada! If the programmer is writing things down in
Ada thinking they mean something different from how they are defined,
then yes indeed, GNAT hopefully will *not* be following the programmer's
confusion.

I know, the name Suppress is somewhat inherently confusing, and undoubtedly
leads many programmers into the same confusion as Charlie has. Hard to know
what a better name might have been ... something like

Check_Not_Required (xxx)

??

Robert Dewar
Ada Core Technologies

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]


In article <dewar.878103469@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>If you say
>
>pragma Suppress (Elaboration_Check);
>
>You are telling the compiler: I have analyzed my program carefully and I
>am sure that there are no instances of access before elaboration. I am sure
>enough that you may consider any instance of such access to be erroneous,
>and do whatever you like. I hope you will be able to use this information
>I am supplying to improve the quality of the generated code.
>
     I like this characterization, but I haven't yet found anything in 
the RM to support it.  I wish something like that appeared somewhere, 
say in a note in 11.5.  Lacking that, it looks more like a programming 
guideline on the "proper" use of Suppress than something that derives 
from the actual definition.

>It sounds like Charlie thinks that the statement means something like
>
>I really don't want you to check for access before elaboration. I want
>you to skip that check, and then carry on and do the "right thing". The
>trouble is that there is not the slightest hint in the RM of what the
>"right thing" might be here, since the RM gives not the slightest clue
>of the semantics of such a situation.

     Not so.  What I actually mean is, "I have decided that I want the 
check suppressed.  Suppressing the check is a language feature and I 
don't have to justify to the compiler why I want it done.  Just suppress 
it and carry on."  That interpretation is weakened, as I have acknowl-
edged before, by the fact that the compiler is not required to honor the 
request.  I have always assumed (without any text in the RM to back me 
up) that the right to ignore the pragma was there to cover the cases 
when suppressing the check was too expensive, by some measure.

     In Ada 83, by suppressing a couple of checks you could often (or 
sometimes) obtain 32-bit or 16-bit modular arithmetic.  Yes, an errone-
ous program.  I would never advocate such a thing and would do it myself 
only under the most extreme duress--such as in very tight time-critical 
code.  However, once the programmer has made the decision to do it this 
way, I don't think it's the compiler's job to tell him he shouldn�t 
have.  His colleagues' maybe, during code walk-throughs, but not the 
compiler's.
>
>Charlie, you really need to adjust your whole view of pragma Suppress.
>It is completely wrong!

     I'm still not convinced it's completely wrong, but I like your 
above characterization so much that I'll probably adopt it, particularly 
for teaching.  But then, that's not very different from the way I teach 
about Suppress already, just more nicely stated.  I never teach people 
how to best exploit erroneous execution.  Many of them are amazingly
adept at discovering this themselves!

 				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Larry Kilgallen]

In article <345774b3.1434102@SantaClara01.news.InterNex.Net>, tmoran@bix.com (Tom Moran) writes:

>   Unless the compiler is buggy, the fact it won't allow something the
> programmer wrote is proof the programmer either did not understand the
> language or made a mistake writing it.  So the compiler has
> demonstrated that it is, in fact, smarter than the programmer. ;)

The compiler is not smarter, it is just better at adapting to new
behavior when it is corrected for the next version.

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

In article <345774b3.1434102@santaclara01.news.internex.net>,
Tom Moran <tmoran@bix.com> wrote:
>>> never been happy as a programmer when a compiler says, "I'm smarter 
>>> than you are and I'm not going to allow you to do what you want."  
>
>>This is the argument many C programmers use against Ada.  Those that
>>really understand C AND never make mistakes write working programs.
>  Unless the compiler is buggy, the fact it won't allow something the
>programmer wrote is proof the programmer either did not understand the
>language or made a mistake writing it.  So the compiler has
>demonstrated that it is, in fact, smarter than the programmer. ;)

     No, rather than saying that the compiler is buggy you have to an-
swer the question, "Is it a bug or is it a feature?"  There have been 
compilers for other languages that tried to outguess the programmer in 
the use of some features, either prohibiting suspicious but legal uses 
or at least warning about them.  Fortunately, this kind of implementa-
tion is close to impossible for Ada compilers because the language is so 
well defined.  For other languages the implementers could justify disal-
lowing something by saying it's not in their version of the language.  
(Hence, no bug.)

 				Charlie

--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Elaboration_check For Instantiations

[Charles H. Sampson]

In article <34573CCF.4DE4@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>> .....  However, I have
>> never been happy as a programmer when a compiler says, "I'm smarter 
>> than you are and I'm not going to allow you to do what you want."  
>
>This is the argument many C programmers use against Ada.  ...

    Yes, it's the same argument, but the effect is quite different.  
Once I've accepted the limitations imposed by a language, I don't want 
the compiler imposing additional ones.

    It seems to me that this thread has progressed to the point where 
it is no longer particularly meaningful in comp.lang.ada.  Ada compilers 
are not going to do any second guessing because the language definition 
won't allow them.  Certainly the Ada 95 compilers I've been exposed to, 
GNAT among them, were correct in their handling of the particular issue 
I mistakenly complained about in starting the thread.

 				Charlie

--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.