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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,799bdb14b530ce1d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.70.131 with SMTP id d3mr8630852qaj.0.1349492887007; Fri, 05 Oct 2012 20:08:07 -0700 (PDT) Received: by 10.236.35.229 with SMTP id u65mr1300626yha.16.1349492886976; Fri, 05 Oct 2012 20:08:06 -0700 (PDT) Path: e10ni211270746qan.0!nntp.google.com!l8no27487903qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 5 Oct 2012 20:08:06 -0700 (PDT) In-Reply-To: <0135d0d3-3dd3-4b75-a639-76cf93975eb2@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.4.246.214; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 68.4.246.214 References: <99b6ed38-0a44-4649-82b7-0b724fa5e68f@googlegroups.com> <5e6b8e61-50c5-4398-9407-60276a070f4f@googlegroups.com> <0135d0d3-3dd3-4b75-a639-76cf93975eb2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <84ec72b1-bf3e-4f62-a777-00692fbdd7f9@googlegroups.com> Subject: Re: Odd subtyping error. From: Adam Beneschan Injection-Date: Sat, 06 Oct 2012 03:08:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-10-05T20:08:06-07:00 List-Id: On Friday, October 5, 2012 3:19:57 PM UTC-7, Shark8 wrote: > On Friday, October 5, 2012 4:11:06 PM UTC-6, Adam Beneschan wrote: >=20 > >=20 >=20 > > Ah, "the rest of the story"! The size clause isn't the problem. The p= roblem is that referring to Item_2 and Item_4 in the declaration of Derived= _Type freezes Base_Type, and you can't add any more representation informat= ion after that. That makes "For Base_Type Use ..." illegal. If the error = messages in your original case pointed you to the wrong line numbers, that'= s something you can complain to the GNAT folks about. But the error is leg= itimate, at least in your reduced source. >=20 >=20 >=20 > Hm, why does it force freezing? If you're looking for the rule that says this, it's 13.14(8). If you're lo= oking for the reason: When you declare the enumeration type, the values of the type are provision= ally given the representations 0, 1, 2, ... i.e. in your example Item_1=3D= 0, Item_2=3D1, etc. Those will be the defaults if there is no other repres= entation clause. When you *use* one of the enumeration literals, though, t= hen depending on what you use it for, the compiler could have to generate c= ode to use the correct representation, e.g. it may have to generate code to= put Item_2 into a variable(or a word in a data section in the executable),= pass it to a function, or do something else with it. Therefore, at that p= oint, the representation has to have been determined, so that the compiler = knows what value to store or load or whatever. It could turn out (as in yo= ur small example) that the compiler doesn't actually have to do anything wi= th the value. But the language has to have rules to make sure things work = right when the value *is* needed, and writing relatively simple rules that = may make things a little more restrictive than necessary is preferred over = writing overly complex rules to try to get every case perfect, or leaving t= he rules so vague that the program isn't portable. You might be thinking, "well, why doesn't the compiler just look ahead in t= he source and find the representation clause?" All I can say is, this isn'= t in line with Ada's design philosophy, which is to design the language so = that it can be compiled with one scan through the code. I'm not exactly su= re why this philosophy was adopted. Efficiency was probably one reason. B= ut another advantage, I think, is that it eliminates the possibility of mut= ual dependencies that could come up if you were allowed to write code that = the compiler couldn't handle without looking ahead.=20 =20 > Is there a way to force defferment, or flag that there will be a represen= tation-clause, maybe with an aspect clause " with Representation, Size =3D>= Enum'Size" No, I don't think so. I think you'll have to move the representation clause out of the private pa= rt. This shouldn't have any impact, except on readability (which I acknowl= edge is important); but as far as I know, there is no case where the legali= ty or semantics of a program *using* your package is affected by whether an= enumeration representation clause is in the visible or private part. -- Adam