Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)

["Alexandre E. Kopilovitch" <aek@VB1162.spb.edu>]

Dmitry A. Kazakov wrote:

> BTW, this is an example how one error leads to another. The first error was
> the design fault of Ada 83, that we had no *procedures* (not functions!)
> with return values. The consequent error was to allow access parameters for
> functions in Ada 95. The result is completely misleading. Functions
> *openly* have side effects, but still have no in-out parameters, forcing
> programmers to use pointers (and thus aliased objects).

So what your point here - do you mean that the best way was to provide an
opportunity for procedures to return value, and then either forbid access
parameters for functions entirely or at least limit them to access-constant
only?

If so, what is your guess, why that was not happened - neither in Ada 83 nor
much later - in Ada 95? It was so simple to do (for example, that may be done
introducing RETURN mode for a parameter of a procedure), and in fact there
is a workaround for that in GNAT - implementation-defined pragma (which first
appeared in DEC Ada compiler, I think). This matter certainly was not
overlooked by the language designers - there were discussions around that
matter (you can see them on AdaIC website) - although they apparently
concentrated on another way of dealing with the issue - IN OUT mode for
functions.

You probably don't think that Ada 83/95 designers were stupid, and before
Ada 95 there was substantial experience with Ada 93 - so why they did not
went that way? They probably had some arguments against it. Do you think that
those arguments were invalid even then? Or you think that they may be valid
in 80th and in the first half of 90th, but are dead now?

And what I'd like to add here is that those language designers had (and have)
one very important thing that you and I have not: real data. We can guess what
is error-prone, dangerous etc., but this is only guess, based mostly on our
own experience and imagination and on very limited observation; while they had
(and have) large customer base, they deal with actual cases and error reports,
and see large amount of code produced by real users; so they can *know* what
is really error-prone, dangerous, confusing etc., at least in current
circumstances. Therefore any strong judgement from our side about their past
decisions - like "error" - seems inappropriate... we weren't insiders of that
Ada world of the past, and we aren't historians.  So, even you dislike some
decisions and their apparent consequences, let them still be "decisions", not
"errors".




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