Re: not X'Length

[Georg Bauhaus <see.reply.to@maps.futureapps.de>]

christoph.grein@eurocopter.com wrote:
> From RM 4.4 follows that this is equivalent to
> 
> if (not X'Length) in Positive then
> 
> Now Universal_Integer (X'Length is of this type) has no operators, so
> it has to be converted to an appropriate type. This is Integer (or, to
> be very precise, the type of Integer) in this case. But then there is
> no "not" defined for this type. So the compiler is correct.

While the compilers are correct, on the programmer's part the
issue is not that easy to understand in general.
You have demonstrated why this is so. Hence my original
question about programmer expectations regarding improved
compiler's diagnostics in this case.

Apparently GNAT can do better in a similar case,

 if not X'Length in Gotcha then  -- Gotcha a mod type

"warning: not expression should be parenthesized here"

for whatever reason.

The issue is that the compilers are correct but they do
not point at the original programmer mistake. While this isn't
unusual, Ada compilers seem to be very good at pointing to
the real cause.


Suppose you are a willing but naive Ada programmer you had
written (and thought)

IF <L> IN <R> THEN       -- <==*=  IF <E> THEN

o.K., no error. You write

IF not <L> IN <R> THEN   -- <==*= IF not <E> THEN  -- Doh!

and are being told "incompatible types", which is a technically
correct whipping. But the thing that has changed, you thought,
is the addition of negating the original Boolean expression.
You thought. And now there is a type issue?

IF not X'Length IN Positive THEN

(a) it's a precedence thing and
(b) as you demonstrate, it takes several mental indirections
to interpret X'Length correctly
    (b.1) as a value of some unnamed type that
    (b.2) will potentially be of a type that,
          (b.2.*) seen without regard to "IN <R>"
          (b.2.+) seen after "NOT"
is nothing you would have expected. You think,
"How on earth can I apply a Boolean operator to an array length?"

I'm *not* saying the compilers are incorrect.
But maybe they could be a bit more helpful in this case (as in the
second GNAT warning).
This is why I had considered filing an enhancement request, unless
this request is obviously too ambitious. I simply don't know.