Rationale for Ada 2005
9.3.9 In out parameters for functions
This is a really interesting topic. Ada functions
are curious. On the one hand they look as if they are going to be well
behaved since they only allow in parameters and thus it appears as if
they cannot have side effects. But of course they can have any side effects
they like by using global variables! And parameters can be access types
and nothing prevents the accessed values from being changed. Indeed access
parameters are a sort of sly way of getting in out parameters anyway.
The proposal (
AI-323)
was to allow functions to have parameters of all modes. The rationale
for the proposal is well summarized in the problem part of the AI thus
"Ada functions can have arbitrary side effects, but are not allowed
to announce that in their specifications".
Clearly, Ada functions are indeed curious. But strangely,
this AI was abandoned quite early in the revision process on the grounds
that it was "too late". (Perhaps too late in this context meant
25 years too late.) In any event there was no agreement on a way forward
since there are strong arguments both ways. But there was agreement that
time would be better spent discussing and agreeing other matters.
One suggestion is that two kinds of functions should
be supported. Absolutely pure side-effect free functions that merely
deliver the value of some state. Functions in SPARK
[9]
are like this. And the other sort of function could be one that is just
like a procedure and can do anything and have all modes of parameters
but for convenience returns a result which can then be used in an expression.
It is interesting to note that Preliminary Ada
[11]
had value returning procedures as well as functions. The functions were
pure but value returning procedures were much as current functions and
could have side effects. But value returning procedures could not have
out and in out parameters. The difference between the two was thus not
enough and so pure functions were dropped and value returning procedures
became functions.
This topic may deserve to be revisited at some time.
© 2005, 2006 John Barnes Informatics.
Sponsored in part by: