Re: seperate keyword and seperate compilation with Gnat?

[progers@acm.org]

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