"Matt Borchers" <mattborchers@gmail.com> wrote in message
news:75d90749-242f-42b8-ba0b-299f7ac693e0n@googlegroups.com...
>Throughout my career, I often find myself writing code similar to:
>
>if (A and B) or else (not A and C) then...
>
>and I always wished there was a better and clearer way to write this in
>Ada. Then along came if expressions. >But, if expressions don't help that
>much with readablity although it is arguably simpler:
>
>if (if A then B else C) then...
>
>What amendment can we suggest to the Ada syntax so the if expression be
>better written when used in an if >statement? I know other languages
>support this and it often looks like A ? B : C or something similar.
>That's >certainly not Ada-like IMO, but I can't think of something better.

Which is the rub. Ada is *not* about clever operators that hardly anyone
knows what they do. Indeed, the original proposal for Ada 2012 was an
"implies" operator. But we quickly found out that there are many people that
don't know off-hand what function an implies operator does. We were pretty
sure that every Ada programmer would understand an if expression.

Note that pretty much the only place that you should almost never use an if
expression is in the choice of an if statement. If you already can write an
if statement, you don't need an if expression! If expressions exist to make
initializations and assertions like (Pre/Post) easier to write.

So I would never write your expression in the first place (either of them).
I'd write something like:

if A then
if B then.
else
end if;
else
if C then
else
end if;
end if;

The contents of the arms should be short anyway, and typically will just be
a procedure call (and possibly some debugging, which is way easier if the
conditions are kept simple).

>These same languages often also have a null check operator A ?? B (where
>A and B are
>access types of the the same Type) such that if A is not null then A is
>returned otherwise B
>is returned. So useful and helpful!

Again, "utility" is not the criteria for Ada, rather understandability for
future maintainers is the primary criteria. The last thing we need is a
bunch of fancy but little used operators that some one cold when reading
some unfamilar code. (Yes, of course you can look them up on-line, but
stopping to doing so necessarily breaks your train of thought.)

And this construct fits nicely into an if expression, with no magic:

(if A /= null then A else B)

and this extends nicely to more likely cases:
(if A /= null then A elsif B /= null then B else raise Program_Error)

(Personally, I don't believe I've ever written something where such an
operator would be useful; one needs to check everything for null (you can't
usually can't assume B is nonnull, either). And the fall backs are generally
more complex than using some other object. Moreover, probably A should have
been declared null-excluding so it doesn't need to be tested in the first
place. :-)

-----

> Again, I often find myself writing a loop to search for something and then
> performing
> one or another action depending on the success of the search. ...

.....
>for i in arr'Range loop
> if arr(i) = match then
> --do something A
> exit;
> end if;
>then
> --do something else B
>end loop;

>The "then" part only executes after the loop terminates normally, ...

In Ada terms, an exit *is* normal completion, so you would need some
different terminology.

> i.e. only when the loop does NOT exit early by "exit" or "return"
> statement.

We've discussed the "continue" statement multiple times, and have always
ended up deciding that we are better off without it. (We've also discussed
allowing "exit" from blocks, but that turns into a mess when blocks and
loops get mixed, at least if one wants the code to do the same thing in Ada
2012 and in future Ada.)

We'ver essentially decided that it is better to use a goto in such rare
cases. The case you show above is similar.

for i in arr'Range loop
if arr(i) = match then
--do something A
goto Loop_Finished;
end if;
end loop;
-- We get here if the search item is not found:
--do something else B
<<Loop_Finished>> null;

Remember that every feature added to a language adds costs in
implementation, documentation, and in tools (analysis, checkers, etc.). A
feature needs to be quite useful in order to make the cut.

Aside: in the case above, I've usually written such loops like:

for i in arr'Range loop
if arr(i) = match then
--do something A
exit;
elsif i = arr'Last then
--do something else B
exit; -- Not really needed, but clearer what is going on.
end if;
end loop;

I've never been that happy with the duplication of the termination
condition, but this avoids any extra objects or any gotos.

If I was going to try to fix your problem with a language feature, I'd
probably try to define an attribute to avoid needing to duplicate the
termination condition. Something like:

Loop_Name: for i in arr'Range loop
if arr(i) = match then
--do something A
exit Loop_Name;
elsif i = Loop_Name'Range'Last then
--do something else B
exit Loop_Name; -- Not really needed, but clearer what is going on.
end if;
end loop Loop_Name;

(We probably would allow 'First and 'Last in such a case.) But this
technique doesn't really work with user-defined iterators (which don't
necessarily have a defined end), and I'm unsure if it is important enough
for another whistle.

>I think syntax enhancements like these could go a long way to making Ada
>feel like it is
>at least keeping up with modern languages and I think current programmers
>expect
>"ease-of-use" syntax from today's languages.

Ada has *never* been about "ease-of-use". It is about readability,
maintenability, and understandability. (See the "Design Goals" in the
Introduction -- http://www.ada-auth.org/standards/2xrm/html/RM-0-2.html.)

Enhancing readability might also enhance ease of use (for instance,
user-defined literals, target name symbols, and user-defined indexing all
were added to enhance readability by avoiding duplicative text that provides
little information), but it is never a primary goal for an Ada feature.

>Other contemporary modernized languages have taken ideas from Ada, but Ada
>has not
>continued to pioneer ideas as quickly. Perhaps that's by choice or design.

This is not true. Ada pioneers ideas all the time (see delta aggregates,
aggregate iterators, the target symbol, parallel stuff, etc. from Ada 2022).
What Ada does not do is waver from its core goal of readability and
maintainability. So we don't waste time with tiny features that are more
likely to harm readability and understandability than help. (Admittedly,
what features are really necessary and which are just nice to have is always
a personal choice.) Additionally, Ada has always been designed with a
"building-block" approach, so we don't provide (say) a semaphore, but rather
the tools (the protected type) to write one (and many other constructs). An
if expression is a building block; funny boolean operators with limited uses
are not.

I personally am not the least bit interested in worrying about ease-of-use
gadgets in other languages. If programmers need such gadgets to be
comfortable, they probably don't have the right mindset to be great Ada
software engineers in the first place. Saving a few characters in a few
expressions simply does not matter when compared to the effort needed to
define and document a good data abstraction (for instance, an abstract data
type and package).

There *are* features that probably would not interfere with Ada goals of
readability. One of them that comes up periodically is an "at end" clause so
one could write final wishes for a block/subprogram/package without writing
a bunch of exception handlers (which doesn't work in the case of abort!) or
one-time use controlled types. I'm sure there are others.

And certainly other languages have interesting features that Ada should
steal, the Rust owned access types would be an obvious example. (Don't get
me started on why Ada 2022 does not have those.) But "ease-of-use" is not
interesting, at least when it does not make readability better. (I want
people to replace "and" and "or" with if expressions as much as possible, as
those are much more understandable. No more operators please!)

Randy.

P.S. Man. did I spend a lot more time than I planned answering this. I hope
it helps.