Pre-Elaboration clarification.

Pre-Elaboration clarification.

[Clueless]

In my Ada spec file, I have the declaration...

	type Int_Data is array(1..Argument_Count) of Integer;

and I'm using the Ada.Command_Line package.

Now, everything compiles fine, and it produces a perfectly usable object
file.

Now, as you may have guessed, the point of this declaration is to create
an array of the type Integer that has as many elements as there are
arguments on the command line.(To be used for assigning numbers to the
array.)

Now, the actual data variable isn't actually elaborated until I get to
the function defintion...

	function Multiply(Some_numbers : in Int_Data) return Integer;

in the same spec file.

Now all appears to be well. No problems.

My question is this...

Is it necessary to specifically instruct the compiler to pre-elaborate
the "type Int_Data" declaration via a pragma, before letting it elaborate
anything else?

Although it really doesnt present any problems here, I can forsee where
such an issue might be a problem later on.
Note: I havent had much of a chance to read up on Pragmas yet, although I
am somewhat familiar with them. I'm also working on familiarizing myself
with order of elaboration issues.

Any pointers(no pun intended) would be helpful.

Thanks.

Clueless
chris@dont.spam.me

Re: Pre-Elaboration clarification.

[Jeffrey Carter]

Clueless wrote:
> 
> In my Ada spec file, I have the declaration...
> 
>         type Int_Data is array(1..Argument_Count) of Integer;
> 
> and I'm using the Ada.Command_Line package.
> 
> Now, everything compiles fine, and it produces a perfectly usable object
> file.
> 
> Now, as you may have guessed, the point of this declaration is to create
> an array of the type Integer that has as many elements as there are
> arguments on the command line.(To be used for assigning numbers to the
> array.)
> 
> Now, the actual data variable isn't actually elaborated until I get to
> the function defintion...
> 
>         function Multiply(Some_numbers : in Int_Data) return Integer;
> 
> in the same spec file.
> 
> Now all appears to be well. No problems.
> 
> My question is this...
> 
> Is it necessary to specifically instruct the compiler to pre-elaborate
> the "type Int_Data" declaration via a pragma, before letting it elaborate
> anything else?

The elaboration pragmata control elaboration issues for entire library
units, not to specific declarations within a unit. Within a unit,
declarations are elaborated in textual order. Therefore, your type
declaration is elaborated before your function declaration, and no
pragma exists 

Perhaps you are concerned that Ada.Command_Line be elaborated before
your package, so the call to Argument_Count is legal. However,
Ada.Command_Line is marked as pre-elaborated, which means it needs no
run-time elaboration, so that is not an issue in this specific case. In
addition, some compilers do an excellent job of determining an
elaboration order that will execute successfully.

In general, if your unit makes calls to operations in another unit
during elaboration, the other unit should be mentioned in a pragma
Elaborate_All.

You seem to be confused about other issues as well. For example, there
is no "data variable" in the declaration of a function.

-- 
Jeffrey Carter

Re: Pre-Elaboration clarification.

[Matthew Heaney]

"Clueless" <chris@dont.spam.me> wrote in message
news:YAyF7.232247$K6.111187950@news2...
> In my Ada spec file, I have the declaration...
>
> type Int_Data is array(1..Argument_Count) of Integer;

Don't do it this way.  Just declare an unconstrained array type:

type Integer_Array is array (Positive range <>) of Integer;

The spec that declares the Integer_Array type shouldn't depend on package
Command_Line.  This is unnecessary coupling between specs.

I'll be talking about this sort of thing at next year's Ada Europe
conference in Austria.  (Assuming the committee accepts my tutorial
proposal.)


> Now, as you may have guessed, the point of this declaration is to create
> an array of the type Integer that has as many elements as there are
> arguments on the command line.(To be used for assigning numbers to the
> array.)
>
> function Multiply(Some_numbers : in Int_Data) return Integer;
> in the same spec file.

function Multiply (N : in Integer_Array) return Integer;

Re: Pre-Elaboration clarification.

[Clueless]

In article <tuomu32t6sb9@corp.supernews.com>, "Matthew Heaney"
<mheaney@on2.com> wrote:

> "Clueless" <chris@dont.spam.me> wrote in message
> news:YAyF7.232247$K6.111187950@news2...
>> In my Ada spec file, I have the declaration...
>>
>> type Int_Data is array(1..Argument_Count) of Integer;
> 
> Don't do it this way.  Just declare an unconstrained array type:
> 
> type Integer_Array is array (Positive range <>) of Integer;
> 
> The spec that declares the Integer_Array type shouldn't depend on
> package Command_Line.  This is unnecessary coupling between specs.
> 
> I'll be talking about this sort of thing at next year's Ada Europe
> conference in Austria.  (Assuming the committee accepts my tutorial
> proposal.)
> 
> 

Are there any basic rules of thumb that an "Intermediate" level
programmer(as I was declared by my CS teacher) should follow in Ada as
regards data types and spec files?
I've made a BIG point of avoiding unecessary coupling as you pointed out.
As I'm not writing very "large" programs in Ada yet, I havent really run
into any problems with Data types and elaboration. Is there anything that
I should be practicing regularly, which might be peculiar to Ada95, that
would help me avoid problems once I get into developing "larger" pieces
of software?

McDoobie
chris@dont.spam.me

Re: Pre-Elaboration clarification.

[Matthew Heaney]

"Clueless" <chris@dont.spam.me> wrote in message
news:v59L7.42261$RI2.21722340@news2...
> Are there any basic rules of thumb that an "Intermediate" level
> programmer(as I was declared by my CS teacher) should follow in Ada as
> regards data types and spec files?

In general, you should always defer package dependencies to the body, or to
a child.

> I've made a BIG point of avoiding unecessary coupling as you pointed out.
> As I'm not writing very "large" programs in Ada yet, I havent really run
> into any problems with Data types and elaboration.

My comment wasn't about elaboration issues specifically.  But it seemed as
if you had a dependency on package Command_Line in a spec, when it wasn't
strictly necessary.

> Is there anything that
> I should be practicing regularly, which might be peculiar to Ada95, that
> would help me avoid problems once I get into developing "larger" pieces
> of software?

Managing dependencies among compilation units isn't specific to Ada95 -- the
techniques are necessary in C++ as well.  You can read John Lakos' Large
Scale C++ Software Design for ideas that apply to either C++ or Ada95.
There's also a section in Norm Cohen's book, about minimizing dependencies
among Ada packages.

WAS Re: Pre-Elaboration clarification.

[Mark Lundquist]

Sorry, this isn't about elaboration or anything, but I couldn't think of a
good, non-inflammatory, i.e. non-C++-bashing :-) subject line for this...

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u0a91lan036634@corp.supernews.com...
> You can read John Lakos' Large
> Scale C++ Software Design for ideas that apply to either C++ or Ada95.

I recommend this book to anyone considering Ada, to read as part of a
comparative language study.  For one, it's a good book.  This is really how
you have to live in C++.  But the reasons why are oh-so-illustrative.

One of the dings you hear against Ada is that it's full of all these
confining *rules*, which supposedly stifle one's creativity, and result in
unacceptable syntactic overhead (i.e. verbiage) in the 0.1% of cases when
one needs to do something unsafe.

But it turns out that survival with C++ depends on a system of conventions,
which are outside the language and must be developed and written about by
gurus in books, and which have to be enforced, not by a compiler but by a
human being (this being both error prone and a human resource drain).  I.e.,
the conventions become draconian rules!

Since we have to have rules, I'd a lot rather have them be language rules
enforced by a compiler than ad hoc provincial rules enforced by a
"conventions czar".

-- mark

Re: Pre-Elaboration clarification.

[Mark Lundquist]

"Clueless" <chris@dont.spam.me> wrote in message
news:v59L7.42261$RI2.21722340@news2...
>
> Are there any basic rules of thumb that an "Intermediate" level
> programmer(as I was declared by my CS teacher) should follow in Ada as
> regards data types and spec files?

Yeah, here's one...

This is a "Beginner" mistake that as an "Intermediate" programmer you will
want to avoid :-).  I used to see it a lot from people who were no longer
beginners, but who somehow never "got it".

The Ada programmer learns that a package can have both a spec and a body,
and that only declarations can go in the spec, and only bodies can go in the
body, and bodies are the only things that can have statements.

As a result of this, sometimes a beginner gets the idea that "the spec is
the place for all my type definitions".  So they define types in the public
part of a spec that should be in defined in the body.  This goes
hand-in-hand with another beginner mistake, which is the failure to
understand and use private types.

Of course failure to encapsulate leads to fragile and buggy code, but it
also obscures intent.  Where things are declared (public, private, or body)
communicates important information to any reader trying to understand the
code.  A reader should always be able to apply the principle that if
such-and-such is visible at a given place, there is a "good reason" (related
to using the abstraction) for that visibility.

So the rule of thumb for type declarations in a package is:

- If only the body needs the type, then put it in the body.
- If code in other (non-child) packages depends on it, but only the compiler
(not the code) needs to know the representation, then put the full
definition in the private part.
- If the only things depending on the type are other types in the private
part, there is no need for a private_type_declaration (that is, "is private"
in the public part).  Define the type in the private part but don't mention
it in the public part.
- If the code in other (non-child) packages needs to see it, put it in the
public part of the spec

I wrote the cases in order from most- to least- encapsulated, because it's
good to get in the habit of thinking that way.

Have fun,
-- mark

Re: Pre-Elaboration clarification.

[Matthew Heaney]

"Mark Lundquist" <up.yerz@nospam.com> wrote in message
news:fiaN7.89348$XJ4.48897553@news1.sttln1.wa.home.com...
> - If only the body needs the type, then put it in the body.

Or in the spec of a private child.

> - If code in other (non-child) packages depends on it, but only the
compiler
> (not the code) needs to know the representation, then put the full
> definition in the private part.
> - If the only things depending on the type are other types in the private
> part, there is no need for a private_type_declaration (that is, "is
private"
> in the public part).  Define the type in the private part but don't
mention
> it in the public part.
> - If the code in other (non-child) packages needs to see it, put it in the
> public part of the spec
>
> I wrote the cases in order from most- to least- encapsulated, because it's
> good to get in the habit of thinking that way.

Other techniques include:

o if only a pointer to the type is required, then you can defer the rep to
the body:

package P is
   type Handle is private;
private
   type Rep;
  type Handle is access Rep;
end P;

packge body P is
   type Rep is null record;  --or whatever
end P;


o sometimes it makes sense to declare an abstract interface, and then
provide a constructor for it:

package P is
   pragma Elaborate_Body;
   type T is abstract tagged null record;
   procedure Op (O : access T) is abstract;
   type T_Class_Access is access all T'Class;
end P;

--the "constructor"
--you could declare this in P, but then you won't be
--able to use a categorization pragma.
function P.New_T return T_Class_Access;

private package P.C is
   type Rep is new T with null record;  --or whatever
   procedure Op (O : access Rep);
end P.C;

with P.C;
function P.New_T return T_Class_Access is
begin
   return new P.C.Rep;
end;

In this way, you're able to hide all kinds of dependencies, because a client
only manipulates type P.T'Class.  This is essentially what Lakos described
as a "protocol class."

We could talk all day about this stuff, which is what I intend to do at next
years Ada-Europe conference in Vienna.

Re: Pre-Elaboration clarification.

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Mark Lundquist" <up.yerz@nospam.com> wrote in message
> news:fiaN7.89348$XJ4.48897553@news1.sttln1.wa.home.com...
> > - If only the body needs the type, then put it in the body.
> 
> Or in the spec of a private child.

Or on a separate body, if the dependency is that far down.

Re: Pre-Elaboration clarification.

[Robert Dewar]

"Clueless" <chris@dont.spam.me> wrote in message news:<YAyF7.232247$K6.111187950@news2>...
> Any pointers(no pun intended) would be helpful.

Have a look at the chapter on elaboration issues in the
GNAT users guide ..