* Re: why only in-parameters in functions
2004-09-29 16:55 ` Alexander E. Kopilovich
@ 2004-09-29 21:10 ` Randy Brukardt
2004-09-29 23:37 ` Björn Persson
2004-09-29 21:12 ` Florian Weimer
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Randy Brukardt @ 2004-09-29 21:10 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: why only in-parameters in functions
2004-09-29 16:55 ` Alexander E. Kopilovich
2004-09-29 21:10 ` Randy Brukardt
@ 2004-09-29 21:12 ` Florian Weimer
2004-09-30 7:41 ` Dmitry A. Kazakov
2004-09-29 22:42 ` Wojtek Narczynski
2004-09-30 1:55 ` Matthew Heaney
3 siblings, 1 reply; 10+ messages in thread
From: Florian Weimer @ 2004-09-29 21:12 UTC (permalink / raw)
* 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: why only in-parameters in functions
2004-09-29 21:12 ` Florian Weimer
@ 2004-09-30 7:41 ` Dmitry A. Kazakov
0 siblings, 0 replies; 10+ messages in thread
From: Dmitry A. Kazakov @ 2004-09-30 7:41 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: why only in-parameters in functions
2004-09-29 16:55 ` Alexander E. Kopilovich
2004-09-29 21:10 ` Randy Brukardt
2004-09-29 21:12 ` Florian Weimer
@ 2004-09-29 22:42 ` Wojtek Narczynski
2004-09-30 1:55 ` Matthew Heaney
3 siblings, 0 replies; 10+ messages in thread
From: Wojtek Narczynski @ 2004-09-29 22:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: why only in-parameters in functions
2004-09-29 16:55 ` Alexander E. Kopilovich
` (2 preceding siblings ...)
2004-09-29 22:42 ` Wojtek Narczynski
@ 2004-09-30 1:55 ` Matthew Heaney
3 siblings, 0 replies; 10+ messages in thread
From: Matthew Heaney @ 2004-09-30 1:55 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 10+ messages in thread