From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Gnat bug or mistaken program? Date: Tue, 27 Jul 2021 19:00:08 +0300 Organization: Tidorum Ltd Message-ID: References: <318e5e93-5f66-4bb8-8bf0-7ee3fd2688fan@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net 8YhlTkiwLN6xHlyPacuZHgRw9pUnVFSNFqA3acQ/esGMaYJMmM Cancel-Lock: sha1:JOea4FZVx3wlJEOd7BmtIpTv1b8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:62425 List-Id: I disagree with Jeffrey's opinion on what is a reasonable solution here. More in-line below. On 2021-07-21 11:29, Jeffrey R. Carter wrote: > On 7/21/21 4:23 AM, Richard Iswara wrote: >> On 20/07/2021 21.09, Niklas Holsti wrote: >>> On 2021-07-20 15:02, Richard Iswara wrote: >>>> I get this error on my program from the menu build => check semantic >>>> exponent must be of type Natural, found type "Standard.Float". >>>> >>>> Should not 10 ** (log10 a + log10 b) = a*b? >>>> >>>> This is my compiler build: >>>> >>>> GNAT Studio Community 2020 (20200427) hosted on x86_64-pc-mingw32 >>>> GNAT Community 2020 (20200429-93) targetting x86_64-pc-mingw32 >>>> SPARK Community 2020 (20200429) >>>> >>>> Here is the relevant part of program: >>>> >>>> with Ada.Numerics.Elementary_Functions; >>>> use Ada.Numerics; >>> >>> >>> To make Ada.Numerics.Elementary_Functions."**" visible without >>> qualification, you should also do "use >>> Ada.Numerics.Elementary_Functions". >>> >>> Otherwise the compiler will see only the predefined operator: >>> >>>     function "**"(Left : Float; Right : Integer'Base) return Float >>> >>> (see RM 4.5.6(9 and 10)) which explains why the compiler does not >>> accept a floating-point value as the Right operand to "**". >>> >>> >>>> Logs : Float := 0.0; >>>> Multiples : Float; >>>     ...> Multiples := 10.0 ** Logs;  => this is where it fails >>> >>> >>> It fails because the compiler sees only the predefined "**" operator >>> which has an integral right operand. >> >> Thank you. So it is a visibility problem. > > "Understanding visibility is the key to understanding Ada." -- /Ada > Distilled/ Hm. I agree visibility is important, but it is hardly the only important Ada concept. > Recommending the use package clause as a solution to a misunderstanding > of visibility is a disservice to a beginning user. Yes, unless the recommendation also includes explaining what the "use package" does, thus increasing the user's understanding of visibility. > In decreasing order of specificity, the ways to call an operation in a > pkg are > > * Use the full name: Ada.Numerics.Elementary_Functions."**" (10.0, Logs) >   This calls the operation once without changing its visibility An application that needs "**" is likely to need other operators. Using the fully qualified names makes non-trivial expressions much harder to read and write. In the special case of a very few uses of very few operators, I agree that this is a workable solution. > * Rename the operation: >   function "**" (Left : Float; Right : Float) return Float renames >      Ada.Numerics.Elementary_Functions."**"; >   This makes the specific operation visible Before Ada got "use type", such renaming declarations were the only alternative to "use package", but they are verbose and proved (in my experience, and that of others too) to be very error-prone, mainly when renaming many operators -- copy-paste errors were rampant and hard to find by reading. Interesting effects occur when "-" is renamed as "+" or vice versa. I consider this solution to be the last (worst) choice. > * Use type: this makes all operators of the type visible (not applicable >   in this case) > * Use all type: this makes all operations of the type visible (not >   applicable in this case) These are IMO usually the best methods but, as you say, not applicable here. > * Use package: this makes everything in the package visible > > Use pkg is clearly overkill for this case, I disagree. If the code uses several operators from the package, a "use package" is apt (because "use type" does not apply here), but should of course be as local as possible. > and overuse of it can have negative consequences. Agreed.