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

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Mon,  5 Jan 2004 06:17:18 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>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?

I meant anonymous access parameters such as:

function Foo (X : access Y) return Z;

Which openly contradicts any possible rationale behind forbidding
in-out parameters.

Alas, there is no anonymous access-to-constant parameters.

As for my point, I have only IF-THEN. If the concept of a function as
a special sort of a pure subroutine with one distinguished side-effect
has to be realized in a language, then that should be made more
consequently than we have it in Ada. Which would also pay off, for
example, by allowing *true* functions in static expressions.

>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?

It is a to death beaten issue discussed in c.l.a. over and over again.
Guess why?

>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.

See above. All arguments are known, to almost everybody, I hope. 

However, that the design was based on an analysis of a large amount of
projects and existing code is somewhat new to me. It would be very
interesting to know, how such analysis could be done in any scientific
manner. I mean precisely:

1. procedures and functions as separate concepts of a subroutine
2. a need to restrict [function] parameters
3. a need to restrict [function] code
4. ways of restricting the parameters and code

with nice diagrams and tables of correlations... (:-))

And honestly, provided all the innovations Ada design brought to
programming languages construction, what was that "real data", back to
late 70s, early 80s?

>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".

Error is a result of a decision. Though the reverse is not true. Not
every decision results in an error.

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