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 wh2mr421085pbc.7.1336432710185; Mon, 07 May 2012 16:18:30 -0700 (PDT) Path: pr3ni247pbb.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 02:18:28 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net P4w0X4cltXufTUrXOIkM+wmo/gjT0MUiZ/2Rb2ivujuwPo2v2Ghi524ZkkKzMFCDuQ Cancel-Lock: sha1:DeMQtHMklfMYzxP9Gg5neP6O1Yg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-08T02:18:28+03:00 List-Id: On 12-05-07 10:49 , Dmitry A. Kazakov wrote: > On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote: > >> On 12-05-06 22:28 , Dmitry A. Kazakov wrote: >>> >>> 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. > > What are you going to do with user-defined operations? As distinct from what? Predefined operations? Why should there be any difference? > In the model (1) where the derived type is a subtype (in Ada sense) I'm afraid I don't understand, sorry. Are you talking about Ada "subtype" declarations? They are not "derived types" in the Ada sense. My suggestion for derived enumeration types that extend the parent type (by "deepening") would create derived types (in the Ada sense), not subtypes (in the Ada sense). Thus any user-defined (primitive) operations for the parent type (except those with "out" parameters of that type, as already discussed) would be inherited (redeclared) for the derived type and implemented with automatic conversion of "in" parameters. > they > get automatically inherited in any context where visible. [This in effect > makes you exposed to "class-wide" programming with subtypes even if you > don't want to. All subtypes of a type form a class with ad-hoc operations > gathered from all members, when visible.] Could you give an example, preferably using the types Message_Kind1 and Detailed_Message_Kind? > In the tagged model (2) the derived type is independent and any specific > operations of the parent are dropped. Ditto, example please, in this context? > (I guess that difficulties with enumeration extension proposals stem from > attempts to force it under the model #1) Could be - some discussion in AI95-261 suggests a new reserved word "supertype", the reverse of "subtype" - but the main text of the AI uses "type .. is new ..", making a derived type and not a subtype (both words in the Ada sense). >>> 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. > > Yes. More general constructs have more power, which needs to be carefully > constrained in order to keep the language safe. C and PL/1 give us examples > of the damage type conversions may inflict. Especially *implicit* type conversions. Vide C++ ... it is interesting to see that even there, forcing explicit conversion is gaining favour. >> It is even more difficult for Ada >> because of the compatibility requirements. > > On the contrary, it is rather specific extensions which likely are to > become incompatible. Generalizations are less problematic, you simply > define old constructs in new terms. If possible! I fear that the "old constructs" in Ada each have their own small, thorny features, carefully defined, for example to avoid specific kinds of distributed overhead, or to spare some implementor from having to make major changes in his/her compiler. While one could likely make a good approximation of the old features by combining new, fundamental primitives, getting all these small details exactly right would be difficult, and failing there would break compatibility. However, it would be nice to see this attempted, sooner or later, and perhaps the incompatibility could be tolerated. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .