package body functionality

package body functionality

[Staffan Dittmer]

the question might be a bit obscure but 
considering the two package bodies below

package body A is
 variable: some_type:=call_some_function_outside_A;
end A;

package body B is
 variable: some_type;
begin
 variable:=call_some_function_outside_B;
end B;

I know that in B the variable will be assigned
every time a program using the package is run,
but is this also true for A, or will the variable in 
this case only be assigned at compile time ?

saturdays usually makes me confused...

/ Staffan Dittmer

Re: package body functionality

[Larry Kilgallen]

In article <9eoeiv$h8$1@eol.dd.chalmers.se>, f97stdi@dd.chalmers.se (Staffan Dittmer) writes:
> the question might be a bit obscure but 
> considering the two package bodies below
> 
> package body A is
>  variable: some_type:=call_some_function_outside_A;
> end A;
> 
> package body B is
>  variable: some_type;
> begin
>  variable:=call_some_function_outside_B;
> end B;
> 
> I know that in B the variable will be assigned
> every time a program using the package is run,
> but is this also true for A, or will the variable in 
> this case only be assigned at compile time ?

call_some_function_outside_A has a body unknown to A,
and the results of that call could be time-variant,
such as computed differently on weekends.  A has no
way of knowing this, so the results cannot be computed
"at compile time".

Re: package body functionality

[Jeffrey Carter]

Staffan Dittmer wrote:
> 
> package body A is
>  variable: some_type:=call_some_function_outside_A;
> end A;
> 
> package body B is
>  variable: some_type;
> begin
>  variable:=call_some_function_outside_B;
> end B;
> 
> I know that in B the variable will be assigned
> every time a program using the package is run,
> but is this also true for A, or will the variable in
> this case only be assigned at compile time ?

Non-static initialization expressions, such as function calls, are
evaluated during elaboration, which happens at run time. Both variables
will be initialized during elaboration at run time.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: package body functionality

[DuckE]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3B0FE64F.7D574D2E@acm.org...
> Staffan Dittmer wrote:
> >
> > package body A is
> >  variable: some_type:=call_some_function_outside_A;
> > end A;
> >
> > package body B is
> >  variable: some_type;
> > begin
> >  variable:=call_some_function_outside_B;
> > end B;
> >
> > I know that in B the variable will be assigned
> > every time a program using the package is run,
> > but is this also true for A, or will the variable in
> > this case only be assigned at compile time ?
>
> Non-static initialization expressions, such as function calls, are
> evaluated during elaboration, which happens at run time. Both variables
> will be initialized during elaboration at run time.

Unless the compiler has a form of global optimization that determines
the result of performing the operation at compile time is the same as
evaluating
both at elaboration time (a nice optimization).

SteveD

>
> --
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail

Re: package body functionality

[Aron Felix Gurski]

Staffan Dittmer wrote:
> 
> the question might be a bit obscure but
> considering the two package bodies below
> 
> package body A is
>  variable: some_type:=call_some_function_outside_A;
> end A;
> 
> package body B is
>  variable: some_type;
> begin
>  variable:=call_some_function_outside_B;
> end B;
> 
> I know that in B the variable will be assigned
> every time a program using the package is run,
> but is this also true for A, or will the variable in
> this case only be assigned at compile time ?
> 
> saturdays usually makes me confused...

The function of the compiler is to convert (in this case) package body A into
object code, not to execute the code in some other package (which, conceivably,
might not even be compiled yet).

-- 
        -- Aron

NB: To reply by e-mail, remove "spam-block." from my address.
- - - - - - - - - - -
"Nobody suffers the pain of birth or the anguish of loving a child in order for
presidents to make wars, for governments to feed on the substance of their
people, for insurance companies to cheat the young and rob the old."

        -- Lewis Lapham

Re: package body functionality

[Ken Garlington]

If you're asking "are these different," the only difference I can think of
is that a given compiler *might* optimize them differently, up to and
including eliminating the variable altogether!

"Staffan Dittmer" <f97stdi@dd.chalmers.se> wrote in message
news:9eoeiv$h8$1@eol.dd.chalmers.se...
: the question might be a bit obscure but
: considering the two package bodies below
:
: package body A is
:  variable: some_type:=call_some_function_outside_A;
: end A;
:
: package body B is
:  variable: some_type;
: begin
:  variable:=call_some_function_outside_B;
: end B;
:
: I know that in B the variable will be assigned
: every time a program using the package is run,
: but is this also true for A, or will the variable in
: this case only be assigned at compile time ?
:
: saturdays usually makes me confused...
:
: / Staffan Dittmer

Re: package body functionality

[Philip Anderson]

Ken Garlington wrote:
> 
> If you're asking "are these different," the only difference I can think of
> is that a given compiler *might* optimize them differently, up to and
> including eliminating the variable altogether!


There could be other differences because of the order of actions,

e.g.

package body A is
  variable: some_type:=call_some_function_outside_A;
  V2 : some_type := variable;
end A;
&
package body B is
  variable: some_type;
  V2 : some_type := variable;  -- default/uninitialised value of
variable
begin
  variable:=call_some_function_outside_B;
end B;


The second option also allows you to include an exception handler to
catch any exception raised by function outside B

-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: package body functionality

[Ted Dennison]

In article <9eoeiv$h8$1@eol.dd.chalmers.se>, Staffan Dittmer says...
>
>package body A is
> variable: some_type:=call_some_function_outside_A;
>end A;
..
>but is this also true for A, or will the variable in 
>this case only be assigned at compile time ?

Oddly enough, we had a very long discussion here a few months back about what it
would take for a compiler to be able to call a user-specified function at
compile time. If you're interested in that topic, you may want to try to look it
up at http://groups.google.com . I doubt we will recover all the better points
here again.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: package body functionality

[Stephen Leake]

f97stdi@dd.chalmers.se (Staffan Dittmer) writes:

> the question might be a bit obscure but 
> considering the two package bodies below
> 
> package body A is
>  variable: some_type:=call_some_function_outside_A;
> end A;
> 
> package body B is
>  variable: some_type;
> begin
>  variable:=call_some_function_outside_B;
> end B;
> 
> I know that in B the variable will be assigned
> every time a program using the package is run,

This is seriously wrong! B.variable is _not_ set many times. It
would be interesting to understand how you got that impression.

B.variable will be set _once_, at "elaboration" time. Elaboration
happens just before the main Ada program is run. All packages in the
program are elaborated, in an order determined by the compiler.

Note that if a function is called before its package is elaborated,
the exception Program_Error is raised; this is before your main
program gets to start.

To be safe, package A should have a 'pragma Elaborate' for the package
containing 'some_function_outside_A', and similarly for B.

> 
> but is this also true for A, or will the variable in this case only
> be assigned at compile time ?

As for B, A.variable is set at elaboration time.

-- 
-- Stephe

Re: package body functionality

[Ted Dennison]

In article <u66ekm0m5.fsf@gsfc.nasa.gov>, Stephen Leake says...
>
>f97stdi@dd.chalmers.se (Staffan Dittmer) writes:
>
>> package body B is
>>  variable: some_type;
>> begin
>>  variable:=call_some_function_outside_B;
>> end B;
>> 
>> I know that in B the variable will be assigned
>> every time a program using the package is run,
>
>This is seriously wrong! B.variable is _not_ set many times. It
>would be interesting to understand how you got that impression.

He said every time the *program* is run, which is quite correct. I'll admit the
possiblity that he meant something else (although I'm having trouble mentally
concoting a reasonable alternative), but that's not what he wrote.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: package body functionality

[Marin David Condic]

Possible exception: If the package is a shared library or in a distributed
environment. I'm not sure what the language rules are, but I'd suspect that
a DLL would not re-elaborate every time another program started up and
called for its services. Maybe under some conditions (separate data spaces)
but not if it was some sort of shared resource. Or would it?

Interesting question - maybe I'll have to look up "Elaboration" tomorrow if
nobody posts an answer before I get back to work. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:MJTQ6.4332$rn5.225402@www.newsranger.com...
> He said every time the *program* is run, which is quite correct. I'll
admit the
> possiblity that he meant something else (although I'm having trouble
mentally
> concoting a reasonable alternative), but that's not what he wrote.
>

Re: package body functionality

[Ted Dennison]

In article <9f14b8$r4v$1@nh.pace.co.uk>, Marin David Condic says...
>
>Possible exception: If the package is a shared library or in a distributed
>environment. I'm not sure what the language rules are, but I'd suspect that
>a DLL would not re-elaborate every time another program started up and
>called for its services. Maybe under some conditions (separate data spaces)

My understanding is that DLL's keep a count of how many programs are using them,
and get automagicly unloaded when the count goes down to 0. You'd want it to
elaborate once for the first call that loads it in, then not again until the
next call after it unloads.

However, DLL's have their own special entry point as well. I suspect what Ada
DLL's have to do is implement that call (exported with the right linkage of
course) to call the standard Ada elaboration entry point. Perhaps someone who
has done this can comment.

Anyway, I wouldn't really call this an "exception". Its just that in this case
the "program" in question is the DLL itself, not its clients. It works if you
hold your head the right way. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: package body functionality

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> In article <u66ekm0m5.fsf@gsfc.nasa.gov>, Stephen Leake says...
> >
> >f97stdi@dd.chalmers.se (Staffan Dittmer) writes:
> >
> >> package body B is
> >>  variable: some_type;
> >> begin
> >>  variable:=call_some_function_outside_B;
> >> end B;
> >> 
> >> I know that in B the variable will be assigned
> >> every time a program using the package is run,
> >
> >This is seriously wrong! B.variable is _not_ set many times. It
> >would be interesting to understand how you got that impression.
> 
> He said every time the *program* is run, which is quite correct. I'll admit the
> possiblity that he meant something else (although I'm having trouble mentally
> concoting a reasonable alternative), but that's not what he wrote.

Hmm, I guess I read "subprogram from the package", rather than
"program using the package". Sorry!

-- 
-- Stephe

Re: package body functionality

[Marin David Condic]

Point taken. It is kind of a matter of how you look at it. I just brought it
up because its an example of the importance of looking over the
documentation for unusual cases. In 99.44% of the cases, you've got a
simple, self contained, program that elaborates when you run it. But there
may be cases where the elaboration has more subtle implications.

I'll try to hold my head right and look at it with the corner of my eyes
next time. It's the only way to see something that has an SEP field
surrounding it. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:hR6R6.5195$rn5.257552@www.newsranger.com...
> Anyway, I wouldn't really call this an "exception". Its just that in this
case
> the "program" in question is the DLL itself, not its clients. It works if
you
> hold your head the right way. :-)
>

Re: package body functionality

[Robert A Duff]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> To be safe, package A should have a 'pragma Elaborate' for the package
> containing 'some_function_outside_A', and similarly for B.

A pragma Elaborate_All is almost always better than pragma Elaborate,
because it is transitive.

- Bob

Re: package body functionality

[Wes Groleau]

> >Possible exception: If the package is a shared library or in a distributed
> >environment. I'm not sure what the language rules are, but I'd suspect that
> >a DLL would not re-elaborate every time another program started up and
> >called for its services. Maybe under some conditions (separate data spaces)
> 
> My understanding is that DLL's keep a count of how many programs are using them,
> and get automagicly unloaded when the count goes down to 0. You'd want it to
> elaborate once for the first call that loads it in, then not again until the
> next call after it unloads.

There are many things a package in a DLL or shared lib might do during
elaboration that would require re-elaboration for each client.  Just for a
few:

  Create a log file.
  Initialize a random number generator.
  Read the process ID.
  Note the time we started running.

Doesn't seem practical for a compiler/linker to foresee ALL the possibilities
and optionally skip elaboration.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau