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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: progers@acm.org
Subject: Re: seperate keyword and seperate compilation with Gnat?
Date: 1996/07/09
Message-ID: <4rsk2t$o4q@uuneo.neosoft.com>#1/1
X-Deja-AN: 167311761
references: <dewar.836427220@schonberg> <4rrcal$hhh@newsbf02.news.aol.com>
organization: NeoSoft, Inc.  
reply-to: progers@acm.org
newsgroups: comp.lang.ada
Date: 1996-07-09T00:00:00+00:00
List-Id: <comp.lang.ada>


In <4rrcal$hhh@newsbf02.news.aol.com>, johnherro@aol.com (John Herro) writes:

[snip]

>     Here's how Janus/Ada solved two other problems in this same general
>category.  First, long identifier names normally don't affect the
>generated code at all.  But that's not true of enumeration types, for
>which the compiler must store the identifier names in the generated code
>because we *might* use 'Image and 'Value.  For example:
>
>type CLA_Message_Type is (Ask_For_Help, Give_Help, Discuss_Ada,
>Please_Do_My_Homework, Flame, Flame_The_Flamer);
>procedure Filter_CLA_Messages is separate;
>
>When generating code for the parent, the compiler has to include the
>enumeration identifier names in the object code because the separate
>procedure might use CLA_Message_Type'Image or CLA_Message_Type'Value.  In
>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.

That pragma is standardized in Ada95: it is called Discard_Names.


>     Permit me to offer a suggestion, even though I have to admit that I
>don't have the Gnat compiler.  (I'm paying America Online 5 cents a minute
>for access, and have no idea what it would cost me to download ez2load - I
>know, I should get a *real* ISP!)  How about a pragma or compiler switch
>to tell Gnat that the whole program won't use tasking?  Then it could
>generate efficient code for the parent before the subunit is written, and
>wouldn't have to recompile the parent when the subunit changes.

That pragma is defined in the Core: pragma Restrictions. The specific
restriction you mention is defined in the Real-Time Systems Annex.

>     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.

And there's a good thumbnail rationale for pragma Restrictions.  You're obviously
thinking like the design team! :)  Well, OK, pragma Restrictions is really
for tuning the run-time system, but that's close...


pat
---------------
Patrick Rogers
progers@acm.org