Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler <nntp-2004-02@t-domaingrabbing.de>]

Hyman Rosen wrote:

>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.

Yes, and that is a very good example on how to write bad code. First:
GetName is obviously a function with side-effect, second it relies on
a specific calling order.

If you want a specific order, do it explicitely:

|Tmp_Name_1 := GetName;
|Tmp_Name_2 := GetName;
|
|Battery(Catcher => Tmp_Name_1, Pitcher => Tmp_Name_2);

>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view,

Well, my point of view to the original code would be that it doesn't
matter which name gets assigned to which parameter.

>rather than for the convenience of the compiler.

Yes, true. But Ada is - like a lot of others - a programming language
that is supposed to get compiled some day. And sometimes language
designers should keep an eye on this if they want a language to be
used outside of purely theoretical and/or educational areas.

So it might be possible that in the parsing/compiling process the
order specified in the named notation simply gets reordered to the
order of how the parameters are declared. Well, even this still
doesn't mean, that this would be the order in which the functions are
called in the end.

I think, all this discussion about execution order is a little bit
senseless when today we have processors that do explicit instruction
reordering and even have parallel execution support. Even if the
compiler issues code where the execution order is fixed that doesn't
mean that the processor will execute it this way. And you don't want
the compiler to emit one serializing instruction after another just to
make sure that the execution order does not change, do you?

IMO, it is easier to just not rely on side-effects. No side-effects,
no problems.


Vinzent.