Re: Constructors/Destructors in Ada95

[Ray Blaak <blaak@infomatch.com>]

Marin David Condic <mcondic.nospam@acm.org> writes:
> Ray Blaak wrote:
> > I really would like to be able to do:
> >
> >   procedure ":="(target : in out T; source : in T);

> there are a lot of obvious problems with trying to redefine
> ":=". The biggest problem is that it is not a subprogram - it is a primitive
> feature of the language.  I believe this might be an example of Godel's
> Theorem. There are some features of the language (any language) that cannot
> be expressed in the language itself. As a "function" it would require that a)
> the left parameter be treated as "out" and b) that the function need not
> return a result. (or that it could be ignored. Does a statement like: "X < Y
> ;" make sense in Ada?) As a procedure, you'd have to allow procedures to have
> symbol names - which opens up a whole can of worms. Further, it would mean
> allowing "infix procedures" which is hard to make sense of - or at least
> could make programs look really strange.

I don't think syntax issues would be a major problem here. It can't be a
function, since a return value makes no sense -- we need to operate on the
target directly. So yes, we would introduce procedures to have (the single
possible) "operator" name.

It is not really a Godel limitation. The problem is that Ada is missing the
necessary expressive power, likely on purpose in this case. The existence of
user-defined assignment in C++ indicates that it is quite doable in theory,
though, so it is only a matter of deciding how to extend Ada, if at all.

But this is a minor change as far as the Ada grammar goes. As for wierd infix
procedures, it would look quite normal: 

  a := b;

The wierd thing would be to see:

  ":="(a, b);

But that is not complicated from a parsing point of view. 

Still, parsing problems can be avoided by having a type's assigner be
accessible from T'Assign, and then allowing:

  procedure DeepCopy(target : in out T; source : in T);
  for T'Assign use DeepCopy;

One problem I can think of is that we need to access the primitive assignment
in order to implement the user-defined assignment. How does one refer to it?
There is no "super" keyword in Ada. I suppose various renaming tricks are
possible, but since they would always have to be done, that would quickly prove
tedious.

Perhaps we could have T'PrimitiveAssign be available for this purpose.

However, I am looking for the subtle stuff. So far I have heard:

a) discriminants problems involving the creation of fields when a different
  discriminat is specified

  - This one I would like to understand better. Why wouldn't something like
    this work:

    -- For all types T, T'Assign is the primitive ":=" operation.

    procedure ":="(target : in out T; source : in T) is
    begin
      -- do the usual thing:
      T'Assign(target, source); 
      -- now the extra work for doing deep copy, etc.
    end ":=";

b) User-defined assignment is not enough, also consider initialization and
  parameter passing.

  - Maybe so. So let's generalize these too.

> I'm sure there are dozens of other reasons why it was decided not to provide
> a means of letting the user define assignment. I'd think it would require
> perverting, warping and twisting language concepts too much. (Look at the
> semantics of C++ construction/destruction sometime - especially as it applies
> to function parameters - and see what an abomination that can become!

I don't have the sense that it warps things too much. C++ construction and user
assignment seems quite understandable, at least for the usual cases.

Are there any online archives somewhere that consider the issue? I think the
Ada 9X discussions used to be, but they seem to have disappeared.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.