Re: += in ada

["Robert I. Eachus" <rieachus@comcast.net>]

Russ wrote:

> I still don't understand where you got that impression. For overloaded
> "+=", I don't see how it could be anything other than a procedure.

All that discussion about how A += 1 is more efficient than A := A + 1;
The procedural version is theoretically significantly less efficient 
than A := A + 1; although most compilers will, when asked, do the 
inlining that makes it exactly equivalent.  If you think that A += 1 is 
more efficient you are talking about augmented assignment.  (Assignment 
with the addition as a side-effect.)  As I showed, in Ada if you try to 
generalize that to cover all cases, there are insoluble problems.

> On the other hand, for built-in types such as integer and float (and all
> the scalar types derived from them), I would expect "+=" to be
> automatically available. It would be silly to require the programmer
> to define all those. I hope that is clear too.

If you check the tread carefully, you will find articles where I and at 
least one other ARG member discussed adding Inc as a predefined 
operation for Integer types.  Several ARG members favor it, others think 
it is unnecessary.  We could also discuss whether there should be one 
procedure with a default parameter:

procedure Inc (L: in out Integer; R: in Integer := 1);

or two separate versions.  Personally I think the one parameter version 
is enough.

Of course, the predefined operation would only be available for 
predefined Integer types.  But we would probably have to consider 
whether it should be supported for other language defined types and if 
so how.  Take System.Address for example.  This "extra" overhead of any 
language change is one reason that the ARG seems so conservative.  In 
private discussions, some of the language changes considered look pretty 
revolutionary.  If the idea multiplies in scope, then it is usually 
discarded.

As a horrible example, AI-2 and AI-7 from the Ada 83 days were seemingly 
simple issues that multiplied out of control.  I remember one (back then 
LMC) meeting where  AI-2 and AI-7 plus AIs that were separated out of 
them occupied one entire volume of maybe 200 pages, and the other AIs to 
be discussed were a second volume.  As I recall we found a "simple" 
solution to AI-7.  It  basically left when a certain constraint check 
was performed undefined, but required the check. All the implementors 
who were following the discussion knew that for the problem cases there 
was only one "natural" place to do the check. For the rest we didn't 
care which of the natural places it was easiest for the compiler to the 
check.

Back to Inc. If there was sufficient demand from users, I am sure Inc 
would be added in the revision currently in progress.  However, I feel 
that there are a number of more important language changes that are "on 
the bubble" and may not make the cut due to limitations on how big a 
change we can make.  The really hard question is does this discussion 
indicate a groundswell of user support for Inc, a lot of opposition to 
it, or just a lot of idle discussion.

Notice that there are several major changes that almost certainly will 
make it in, and at least one that is "iffy."  Adding Inc would be a 
minor change.  Adding ++ would be a significant change, and augmented 
assignment would be a huge change, if we could figure out how to make it 
work.

-- 
                                       Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig