Ada self-referential operators

[bill@valiant (R.A.L Williams)]

In article <3grqrf$jkd@gnat.cs.nyu.edu> Robert Dewar wrote:
: A couple of things Bill, first you would like to see := be overloaded, but
: this is notoriously difficult to define cleanly, and people's first naive
: thoughts quickly founder on very tricky semantic rocks.

C++ seems to manage. Does Eiffel? I can't offhand remember.

OK, in Ada I can see that ":=" may have some implicit semantics not
present with other operators. For example, I believe constraint checking
is expected at this stage of the execution of a statement and not
before. In C++ this would be approached by inheriting from some base
operator.

Optimisation is obviously another problem. Optimisation is just not 
possible if the compiler doesn't understand the semantics of the
operators. After all, I could define something wierd like

procedure ":="(lhs : out Integer; rhs : in Integer) is
begin
  if rhs = 2 then
    lhs := 5;
  else
    lhs := 6;
  end if;
end;

Obviously, any compiler which tried to optimise a basic block containing
that would be in for a nasty surprise! So, OK, we disable statement level
optimisation where overloaded assignment is used. Caveat emptor (I don't
know the latin for programmer) -- if you use this construct, don't expect
optimisation.

: As I assume you know, Ada 95 does allow for the effect of user defined
: assignment, but not via providing a definition for the := "operator",
: which of course is not an operator at all.

My knowledge of Ada 95 is currently rudimentary, but improving. I did
a lot of Ada 83 code some years ago. I wasn't aware of 'User Defined
Assignment and Finalisation' (RM 7.6) until you pointed it out. I assume
from the LRM that to make use of this facility I need to derive the
types I want to perform 'adjustment' etc. on from 'Controlled'. 

Well, OK, with this model for assignment I can see that overlaoding ":="
is going to be inelegant. In fact, the equivalent that Ada 95 provides
*is* inelegant (IMO :-) Effectively, Ada 95 imposes a 'tree' view of
inheritance, and rules out the possibilty of a 'forest' if user defined
init/final/adj is needed. This is because, as I understand it, all classes
(sorry, object speak) must be inherited from Controlled or, presumably,
Limited_Controlled. Probably not a problem, but the sort of minor
irritation that we could do without.

BTW, I don't understand your assertion that ':= [...] of course not an
operator'. Perhaps not in Ada 95, with the semantics of package 
Ada.Finalization behind it, but the assignment operator is as good an 
operator as any other to my way of thinking. Can you explain your
reasoning here?

: Labor saving devices are indeed a good idea, PROVIDING that they save
: labour in the right places. In particular, I regard labor saving devices
: for code writers to be pretty unimportant. The only thing that is important
: is the ease of code reading, and it is CERTAINLY not the case that anything
: that makes code more compact makes it easier to read (if that were true,
: then as Bob Eachus points out, everyone would program everything in APL!)

Yes, but... (moderation in all things! Ada, sometimes makes us go to 
unnecessary lengths to do trivial operations; eg. bit shift in Ada 83
implemented with arrays of 1 bit variables! Let's face it, in a language
promulgated specifically for *embedded* applications, this was nonsense!)

: It is not that I think :+= is peculiar because it is not in the RM, rather
: +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult
: to put it in without running into nasty semantic ramifications.

I'm sorry, I still don't see that. The trouble is that we still disagree
on the status of ":=" I think. If 'procedure ":=" (....)' were acceptable,
and I still don't understand why not, then I can't see anything wrong with
'procedure ":+="(...)' (although I think that "+=" looks nicer).

: I don't know how skilled you are as a language designer. Often it is 
: frustrating to plain users of the language that something that seems
: like it should be simple to do is not there, when it seems so simple
: to put it in.

I have designed a language and led the team writing a compiler for a 
specialist event driven application. Not a great deal of experience, and
not at all like Ada, but I have spent some time thinking about the
implementation of such features in C++. I still don't see where the 
problem is.

[delete]

: Indeed it was very nearly the case that Ada 95 ended up with no user
: defined assignment, since we couldn't find a way to do it. Then quite
: late in the process someone suggested the current approach, and that
: turned out to be tricky but practical, so it was put in.

I would be interested in seeing a discussion about these design decisions.
Some years ago I read the book "Engineering a Compiler" by some engineers
at Digital. Fascinating stuff, but I haven't seen much similar discussion
by language designers. I remain to be convinced, but I have an open mind
(honest).

Thanks for your comments.

Bill Williams