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: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.191.225 with SMTP id hb1mr836394pbc.5.1336438091175; Mon, 07 May 2012 17:48:11 -0700 (PDT) MIME-Version: 1.0 Path: pr3ni489pbb.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Mon, 7 May 2012 19:48:05 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1336438089 27595 69.95.181.76 (8 May 2012 00:48:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 8 May 2012 00:48:09 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-05-07T19:48:05-05:00 List-Id: "Niklas Holsti" wrote in message news:a0r0vkFb94U1@mid.individual.net... > 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. But the representation of an enumeration type is its position number, unless otherwise specified. That's an age-old Ada requirement (found in 13.4(8)). I suppose you could drop it, but then a complete replacement would have to be defined and that would be complex (and less than useful). ... >> 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.) This makes no sense, since enumerations have well-defined representations, which can be specified by the user. And it provides no value that I can see, since a compiler is going to have to support conversions to/from these enumerations that have user-defined representations anyway. So the only way to do the conversions is is with a lookup table. Moreover, I can't speak for other compilers, but Janus/Ada uses the position number for all operations; the only use of the representation is to read/store from memory. So the representation is completely irrelevant for implementing operations. (We wouldn't even need to enforce the representation ordering rules, but of course we do because they're required by the language.) We couldn't find any reasonable way to support operations like indexing and looping and still support arbitrary representations with missing values (holes if you will). >> And it's unclear about representation of "array (Detailed_Message_Kind) >> of ...". Arrays in Ada should not have holes, so the representation would surely not change. > 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, This isn't happening, because of the need to support user-specified representations. That's not "fast", and it's almost certain that implementations would use the same mechanism for this (why invent a third mechanism for something rarely used?). ... >> However, I too want to use this extensible enum if you have a nice >> solution. > > Two votes in favour, interesting! It seemed like a useful idea back in the day, but to be really useful, we need the equivalent of class-wide operations. I don't see how to do that if the position numbers are completely different between the various types. So I'm dubious, but we have a long time before any of this is going to be adopted, so perhaps improvements can be made. Randy.