Re: Future Ada language revisions?

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <6um7on$db5$1@nnrp1.dejanews.com> bpr5549@my-dejanews.com writes:

  > PS: In case anyone is wondering, my main peeve is the restriction
  > on out mode function parameters, which I just don't understand,
  > even when I'm trying to open minded. I have yet to hear a good
  > defense of this restriction, so if anyone has one, I'm all ears,
  > errr, eyes.

   I don't have strong feelings either way here, with a slight bias
toward allowing it in interfaces to make interfacing to C easier.
(Flame retardant:  Of course in C you can't have a function that
changes a function parameter, but the workaround it to require the
user to pass a pointer to an appropriate sized area.  You can, of
course, do exactly the same in Ada, but it means that the caller has
to be responsible for managing the memory.)

   But let me give the reasoning from the winning side:  There are
four cases where functions with side-effects are needed. 

   1) Memoizing functions, like random number generators.  This can be
done neatly enough in Ada, but in fact the twin requirements of Annex
A semantics and good performance make this a little tricky.  However,
users are unlikely to have to deal with any case as tough as the A.5.2
generators.  (The tough part is A.5.2(46): "Any storage associated with
an object of type Generator should be reclaimed on exit from the scope
of the object.")

   2) Functions which return more than one unconstrained value.  Again
Ada offers a disciplined way to do this since you can always declare a
record type and return that.  The known special cases in Ada 83 were
dealt with elsewhere, such as with Ada.Task_Identification.Task_ID.

   3) Functions which are operations of an object, with side effects
on that object.  The solution here is to make the complete object type
an access type, and hide that fact completely from outside users.  The
introduction of finalization in Ada 95 vastly simplifies the amount of
work to do this right in Ada 95.

   4) Interfacing to languages which permit functions to modify
parameters directly.  The prime case is PL/I.  (I like PL/I, I've
written a lot of code in PL/I, including parts of three Ada
compilers.)  Of course, PL/I is relatively much less popular than it
was when Ada 83 was standardized.

   So in every case where it is needed, the drawbacks are much less in
Ada 83.  On the other hand, if you do pull a fast one in Ada and write
a function with a side effect, READERS of the code will be very
surprised, and may miss the intent of the function, and certainly the
fact that such a call could have side effects or change its
parameters.  So allowing such functions has a distributed cost in
shops where no functions with side effects are ever written.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...