From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f712c3cc98e7f25 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.tu-darmstadt.de!newsfeed.velia.net!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 15 May 2008 22:48:20 +0200 From: Georg Bauhaus Reply-To: rm.tsho+bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: not X'Length References: <482c0030$0$7542$9b4e6d93@newsspool1.arcor-online.net> <954e4cd2-11a9-420b-85c4-7741c429e1b2@c65g2000hsa.googlegroups.com> In-Reply-To: <954e4cd2-11a9-420b-85c4-7741c429e1b2@c65g2000hsa.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <482ca195$0$6788$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 15 May 2008 22:48:21 CEST NNTP-Posting-Host: 46ba73cb.newsspool2.arcor-online.net X-Trace: DXC=>;`Y0SE[`5F0YVY]kmLTlDA9EHlD;3YcB4Fo<]lROoRA8kFejVHkB6kn1P=?SI_cnP08@d65I X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:82 Date: 2008-05-15T22:48:21+02:00 List-Id: 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 IN THEN -- <==*= IF THEN o.K., no error. You write IF not IN THEN -- <==*= IF not 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 " (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.