Re: Side-Effects in Functions [Rosen Trick]

[dewar@gnat.com (Robert Dewar)]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9s3tl3$111hco$1@ID-25716.news.dfncis.de>...
> I was hoping that it would be obvious that I was putting 
> this point in a
> deliberately polemical style. I am merely stating my own 
> strongly held
> belief on this subject, based on perfectly good 
> reasoning, as well as the
> consensus of programming wisdom.

No, this is by no means a consensus. Most procedural
languages, including Ada, allow functions to have side
effects. And on the narrower issue of allowing IN OUT
parameters in functions, there is nothing like a consensus
opposing this. Indeed my guess is that during the design
phase on Ada 95, if a show down had been insisted on, 
the side favoring IN OUT parameters would have (narrowly)
won, but it seemed inappropriate to force this change in
the absence of a consensus on the other side. So your
understanding of the consensus here is completely wrong.

> > Now in Ada, the rule for functions is a bit odd:
> >
> >   Side effects from access to global variables - permitted
> >   Side effects from modifying access type args - permitted
> >   Side effects from in out parameters - prohibited
> 
> These rules may seem a little odd, but they pertain to what Ada allows
> programmers to do, not what Ada programmers should do. My point was entirely
> about what Ada programmers should do.

Features in Ada are there to be used, anyone who announces
that some feature should never be used probably just does
not understand the issues. Of course they should not be
abused.

> The rationale is simple and well-known Robert! Good grief, every Ada
> textbook on the planet has an example of how side-effects in functions can
> introduce subtle and pernicious bugs (especially on porting). Must I really
> repeat these?

Please don't! Many people would say EXACTLY the same
about assignments, or global variables. Of course this
feature can be misused, as can many features. Forbidding
something because it can be misused is an absurd design
approach and one that fortunately Ada seldom indulges in.

> > Most annoyingly, the natural translation of a * arg in a
> > C function, e.g. *int, is to translate it to an IN OUT
> > parameter, but that is arbitrarily not allowed.
> 
> This isn't the most natural translation, and the prevention of the use of
> in-out parameters in functions is not arbitrary, it was, as you said
> earlier, carefully debated.

Actually the issue of IN OUT parameters was never carefully
debated. It was clear early on that it was one of these
religeous issues (note Nick's odd use of the phrase "strong
belief") which was not something that could be calmly debated (your
"good grief" shows this nicely -- why people
get so excercised over this issue is a puzzle to me).


> To me, it is obvious that option 2 should be used. To describe the required
> aliasing of variables as a 'plague' is rather an overstatement: it simply
> means adding the word 'aliased' to the appropriate objects; that's not a
> plague! It is absolutely right, since they must (at least in effect) be
> aliased for the called C routine(s) to access them via a pointer.

Most people feel that being forced to add aliased keywords
all over the place, just because of odd interfacing requirements for C
functions, is unfortunate. If you find
it perfectly fine to have aliased keywords around, fine,
but you obviously don't have the alergy to aliasing that
many people have. It is not accidental that aliased is not
the default.


> To sum up, I am amazed at Robert's opposition to what I
> have always understood to be a very well established 
> programming principle (in procedural languages such as 
> Ada).

No wonder if you are amazed if you think this is a "very
well established programming principle". That's just wrong.
As I noted earlier, nearly all procedural languages DO
allow side effects in functions.

And of course Ada does too (allow side effects in functions), but has
the odd attitude that side effects
are only OK if they are not announced in the spec. 

Consider the following:

   function f return integer;
   --  Increments the global variable Q and returns the
   --  incremented value.

   function f (Q : in out integer) return integer;
   --  Increments its argument and returns the incremented
   --  value.

I find it odd that Ada allows the first and disallows the
second, and many others would agree with me. Nick, no one
will try to convince you that you are wrong here, because
it is a waste of time, but you should learn that you are
quite wrong if you think your viewpoint somehow represents
a general consensus. I and many other experts in programming languages
in general, and Ada in particular,
disagree with you. The fact is there is no consensus on
either side of this issue.

Oddly, the feeling that goto statements should never be
used has much *stronger* support than the feeling that
IN OUT parameters should not be allowed in functions, yet
Ada does permit goto statements. I think the actual situation is that
this is one of these cases where the
designers get to decide, since there is no consensus.
JDI accepted gotos, but felt that functions should have
no side effects whatever. That was untenable, and he was
argued out of this extreme position, with the result that
we ended up with a rather odd compromise. Tuck is also
somewhat (though not fanatically like you) opposed to IN
OUT parameters for functions, so was not about to decree
that they should go in.

> That principle is taught for very good
> software engineering reasons. I said "Must I really
> repeat these?".

If you have been taught that functions should never ever
have side effects, you have been taught by a fanatic. Such
fanaticism is almost never helpful.