why only in-parameters in functions

why only in-parameters in functions

[Rick Santa-Cruz]

Hi,

I know that it is only allowed to use in-parameters with functions. But I 
can't figure out what is the idea behind this. Why did the Ada-Team only 
allow in-parameter when using functions?

Thanks in advance,
Rick 

Re: why only in-parameters in functions

[stephane richard]

"Rick Santa-Cruz" <rick_santa_cruz75@msn.com> wrote in message 
news:cjejo4$62e$00$1@news.t-online.com...
> Hi,
>
> I know that it is only allowed to use in-parameters with functions. But I 
> can't figure out what is the idea behind this. Why did the Ada-Team only 
> allow in-parameter when using functions?
>
> Thanks in advance,
> Rick
>
Maybe I can answer that, with my still very limited knowledge...and wait for 
others to correct me ;-).

I would assume that since a function returns a value Out parameters would 
also allow to change values outside the function.  even if it's available in 
other languages, it's usually recommended to not do so for good practice. 
so to enforce it isn't all that bad a thing. :-).

Re: why only in-parameters in functions

[Alexander E. Kopilovich]

Rick Santa-Cruz wrote:

> I know that it is only allowed to use in-parameters with functions. But I 
> can't figure out what is the idea behind this. Why did the Ada-Team only 
> allow in-parameter when using functions?

There were so many discussions on this matter, at various levels, and so manu
arguments pro and contra were expressed that perhaps there should be FAQ for
this topic alone.

In short, for many years Ada community and ARG (which can be seen as Ada
design team) were (and still are) divided about this matter.

In practice, where you really need in-parameters for a function you may either
use a procedure that returns value (if you use GNAT compiler) or you may use
the construct, presented here in c.l.a by Robert I. Eachus (see his message
in comp.lang.ada from 2003-07-15 with Subject: Re: What evil would happen?)

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

function Random(Gen: in Generator) return ...
   Local: Generator;
   for Local'Address use Gen'Address;
begin
   ...
end Random;

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




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: why only in-parameters in functions

[Randy Brukardt]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message
news:mailman.131.1096477841.390.comp.lang.ada@ada-france.org...
> Rick Santa-Cruz wrote:
>
> > I know that it is only allowed to use in-parameters with functions. But
I
> > can't figure out what is the idea behind this. Why did the Ada-Team only
> > allow in-parameter when using functions?
>
> There were so many discussions on this matter, at various levels, and so
manu
> arguments pro and contra were expressed that perhaps there should be FAQ
for
> this topic alone.
>
> In short, for many years Ada community and ARG (which can be seen as Ada
> design team) were (and still are) divided about this matter.

The most recent go-round is saved in AI-323. And, yes, opinion is divided
enough that it is unlikely to ever change.

> In practice, where you really need in-parameters for a function you may
either
> use a procedure that returns value (if you use GNAT compiler) or you may
use
> the construct, presented here in c.l.a by Robert I. Eachus (see his
message
> in comp.lang.ada from 2003-07-15 with Subject: Re: What evil would
happen?)

The easiest thing to do is to use an access parameter instead. That's
somewhat ugly (because it messes up the calls as 'Access is needed), but it
works.

If you are willing to depend on the definition of the type, a number of
things (including the solution suggested previously) work. Another solution
(used by Ada.Text_IO, for example) is to insure that the type passed is just
a handle to the real object. Controlled types make this solution relatively
easy to write.

                                  Randy.

Re: why only in-parameters in functions

[Florian Weimer]

* Alexander E. Kopilovich:

> In practice, where you really need in-parameters for a function you may either
> use a procedure that returns value (if you use GNAT compiler) or you may use
> the construct, presented here in c.l.a by Robert I. Eachus (see his message
> in comp.lang.ada from 2003-07-15 with Subject: Re: What evil would happen?)

The "Rosen trick" is also relevant in this context (see the archives),
but it only works for limited types.  However, it should be used
whenever possible because it does not involve erroneous execution.

Re: why only in-parameters in functions

[Wojtek Narczynski]

Hello,

I've tried to produce a patch for GNAT for this. Of curse, I realize what
"Standard" means, but I wanted to have this functionality (-gnatX
controlled) in order to deliver new arguments, by exposing all the tricks
caused by the absence of this feature. I believe this is the only way to
put this discussion back on (technical) track.

The Ada part was surprisingly easy, I only had to comment-out two lines.
After that it worked for types passed by reference. But for types passed
by copy, it turned out that modifications to GiGi C code are necessary.
But this code is in flux now (due to gcc tree-ssa change), so I left it
for now.

Regards,
Wojtek

Re: why only in-parameters in functions

[Björn Persson]

Randy Brukardt wrote:

> The most recent go-round is saved in AI-323.

I bet Rick has no idea what AI-323 is.

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00323.TXT?rev=1.2

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: why only in-parameters in functions

[Rick Santa-Cruz]

Hi,

>I bet Rick has no idea what AI-323 is.
>
>http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00323.TXT?rev=1.2
Yes ;). Thanks.

Re: why only in-parameters in functions

[Matthew Heaney]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> In practice, where you really need in-parameters for a function you
> may either use a procedure that returns value (if you use GNAT
> compiler) or you may use the construct, presented here in c.l.a by
> Robert I. Eachus (see his message in comp.lang.ada from 2003-07-15
> with Subject: Re: What evil would happen?)
> 
> ----------------------------------------------------------------------------
> 
> function Random(Gen: in Generator) return ...
>    Local: Generator;
>    for Local'Address use Gen'Address;
> begin
>    ...
> end Random;
> 
> ----------------------------------------------------------------------------


Actually, if the type is limited, then you can use the Rosen Trick,
which is somewhat cleaner:

private

   type Handle (G : access Generator) is 
      limited null record;

   type Generator is limited record
      H : Handle (Generator'Access);
      ... -- rest of state
   end record;

end;

   function Random (G : Generator) return ...
      GG : Generator renames G.H.G.all;
   begin
      ... -- modify GG as desired
   end Radom;

The Rosen Trick was discovered in the fall of 1999.  See CLA archives
around that time for more info.

Re: why only in-parameters in functions

[Dmitry A. Kazakov]

On Wed, 29 Sep 2004 23:12:41 +0200, Florian Weimer wrote:

> The "Rosen trick" is also relevant in this context (see the archives),
> but it only works for limited types.  However, it should be used
> whenever possible because it does not involve erroneous execution.

Yes. However, using Rosen trick with derived types could face problems.
When an function (primitive operation) has to be overridden, then to access
the argument to be modified, one should either cast (bad) or dispatch
(assuming that the self-pointer is class-wide.) I.e. in fact, the function
is class-wide, though declared as a primitive one. It is not good, not a
clean design.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de