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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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.204.152.217 with SMTP id h25mr1985578bkw.3.1336430070565; Mon, 07 May 2012 15:34:30 -0700 (PDT) Path: h15ni210692bkw.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Tue, 08 May 2012 01:34:28 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> Mime-Version: 1.0 X-Trace: individual.net 5uBK4kYWc2oKubriwaemJwT/R8TT/8G1Th/iJLw0PzMMAgEBJBIpvV8jG5TQvNGGrL Cancel-Lock: sha1:Nwn0w9wnL3PP4o4kUP7I13wHX0A= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-08T01:34:28+03:00 List-Id: 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. > 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 . @ .