From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6a9844368dd0a842
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: seperate keyword and seperate compilation with Gnat?
Date: 1996/07/09
Message-ID: <DuA43q.CtC@world.std.com>#1/1
X-Deja-AN: 167391675
references: <dewar.836427220@schonberg> <4rrcal$hhh@newsbf02.news.aol.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-07-09T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4rrcal$hhh@newsbf02.news.aol.com>,
John Herro <johnherro@aol.com> wrote:
>this case, Janus/Ada has a pragma for the user to tell the compiler that
>the program will *not* use 'Image or 'Value for a particular enumeration
>type.

Ada 95 has a similar feature -- see pragma Discard_Names.  It also works
for eliminating tag names for tagged types.

>...  How about a pragma or compiler switch
>to tell Gnat that the whole program won't use tasking?

Ada 95 has this feature too -- see pragma Restrictions.  There are many
restrictions, including No_Tasks (or something like that).  Also,
implementations can add their own restrictions.

>     My philosophy is this: Ada is a large language with many features. 
>When the user specifies no pragmas or special switches, don't worry too
>much about efficiency, just compile the code quickly (without unnecessary
>recompilation) to support rapid development.  When efficiency is a
>concern, transfer *some* of the responsibility to the programmer, who can
>tell the compiler if the program won't contain tasking or use other Ada
>features that are costly in the generated code.

In general, I agree with this principle.  One can look at many
optimizations as consisting of (1) determine whether the optimization is
correct, (2) determine whether it's worthwhile, and (3) doing it.  Parts
(1) and (3) can be very error-prone, so should usually be done by the
compiler (when possible).  Part (2) is less error-prone, so it's OK to
let the user do that part, if it's hard for the compiler but not so hard
for the user.  Pragma Inline is a good example -- the user says when it
should be done, but the compiler takes care of doing it.  If the user
had to do the inlining by hand, it would be a disaster.

I was against the inclusion of pragma Discard_Names, though -- I thought
compilers ought to be able to do that optimization without the extra
hint, and I didn't think this particular feature was worth the trouble.
On the other hand, I was in favor of pragma Restrictions.

Note that pragma Restrictions is not just for optimization.  For
example, it can be helpful in proving various properties of programs --
hence the restrictions in the Safety annex.

- Bob