Re: Better Finalisation [List container strawman]

[dewar@gnat.com (Robert Dewar)]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9seup3$12h0ar$2@ID-25716.news.dfncis.de>...

>    procedure T'Construct (Object: in out T);
>    procedure T'Destroy (Object: in out T);
>    procedure T'Assign (Source, Target: in out T);

It's easy to suggest something at this level, but much much
harder to work out the full implications. A starting point
would be to work up a full complete coherent description
based on the above thought.

You will find it much harder than you think. 

You should also thoroughly review the discussion of this
issue during the design phase. In fact finalization (note
by the way that we spell it with a z in the Ada world, and
indeed that's the preferred spelling anyway) was extensively discussed
during the design phase, and of
course the above general idea was explored (this is hardly
a non-obvious idea).

The conclusion at that time (I don't see anything that would change
it) is that this was too complex to work out,
and the feature was dropped.

Finalization was reintroduced when a suggestion based on
the current semantics was made. This seemed much simpler,
and was put in relatively late. However, it has turned out
from an implementation point of view that even this proposal was far
harder to implement that expected.

But anyway, read the old stuff, no point in reinventing
the wheel. As so often happens in language design, ideas
that seem simple at the naive user level turn out to be
a den of vipers at the detailed semantic specification
level.

Nick, you should certainly have all the old mapping documents on your
shelf. You will find these a fertile
source of interesting ideas. The old mapping documents
are full of coherent well worked out useful ideas that
did not make it into the final language not because they
were wrong (*) but simply because there was a requirement
to keep the entire language at an acceptable level of
complexity (**).

Can we do more for the next version? Perhaps in some
critical areas, but not much. If the next version of
Ada is too big a delta, it will simply be ignored by
vendors at this stage. Even now, we have lots of customers
running Ada 83 rather than Ada 95 -- transition takes a long long
time.

Robert Dewar

(*) Tuck always used to demand that we show why a feature
was wrong before he would agree to remove it, but most often there was
nothing wrong. The straw was all high
quality, but the camel's back was still in danger :-)

(**) I think we probably hit about the right level in
retrospect. We lost one major vendor (DEC, who decided
that the effort in moving to Ada 95 would be too great,
and so abandoned their successful and profitable Ada
product), and we lost a couple of other front ends
(Alsys and Telesoft), but we gained a couple of front
ends (GNAT and Intermetrics), and it proved possible
to move an Ada 83 compiler to Ada 95 (Rational and
others).