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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada Successor Language Date: Tue, 26 Jun 2018 23:09:33 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t7u1cfm.fsf@nightsong.com> <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com> <87602fbu2g.fsf@nightsong.com> <87po0mziqt.fsf@nightsong.com> <87fu1izfgs.fsf@nightsong.com> <878t75nwad.fsf@adaheads.home> NNTP-Posting-Host: 3CrKQyqWAJZHy6zYVP/kUg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:53354 Date: 2018-06-26T23:09:33+02:00 List-Id: On 2018-06-26 22:49, Niklas Holsti wrote: > On 18-06-26 23:16 , J-P. Rosen wrote: >> Le 25/06/2018 à 16:03, Niklas Holsti a écrit : >>> So it says in RM 3.4(5/2), but even the Annotated RM has no motivation >>> for it, and I don't see why Ada could not assume a null extension when >>> the type is tagged. Can someone explain why the RM is so strict on this? >>> >>> (In fact, it seems to me that Ada could allow untagged record extensions >>> as well; the effect would be the same as for tagged ones, but no 'Class >>> would be formed, and no class-wide programming or dynamic dispatch could >>> be used, so all such types would be static. It would be semantically >>> equivalent to aggregation of a component of the parent type with the >>> extension components, but would allow direct access to the inherited >>> components from the parent type. This could be a useful separation of >>> extensions from tags.) >> You can achieve exactly this with a tagged type and Restriction >> (No_Dispatch) > > Not exactly that, no: you would still have to declare the types as > tagged, and the objects of these types would still have to store the tag > value somewhere, at least for use when X'Tag is taken for a controlling > parameter X of an inherited (non-overridden) operation. > > Moreover, Restriction (No_Dispatch) is partition-wide (or so I believe, > because "tailored" run-time systems are mentioned in that part of the > RM, H.4). Thus it would not let one use both tagged record extensions > and untagged record extensions in the same program partition. > > In fact the only similarity I can see between Restriction (No_Dispatch) > and the suggested extensibility of non-tagged records is that the latter > (as I suggested it) would also not allow dispatching -- but preventing > dispatch was not the point of the suggestion. > > Combining extension of untagged records with Dmitry's suggestion for > untagged class-wide types would allow dispatch (but not re-dispatch) for > such extensions, which IMO shows that Restriction (No_Dispatch) is > independent of untagged record extensions. Furthermore, it must not be limited to only record types or only extensions. Since by-reference semantics and view conversions do not hold for non-tagged types anyway, we could allow representation overriding as an alternative to representation extension. With representation overriding the derived type must provide value conversions used for inherited operations. The parent type's value is no longer a part of the descendant's value. That will give us extending and shrinking enumeration types, making Unbounded_String a descendant of String and much more. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de