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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.241.98 with SMTP id wh2mr1209777pbc.7.1336632404642; Wed, 09 May 2012 23:46:44 -0700 (PDT) Path: pr3ni8998pbb.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: ytomino Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Wed, 9 May 2012 23:45:21 -0700 (PDT) Organization: http://groups.google.com Message-ID: <12977134.804.1336632321128.JavaMail.geo-discussion-forums@pbuy6> References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> NNTP-Posting-Host: 118.8.128.51 Mime-Version: 1.0 X-Trace: posting.google.com 1336632404 31649 127.0.0.1 (10 May 2012 06:46:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 10 May 2012 06:46:44 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=118.8.128.51; posting-account=Mi71UQoAAACnFhXo1NVxPlurinchtkIj User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-05-09T23:45:21-07:00 List-Id: On Tuesday, May 8, 2012 7:34:28 AM UTC+9, Niklas Holsti wrote: > On 12-05-07 09:33 , ytomino wrote: > > It's interesting. > > > > What would happen to 'Pos and 'Val ? > > They would work in the normal way for enumeration types, just as if the > parent type and the derived type were declared separately, without > derivation. > > >> type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off); > >> type Detailed_Message_Kind is new Message_Kind1 with ( > >> Request => (Read, Write), > >> Reply => (Data, Ack, Refused), > >> others => <>); > > > > First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off = 4, of course. > > That should be 0, 1, 2, and 3. 'Pos starts from zero. Oops. > > > 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 (float!) > > No, I would make the 'Pos values for Detailed_Message_Kind be the normal > ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is > 0, for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is > 4, for Refused it is 5, and for Sign_Off it is 6. > > I don't see any reason to keep the same position number for the "same" > literal of Message_Kind1 and of Detailed_Message_Kind. Although the > literals have the same identifier, they are not the same value. > > That is, Message_Kind1'(Sign_On) is not the same value as > Detailed_Message_Kind'(Sign_On), although the latter can be converted to > the former (and perhaps vice versa). > > Moreover, neither the parent type nor the derived type is a subtype > (subrange) of the other type, in the Ada sense. > > > It seems difficult to realize keeping operator "<",">" and keeping > > Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time. > > The code for the relational operators "<" and ">" would use the > representation, not the position number. I suggested that values of the > derived type would be represented by some "parent" bits that represent a > value of the parent type, and some more "extension bits" to separate the > refining literals from each other. If these bits are packed in a word, > with the extension bits less significant than the parent bits, ordinary > integer comparison instructions can implement "<" and ">" for the > derived type. (This is just like lexicographic ordering.) > > > And it's unclear about representation of "array (Detailed_Message_Kind) of ...". > > The array index would be the position number, as usual. The position > number can be computed from the representation with parent bits and > extension bits. To make this computation fast, the compiler could use a > constant array "first_pos" that is indexed by the parent bits (that is, > by the parent enumerated type) and gives the position number of the > first derived-type literal that is refined from this parent-type value. > The position number of any value of the derived type is then computed as > first_pos(parent bits) + (extension bits). > > In the example, first_pos(Message_Kind1'(Sign_On)) would be 0, for > Request it would be 1, for Reply it would be 3, and for > Message_Kind1'(Sign_Off) it would be 6. > > The value Detailed_Message_Kind'(Ack) would be represented by the parent > bits 2#10#, representing Reply, and the extension bits 2#01#, to show > that Ack is the second literal refining Reply. The position number is > computed as first_pos(Reply) + 1 = 3 + 1 = 4. > > Each derived type needs its own "first_pos" array, of course. > > > However, I too want to use this extensible enum if you have a nice solution. > > Two votes in favour, interesting! > > -- > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > . @ . Thank you for the answer. Although negative opinions is also seen, I think it's nice. For myself check... type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off); -- Sign_On = 0 -- Request = 1 -- Reply = 2 -- Sign_Off = 3 type Detailed_Message_Kind is new Message_Kind1 with ( Request => (Read, Write), Reply => (Data, Ack, Refused), others => <>); (when the offset is 4 bit) -- Sign_On = 16#00# -- Read = 16#10# -- Write = 16#11# -- Data = 16#20# -- Ack = 16#21# -- Refused = 16#22# -- Sign_Off = 16#30# X'Pos = first_pos (X'Enum_Rep / 16) + (X'Enum_Rep mod 16) type More_Detailed_Message_Kind is new Detailed_Message_Kind with ( Write => (Overwrite, Append), others => <>); -- Sign_On = 16#000# -- Read = 16#100# -- Overwrite = 16#110# -- Append = 16#111# -- Data = 16#200# -- Ack = 16#210# -- Refused = 16#220# -- Sign_Off = 16#300# Y'Pos = More_Detailed_Message_Kind'first_pos ( Detailed_Message_Kind'first_pos (Y'Enum_Rep / 256) + (Y'Enum_Rep mod 256 / 16)) + (Y'Enum_Rep mod 16) Is it OK? It's interesting. I feel that you do not need to change the existing representation rule. Because even if Message_Kind1 has the representation clause, it's unrelated to Detailed_Message_Kind. It's able to keep the existing rule of root enum-types. And the representation of Detailed_Message_Kind is new thing, such as your saying. (I'm only interested, not a language lawyer. I'm sorry that I couldn't help you in this discussion.)