Re: status of Ada STL?

[18k11tm001@sneakemail.com (Russ)]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc8z5czi89.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > I really don't understand the objection to my proposal. 
> 
> OK, I'll try to explain *my* objections.  (And I will refrain from
> accusing you of being a C lover. ;-)  Your proposal clearly states that
> your ideas come from Fortran and Python.)  I even agree with some of
> what you said.

Thanks for your thoughtful reply. I have a few rebuttals below.

> I understand your point that you can write a preprocessor, so people can
> choose whichever notation they like.  I think that's a bad idea,
> because it hinders communication among Ada programmers.
> 
> Here's your proposal, with my comments:
> 
> > A Cleaner Syntax for Ada Programming
> > 
> > Ada 95 is a great programming language with an excellent fundamental
> > design. However, it has an awkward, "klunky" syntax. I propose to
> > simplify its syntax by borrowing features from Fortran 95 and Python. I
> > will tentatively call the resulting new dialect "Ada-F". Ada-F maintains
> > all the safety features of Ada and can be converted into standard Ada 95
> > with a simple pre-processor (to be developed). Existing Ada compilers
> > can still be used, therefore, and programmers who wish to continue using
> > the old syntax can do so. Here are the changes I propose:
> > 
> > 1. Eliminate semicolons, except for combining multiple statements on a
> >    single line, as in Python and Fortran 95, and use "\" (backslash) to
> >    continue a statement on the next line when necessary. Semicolons are
> >    unnecessary clutter, and they cause many nuisance compilation
> >    errors. 
> 
> Equating "statement" with "line", and then having a convention like "\"
> to mean "I didn't really mean end-of-line; I just ran out of room" seems
> kludgy to me.  The ";" seems much cleaner, and I don't find it a
> nuisance at all.
> 
> There are some languages that eliminate the need for ";" by carefully
> designing the syntax to avoid the need.  That seems reasonable,
> but the "\" convention is an abomination.

I'm open to suggestions. Actually, if an open "(" has yet to be
closed, you don't need any line-continuation symbol. That takes care
of most multi-line statements right there, perhaps.

Also, I do not see why "\" is so bad. Fortran uses "&", which is
preferable, but that symbol is already used in Ada. The backslash is
used in many scripting languages, so it seems appropriate to me.

> > 2. Use "=" rather than ":=" for assignment. The vast majority of
> >    languages use "=" for assignment, which is simpler and perfectly
> >    adequate. (Continue to use "=" for equality testing if confusion with
> >    assignment can be avoided, otherwise use "==", but never allow
> >    assignment within an "if" test.) 
> 
> As I said in a different posting, maths tradition ought to trump the
> faddish concerns of an industry that's only a few decades old.  ;-)

Consider the major languages in widespread use today, such as C, C++,
Java, Perl, Python, and Fortran. They all use "=" for assignment. It's
virtually a standard, and it makes it easier for programmers to become
fluent in several languages. But Ada is the oddball. A programmer who
wants to be multi-lingual will therefore constantly have annoying
compilation errors when using Ada. The life of a programmer is filled
with enough annoyances already without stupid ones like that.

> > 3. Use "=" instead of "=>" for passing arguments by named association,
> >    as in Python and Fortran 95. Again, it is simpler and perfectly
> >    adequate. 
> 
> I don't much like "=>" either, but this is another example of using "="
> to mean something other than equality -- see my previous point.

The other thing that bothers me about "=>" used this way is that it is
backwards. It should really be "<=", but of course that's already
taken. If you Ada folks were consistent, you would use "=>" for
assignment too:

x => 3;

How does that grab you?

> An early version of Ada used ":=", ":=:", and "=:" to indicate 'in',
> 'in out', and 'out' actual parameters.  This I like, because I think
> it's useful to indicate this information at the call site.
> 
> > 4. Use ":" instead of ".." to denote a range of numbers, as in Fortran,
> >    Python, and Matlab. 
> 
> Shrug.  I see no advantage or disadvantage to ":" vs. "..".
> So why change?

It's not a big deal, but ":" is more consistent with other languages,
such as Python, Fortran, and Matlab. Also, it does use one less
character, and it looks better without spaces, for example: (1:3) vs
(1..3). In the latter case, the first dot looks like a decimal point.

> > 5. Add assignment operators such as "+=", "-=", "*=", and "/=". These
> >    operators produce cleaner code. They could also facilitate much more
> >    efficient vector/matrix operations if integrated into the core
> >    language. 
> 
> I agree with you that there should be a notation for these, but given
> that I reject number 2, I don't like *these* notations.  And of course,
> "/=" already means something else in Ada.  I believe Algol 68 uses
> "+:=", which seems OK, but I would actually prefer "Increment" or
> "Incr".  The goal is not to make the notation short, but to avoid having
> "X" appear twice in things like "X := X + 1;".  X could be a long
> expression, and having it appear twice means the reader has to carefully
> notice whether it's really the same, and also whether there are side
> effects that might occur twice.  I think this:
> 
>     Incr(X, By => 2);
>     Incr(X); -- By defaults to 1.
> 
> is more readable than:
> 
>     X := X + 1;
> 
> if X is a medium-to-long expression.
> 
> So on this point, I partly agree with you.
> 
> Your point about efficiency is partly right: If you call a procedure
> that updates one of its parameters, that can be more efficient (eg in
> the matrix case, as you say).  But this is true whether or not the
> notation is built in -- it could just as well be a user-defined
> 
>     Matrix_Add(X, Y);

Yes, but the name of your Matrix_Add function above does not make it
clear what is happening. Does it return the sum or add them in place?
The advantage of "+=" is that it is clear what is happening (assuming
it is implemented properly, of course). That was the original idea
behind operator overloading in the first place, wasn't it?

> > 6. Allow a more natural declaration/initialization syntax, as
> >    illustrated by the following example: 
> > 
> >    count: integer := 0; -- old syntax
> > 
> >    count = 0: integer -- new syntax
> > 
> >    The assignment is to the variable, not the type, and the new syntax
> >    shows that. The same applies to default subprogram arguments. 
> 
> Shrug.  Maybe I'm just used to it, but it seems perfectly reasonable to
> me to have the name of the thing, followed by its type, followed by its
> initial value (more important info ... least important info).

Sorry, but I don't see how it makes sense to assign the value to the
type. Also, my syntax is consistent with an assignment statement, and
that's aesthetically pleasing to me.

> > 7. Let "use" imply "with" so files need not be cluttered with both
> >    "with" and "use" for the same package. Note that this would not
> >    preclude the explicit use of "with" if that is deemed preferable. 
> 
> I agree with this point.  Saying "with X; use X;" is useless clutter
> when you could just say "use X;".  (With child packages, X is often
> quite long, so saying it twice hinders readability.)

Some people seem to think I want to eliminate "with" altogether. Not
so. But all those duplicated "with" and "use" statements are enough to
drive a beginner away from Ada, particularly when they are for nothing
but basic I/O formatting.

> > With these relatively minor changes, I believe Ada could gain the
> > popularity it deserves.
> 
> This is the point I most strongly disagree with.  All of the above
> issues are trivial, and even if I agreed with all of them, I don't think
> they would have the slightest effect on people's language choices.

And here I though I was making progress! You Ada guys never cease to
baffle me. On the one hand, my proposed changes are "trivial," and on
the other hand, implementing them will be like "moving a mountain."

> >... Yet existing compilers would still work, and
> > programmers who prefer the old syntax could continue to use
> > it.
> 
> This makes it even worse.  It's bad enough that people won't follow the
> RM-recommended indentation and capitalization styles.  Now you're saying
> they don't have to agree on the spelling of assignment and whatnot!

If you really want them to follow indentation conventions, you could
always force the issue, as Python does. But even I wouldn't go that
far.

You Ada guys are so worried about having two slightly different
dialects of Ada, but a much bigger problem for Ada is that it uses
basic syntax that is inconsistent with all the other major languages
in widespread use today, as I explained above. Unless you guys wake up
to that fact, I'm afraid Ada is on the way out -- and that's a shame.