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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d0452dbe16ac0df4 X-Google-Attributes: gid103376,public From: kst@sd.aonix.com (Keith Thompson) Subject: Re: ObjectAda vs Gnat -- bugs Date: 1997/05/16 Message-ID: #1/1 X-Deja-AN: 241814987 Sender: news@thomsoft.com (USENET News Admin @flash) X-Nntp-Posting-Host: pulsar Organization: Aonix, San Diego, CA, USA Newsgroups: comp.lang.ada Originator: kst@pulsar Date: 1997-05-16T00:00:00+00:00 List-Id: louis.granger@MAIL.POLYMTL.CA (granger) wrote: > Here is a shortened version of a package that I wrote. > > It compiles without any error with ObjectAda. > With gnat3.09, I have the following errors: > > rgbcolor.ads:18:41: expect object name in renaming > rgbcolor.ads:19:49: expect object name in renaming > > Which of the compilers is correct ? > > If gnat is correct ( probably gnat!!!), the internal package RGB_Value does > not have any influence, how can I have the enumeration values Gray* and > Grey* of the same type or subtype with the same internal value ? > > Thank in advance for any suggestion. > > package rgbcolor is > package RGB_Value is > type Color3 is > record > red, green, blue : Float; > end record; > Gray0 : constant Color3 := ( 0.000, 0.000, 0.000 ); > Grey0 : Color3 renames Gray0; > Gray1 : constant Color3 := ( 0.012, 0.012, 0.012 ); > Grey1 : Color3 renames Gray1; > end RGB_Value; > > type Color_Type is ( Gray0, Gray1 ); > > subtype Grey_Color_Type is Color_Type range Gray0 .. Gray1; > > Grey0 : Color_Type renames Gray0; -- line in error--------------- > Grey1 : Color_Type renames Gray1; -- line in error--------------- > end rgbcolor; Actually, I believe ObjectAda is correct on this one -- but the reasons are rather obscure. By the way, the contents of the package RGB_Value are irrelevant here. Here's a simpler example: package RGBColor is type Color_Type is ( Gray0, Gray1 ); Grey0 : Color_Type renames Gray0; Grey1 : Color_Type renames Gray1; end RGBColor; By RM95-8.5.1(4), the renamed entity in an object renaming must be an object. By RM95-3.5.1(6), an enumeration literal specification declares a parameterless function, so an occurrence of an enumeration literal in an expression is a function call. This rule may seem strange; it's defined that way so that enumeration literals can be overloaded in the same manner as functions. In practice, you can be sure that enumeration literals will not be implemented as actual function calls. By RM95-6.4(12) and 6.5(21), a function call denotes a (constant) object. (This rule is new to Ada 95.) So, it is legal in Ada 95 (but illegal in Ada 83) to use an object renaming declaration to rename an enumeration literal. However, the more traditional way to rename an enumeration literal is as a function: package RGBColor is type Color_Type is ( Gray0, Gray1 ); function Grey0 return Color_Type renames Gray0; function Grey1 return Color_Type renames Gray1; end RGBColor; Or, if you aren't worried about overloading, just declare some constants: package RGBColor is type Color_Type is ( Gray0, Gray1 ); Grey0 : constant Color_Type := Gray0; Grey1 : constant Color_Type := Gray1; end RGBColor; -- Keith Thompson (The_Other_Keith) kst@sd.aonix.com <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 5040 Shoreham Place, San Diego, CA, USA, 92122-5989 "Zathras warn Zathras, but Zathras never listen to Zathras." -- Zathras