Re: status of Ada STL?

[Robert A Duff <bobduff@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.

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.

> 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.  ;-)

> 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.

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?

> 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);

> 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).

> 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.)

> 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.

>... 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!

>... Initially, a pre-processor could be called explicitly to convert
> Ada-F files to standard Ada files, but eventually Ada compilers could do
> the conversions automatically.
> 
> The proposed syntactic changes are minor enough that it might be
> possible to allow both dialects within the same source file, but that
> has yet to be verified. If so, the pre-processor would pass standard Ada
> source lines through unchanged, and would change only lines using the
> new syntax. Another possibility is to denote Ada-F files with a keyword
> such as "Ada-F" in a comment in the first line of the file.

- Bob