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.223.40 with SMTP id qr8mr11220562pbc.0.1336339614045; Sun, 06 May 2012 14:26:54 -0700 (PDT) Path: pr3ni11974pbb.0!nntp.google.com!news2.google.com!news4.google.com!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: Mon, 07 May 2012 00:26:52 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net Z7GTtXxbrHgl0WTp9SPdWAaT6ySQEylvZyAskIS/9GAJ0zTBvjkNXg9Tg8BgJT72mz Cancel-Lock: sha1:e7F2vP8dXifSn7508m4YfqocjEE= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-07T00:26:52+03:00 List-Id: On 12-05-06 22:28 , Dmitry A. Kazakov wrote: > On Sun, 06 May 2012 21:48:00 +0300, Niklas Holsti wrote: > >> On 12-04-25 10:47 , Martin wrote: >>> Ok, we don't officially have Ada2012 yet but as no new features are >>> going to be added to it, now seems like a good time to start thinking >>> about the next revision. >> >> There is a proposal for extensible enumerated types, AI95-261 >> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00261.txt), that was >> rejected (and I don't much like it, either). While reading John Barnes' >> second part of "Rationale for Ada 2012" in Ada User Journal, for some >> reason an idea came to me of a different and perhaps better concept of >> extension for enumerated types. I'm not sure that this would be a >> worth-while addition to Ada, but here it is, for your pleasure or >> displeasure, as briefly as I could write it. >> >> The new concept can be describes as "extending enumerated types by >> deepening", where the AI95-261 concept is "extending by widening". >> >> The terms "deepening" and "widening" come from seeing an enumerated type >> as a classification of some set of things. For example, the messages >> exhanged in some protocol could be classified in this way, initially and >> roughly: >> >> type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off); >> >> and some general operations might be written using only this rough >> classification. AI95-261 proposed the ability to derive a "wider" type >> with more literals, as in: >> >> type Wider_Message_Kind1 is new Message_Kind1 with (Tick, Ping); >> >> The main problem with this extension by widening is that the derived >> type, Wider_Message_Kind1, is not a "subclass" of the parent type, >> because some values of the derived type (the new literals) cannot be >> converted to (or viewed as) values of the parent type. The derived type >> can't inherit operations from the parent type, because those operations >> can't handle the added values. > > That depends on the operations. Extension is safe with out-operations. Yes, you are right. In extension by widening, the parent type is a "subtype" (a subrange, really) of the derived type, so any value of the parent type is also a value of the derived type, and "out" works when inherited. But "in" (which I tend to think of as the usual role) has problems. > >> AI95-261 suggests to raise >> Constraint_Error in such cases. Note how this differs from derived >> tagged types. > > Yes, for tagged types operations which are unsafe to inherit are inherited > abstract, e.g. functions returning covariant value. The same could be done also for extension by deepening, but it is not needed, as long as we don't introduce tags and class-wide programming for these types. Inheriting these operations as abstract could even be inconvenient, since it would force the program to implement (override) the operations even when they are not needed. >> In "extension by deepening", the classification is not widened by adding >> more literals "at the end", but is deepened, or refined, by dividing >> some or all of the parent literals into a set of new literals, to give a >> more detailed classification. >> >> In the protocol example, we can distinguish different kinds of Request: >> a read request or a write request, and different kinds of Reply: some >> data (in reply to a read request), an ack (in reply to a write request), >> or a refusal (in reply to any invalid request). The derivation syntax >> could be like this: >> >> type Detailed_Message_Kind is new Message_Kind1 with ( >> Request => (Read, Write), >> Reply => (Data, Ack, Refused), >> others => <>); > > [...] >> What do you think? > > This looks like plain interface inheritance. You inherit the interface (the > literals of the type) dropping the implementation (encoding). Not quite, because the derived type does not inherit the literals that are refined. Detailed_Message_Kind does not have the literals Request and Reply, because they have been refined into the literals Read and Write, and into the literals Data, Ack, and Refused, respectively. If the derived type refines all the parent-type literals, the parent and derived types have no literals in common. As for the representation, my intent was that it would be inherited, but extended with some more bits ("less significant" bits, in a way). So yes, the representation would be changed in some ways. > Parent's > operations are inherited per composition with a type conversion. Yep. > I always wished to have this mechanism in Ada. Note that instead of > inventing some complicated syntax which purpose is basically to generate > conversion functions (four conversions are needed in most general case), > you should just allow the programmer to define them by himself. There is a trade-off. Using syntax constrains the kinds of conversions the programmer can use, which may help compilation and code generation. Programmer-defined unrestricted conversion functions could become too complex for efficient compilation. > My opinion is that the language should provide very few fundamental > primitives rather than a forest of special cases. I agree, in theory. In practice, it is difficult, even if you could define a language from scratch. It is even more difficult for Ada because of the compatibility requirements. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .