local variables

local variables

[B.Voh]

Does new ADA support a retention of local variables similar to Fortran's
"save" or C's "static" declaration?
In my last encounter with ADA, some years back, I found that to be a
rather crippling ommission and often working against the very principles
(encapsulation) it was supposed to champion.

Re: local variables

[Niklas Holsti]

B.Voh wrote:
> 
> Does new ADA support a retention of local variables similar to Fortran's
> "save" or C's "static" declaration?
> In my last encounter with ADA, some years back, I found that to be a
> rather crippling ommission and often working against the very principles
> (encapsulation) it was supposed to champion.

The local variables of an Ada 95 subprogram are still created for each
call of the subprogram, and deleted when the call returns. However, just
as in Ada 83, the way to save local (private, encapsulated) variables
from call to call is to put the subprogram in a package, and declare
the variables in the body of the package but outside the subprogram:

   package Example is
      procedure Count_Something;
   end Example;

   package body Example is

      Saved_Count: integer := 0;

      procedure Count_Something is
      begin
         Saved_Count := Saved_Count + 1;
      end Count_Something;

   end Example;

Here, the Saved_Count variable lives and retains its last-assigned value
as long as the package Example lives; if Example is a library-level
package, this means the whole duration of the program run.

Is this what you were looking for? If not, what is the "crippling"
problem?

- Niklas

Re: local variables

[Tucker Taft]

B.Voh (voh@young.epc.lmms.lmco.com) wrote:

: Does new ADA support a retention of local variables similar to Fortran's
: "save" or C's "static" declaration?

No.  However, the "new" Ada (aka Ada 95) does allow variable declarations
to be interleaved with subprogram bodies in a package body, so it
is easier to localize package-level variables with a subprogram that 
needs one.  In my experience, however, it is quite common that
there are several subprograms in a given abstraction that all need
access to the "static" variables retaining state across calls.
So moving such variables to the package level usually makes
good sense anyway.

: In my last encounter with ADA, some years back, I found that to be a
: rather crippling ommission and often working against the very principles
: (encapsulation) it was supposed to champion.

I would be curious in what way this is crippling.  All declarations
in a package body are "encapsulated," including package-level
variables used to retain state between calls of a given subprogram.

For what it is worth, Java also omits the notion of "local static" variables.

Here is an example which takes advantage of the Ada 95 relaxed ordering
for variable declarations and subprogram bodies, to allow package-level
variables to be grouped with associated subprograms:

  package Abstraction is
    procedure Op1(...);
    procedure Bump_Counter(Next : out Integer);
  end Abstraction

  package body Abstraction is
    procedure Op1(...) is
    begin
      -- do something interesting
    end Op1;

    Counter : Integer := 0;  -- "static" variable used by Bump_Counter
    procedure Bump_Counter(Next : out Integer) is
    begin
      Counter := Counter + 1;
      Next := Counter;
    end Bump_Counter;
  end Abstraction;

In any case, "Counter" is not visible outside the Abstraction package,
and so it is still "encapsulated."

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: local variables

[Robert Dewar]

Tucker said

<<  package body Abstraction is
    procedure Op1(...) is
    begin
      -- do something interesting
    end Op1;

    Counter : Integer := 0;  -- "static" variable used by Bump_Counter
    procedure Bump_Counter(Next : out Integer) is
    begin
      Counter := Counter + 1;
      Next := Counter;
    end Bump_Counter;
  end Abstraction;
>>

You really don't need the relaxed rules of Ada 95 here, and indeed they
are not really sufficient in this case (what if there were another
routine after Bump_Counter, it would be able to see Counter, which is
wrong).

Instead you can just introduce a nested package:

  package body Abstraction is
    procedure Op1(...) is
    begin
      -- do something interesting
    end Op1;

    package body Encapsulate is

      Counter : Integer := 0;  -- "static" variable used by Bump_Counter
      procedure Bump_Counter(Next : out Integer) is
      begin
        Counter := Counter + 1;
        Next := Counter;
      end Bump_Counter;
    end Encapsulate;
  end Abstraction;


The corresponding package spec might have

  package Abstraction is
    procedure Op1(...);

    package Encapsulate is
      procedure Bump_Counter (Next : out Integer);
    end Encapsulate;

    procedure Bump_Counter (Next : out Integer)
      renames Encapsulate.Bump_Counter;

  end Abstraction;

and this can of course be done in Ada 83, so the reference to this as a
crippling problem seems overblown!

Re: local variables

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Instead you can just introduce a nested package:
>
>  package body Abstraction is
>    procedure Op1(...) is
>    begin
>      -- do something interesting
>    end Op1;
>
>    package body Encapsulate is
>
>      Counter : Integer := 0;  -- "static" variable used by Bump_Counter
>      procedure Bump_Counter(Next : out Integer) is
>      begin
>        Counter := Counter + 1;
>        Next := Counter;
>      end Bump_Counter;
>    end Encapsulate;
>  end Abstraction;
>
>
>The corresponding package spec might have
>
>  package Abstraction is
>    procedure Op1(...);
>
>    package Encapsulate is
>      procedure Bump_Counter (Next : out Integer);
>    end Encapsulate;
>
>    procedure Bump_Counter (Next : out Integer)
>      renames Encapsulate.Bump_Counter;
>
>  end Abstraction;

There's no need to put the package `Encapsulate' in the package
spec rather than the package body, is there?

I'd write this as

  package Abstraction is
    procedure Op1(...);

    procedure Bump_Counter (Next : out Integer);

  end Abstraction;

  package body Abstraction is
    procedure Bump_Counter (Next : out Integer)
      renames Encapsulate.Bump_Counter;

    package Encapsulate is
      procedure Bump_Counter (Next : out Integer);
    end Encapsulate;

    package body Encapsulate is
    	-- as above
    end Encapsulate;

    procedure Bump_Counter (Next : out Integer);
      renames Encapsulate.Bump_Counter;

  end Abstraction;

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: local variables

[Robert Dewar]

B. Voh said

<<Does new ADA support a retention of local variables similar to Fortran's
"save" or C's "static" declaration?
In my last encounter with ADA, some years back, I found that to be a
rather crippling ommission and often working against the very principles
(encapsulation) it was supposed to champion.
>>

I am afraid it was your lack of success in learning Ada that was the
source of the crippling rather than the language itself!!! 


All versions of Ada have supported this in a straightforward manner. Merely
encapsulate the subprogram involved in a package, and then put the variable
in question in the package body. Problem solved!

Re: local variables

[Simon Wright]

"B.Voh" <voh@young.epc.lmms.lmco.com> writes:

> Does new ADA support a retention of local variables similar to Fortran's
> "save" or C's "static" declaration?
> In my last encounter with ADA, some years back, I found that to be a
> rather crippling ommission and often working against the very principles
> (encapsulation) it was supposed to champion.

Current Ada is exactly like Ada83 in this respect; you get the effect
you want by using *package* variables.

-------- foo.h ---------

int f(void);

-------- foo.c ---------

static int fi = 0;

int f(void)
{
  fi++;
  return fi;
}

-------- foo.ads ---------

package foo is
  function f return integer;
end foo;

-------- foo.adb ---------

package body foo is
  fi : integer := 0;
  function f return integer is
  begin
    fi := fi + 1;
    return fi;
  end f;
end foo;

-------------------------

OK, within foo.c the scope of fi is a bit wider than it would have
been if it'd been declared inside f(), but I don't see this as being
that big a deal.

Remember that if you use tasking (or, in C, threads) you will have to
protect accesses to fi; putting it inside f() won't help.