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.68.241.98 with SMTP id wh2mr1570058pbc.7.1336458617798; Mon, 07 May 2012 23:30:17 -0700 (PDT) Path: pr3ni1396pbb.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 09:30:15 +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 S8MbkNsxzX6+xx+kKxNpTQplyAiacwpk3iGBXnzqxyuyNBKUaGyGO+ovQwS4gyn9hk Cancel-Lock: sha1:SD3v6xnA3C+6nRjaVHKigMQ+860= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-08T09:30:15+03:00 List-Id: On 12-05-08 03:48 , Randy Brukardt wrote: > "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. Maybe it wasn't clear, but anything I've said about the representation of the "deepened" derived enumeration types has been intended as an example of how it could be done, to help machine-oriented readers understand how the types work. I don't really care about the representation. > That's an age-old Ada requirement (found in 13.4(8)). So, "deepened" enumeration types are a new thing; new rules for new things. > 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). This is a side track, but I don't see any compelling reason (except compatibility) to define a standard default representation for enumeration types. There is no standard representation for Booleans, integer types, floats, records; why should enumeration types have one? (Is it a remnant of a C-style identification of enumerations with integers?) Decades ago I liked to specify my own enumeration representations, but I would think three times before doing it today. It is only useful for unchecked conversions and I/O. If you use it for input, you have to mess about with 'Valid or exceptions. For output, there are always other important considerations like memory access width and byte ordering. I much prefer to use my own code or tables for converting between known external representations and unknown internal representations. This also avoids the rule about keeping the same order of the literals and the representation values. > ... >>> 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 I should have said "*could* be represented by...". >> 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, In current Ada, yes. > which can be specified by the user. Sure. I was giving an example of a possible default representation (if not by position number). > 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. That would be ok for me. The parent-bits/extension-bits representation is only an example of an alternative representation that makes the conversion from the derived type to the parent type fast (right-shift to discard the extension bits). (And it is analogous to the way tagged record types are extended by adding new components.) > 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). You could continue using this method for the "deepened" enumeration types, whatever representation you choose to use for them, or the user specifies for them. The only new thing that the "deepened" enumeration type needs is a compiler-provided conversion to the parent type. The parent-bits/extension-bits representation would make that fast, but you could also use a simple table, indexed by the derived type (= position number), with elements of the parent type. > ... it's almost certain that > implementations would use the same mechanism for this (why invent a third > mechanism for something rarely used?). Sure, implementations could do that. And it seems to me that supporting user-specified enumeration representations for "deepened" enumeration types would not require any new compiler mechanisms. > It seemed like a useful idea back in the day, I think that extending enumeration types by "deepening" is a different idea than the AI95-261 "widening" idea. Don't you think that they are logically different? > but to be really useful, we > need the equivalent of class-wide operations. That is the main question: do we? > I don't see how to do that if > the position numbers are completely different between the various types. I agree. It seems to me that adding class-wide operations would force to use some kind of tags, call by reference, and view conversions, and then it becomes so similar to tagged types that it is not worth it. I think the idea of "deepened" enumeration types is worth pursuing only if it is useful without class-wide operations. Another issue is that generic formal types of the "deepened" kind would be needed. I think that would be the next point to work on for this proposal. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .