Re: Ideas for Ada 200X

[Richard Riehle <richard@adaworks.com>]

Steve wrote:

> In my opinion the benefit of += has nothing to do with efficiency or ease in
> writing.  It's all about readability.

If we adopt this syntax, in Ada, we will need to include some rules in the
language to enable the compiler to discern a clear  difference between
the += and :=.   That is, in Ada's current model, we want to compiler to
be able to tell us when a construct is a mistake or warn us when it will
potentially create an incorrect execution.

What rule can you come up with that will enable the compiler to, at minimum,
warn the programmer that this,

               i :=  1;
               i += 1;

poses no hazard.   It is bad enough that, in many derivates from C,  a legal but

erroneous code can be created when the programmer confuses the = and the = =.
This cannot currently happen in Ada, ever.

So, if there is some approach that will ensure that my i += 1 could not be a
mistake
for i := 1,  that would go a long way toward making it an acceptable construct.

Granted, in C the =  symbol is an assignment.   Therefore, the = = will not be
mistaken
for a +=.  However,  the use of these shortcuts can have interesting results
when used
incorrectly.   Consider the difference between  ++i  and i++.  Often this will
not create
a problem.  Often it will.

The readability we emphasize for Ada is not suggest human readbility.  It also
includes
compiler readability.   We are striving for less ambiguity in the language, not
more.
Therefore, each new feature must be evaulated in terms of its potential
ambiguity, not
just for the human reader, but also for the compiler.

In this regard, Ada is a leader, not a follower.   Leaders are not always
popular.  Ada
may never be popular, but it will continue to be the best language when one
requires
a language with internal consistency, lack of ambiguity, and a focus on
high-iutegrity
software.

It is very easy to become enamoured of a particular syntax.  Many a young man
has
lost his heart to a pretty face only to discover that the underlying personality
was
incompatible with his own.   Ada is not designed to be just another pretty
face.  It
is designed to support a serious set of goals,  consistently, correctly,
confirmably,
and coherently.   We might add, correctly compilable, because that is the
ultimate
test of any new syntactic feature.

Perhaps I am an old fuddy-duddy when it comes to Ada.   However, my programming
experience pre-dates the advent of Ada by some considerable number of years.  I
have made, during my career, as many or more programming mistakes as anyone
alive.  Perhaps that is a function of my cultivating my own stupidity more
effectively than most of my contemporaries.  One reason I appreciate Ada is the
way it helps me look smarter than I really am when creating code.   I rely,
perhaps
too much, on the compiler to trap those silly little mistakes I so often made
when
programming in some earlier languages, including Assembler, COBOL, Fortran,
PL/I, Neat 3, BASIC, C ( and later C++) to name a few.

So, when you can define, using well-formed semantics, how the compiler will
be improved (not the popularity of the language), how error-checking will be
sustained, and how my own stupidity will be mitigated, by the addition of this
feature, I will gladly admit my error and support your proposal.  At this point,

however, the proposal seems to be based largely on the notion that, "If C and
its derivatives has it, it must be good."   That is not good enough for me.  I
need
more carefully reasoned exposition.

Richard Riehle