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 X-Received: by 2002:a6b:4e0b:: with SMTP id c11-v6mr3897557iob.22.1532790114234; Sat, 28 Jul 2018 08:01:54 -0700 (PDT) X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr201629oif.2.1532790113530; Sat, 28 Jul 2018 08:01:53 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no2812320itj.0!news-out.google.com!l67-v6ni2058itl.0!nntp.google.com!d7-v6no2812316itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 28 Jul 2018 08:01:53 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <72ccb7fa-a9cb-42e6-8c29-3c06da281a45@googlegroups.com> <2212eb54-cb4a-446f-9cdf-287ef220e2c2@googlegroups.com> <1b5a58b2-65b7-4df8-80b5-03e208d249e1@googlegroups.com> <99a9127d-1024-4690-aa1d-8b3026a0f57d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada Distilled by Richard Riehle From: "Dan'l Miller" Injection-Date: Sat, 28 Jul 2018 15:01:54 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54000 Date: 2018-07-28T08:01:53-07:00 List-Id: On Saturday, July 28, 2018 at 2:10:07 AM UTC-5, Dmitry A. Kazakov wrote: > On 2018-07-28 04:41, Dan'l Miller wrote: > > On Friday, July 27, 2018 at 4:32:52 PM UTC-5, Dmitry A. Kazakov wrote: > >> On 2018-07-27 22:38, Dan'l Miller wrote: > >>> On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote= : > >>>> - full MD > >>> > >>> Full multiple dispatch was added experimentally back in the day for A= da as part of the Ada9X exploratory contracts, by SRI iIRC. > >> > >> MD is a difficult problem with regard to separate compilation. I don't > >> know how to solve it in a consistent way. > >> > >> But the language design goal should be that any operation declared > >> publicly must have all arguments and results controlling or class-wide= . > >> No contravariance. No type-specific operations. > >=20 > > http://www.stroustrup.com/multimethods.pdf > > Above is an interesting research report (and survey of the 2007 then-st= ate of the art) from C++world on this topic of how to efficiently implement= openmultimethods. (Ada95 fortunately chose a variant of open methods for = the syntax of single-dispatch, which should extend quite nicely to openmult= imethod syntax, whereas C++ with openmultimethod feature would need to graf= t on a foreign-language-feeling Ada95-esque syntax.) >=20 > Yes, Ada's OO model is the only correct one, IMO. >=20 > The concept of operations nested class type declaration is evident=20 > garbage in the light of MD. >=20 > > Cutting to the chase scene: > > A) they seem to drop breadcrumbs per compilation-unit that are then sti= tched together in the linker to then author the (dense?) multidimensional = array in one fell swoop, > > instead of > > B) each compilation-unit contributing its portion fully-formed in situ = in the one multidimensional dispatch array. > >=20 > > I am not understanding how the Chinese-remaindering alternative design = is better in =E2=80=A2any=E2=80=A2 metric at all (e.g., smaller memory foot= print? but why the N/A in the table in =C2=A77.2?), unless their multidimen= sional dispatch array was sparse (for no good reason) instead of dense. >=20 > Before considering aspects of linking dispatching tables, the problem to= =20 > resolve is guaranteeing completeness of the table. Considering: >=20 > package MD is > type T1 is ...; > type S1 is ...; > procedure Doubly (X : T1; Y : S1); > end MD; >=20 > package P is > type T2 is new T1; > overriding procedure Doubly (X : T2; Y : S1); > end P; >=20 > package Q is > type S2 is new S1; > overriding procedure Doubly (X : T1; Y : S2); > end P; >=20 > Where is >=20 > overriding procedure Doubly (X : T2; Y : S2); >=20 > How to statically ensure its appearance, when lexically (clearly it must= =20 > be done before linking), where (visibility issue S2 must know nothing=20 > about T2 and conversely)? Don't get stuck in an Ada95 syntactic structure; think a little in PL/I or = in Algol68. You are gratuitously insisting on placing the multimethods nea= r the Ada95-era (singly-dispatched) method syntax. Scattering the multimet= hods among T1, S1, T2, and S2 is what is called =E2=80=A2multimethods=E2=80= =A2=E2=80=94and what is causing your unnecessary conundrum. Divorcing thei= r placement so that they are no longer juxtapositioned with T1, S2, T2, and= S2 is called =E2=80=A2openmultimethods=E2=80=A2; the movement of all the m= ultimethods to a confederation-of-multidispatching package away from the pa= ckages that contain the singly-dispatched methods is what is meant by the = =E2=80=9Copen=E2=80=9D there. The answer is effectively already in Holzm=C3=BCller's & Pl=C3=B6dereder's = work (and crudely 5 decades ago in PL/I), although I change the /overriding= / openmultimethod syntax to better visually correspond to your example (tha= n to Holzm=C3=BCller's & Pl=C3=B6dereder's syntax) and to call to mind the = PL/I GENERIC-esqueness of it all: package MD is type T1 is ...; type S1 is ...; procedure SinglyT (A: T1); -- not participating in multimethod type-co= ndeferation procedure SinglyS (A: S1); -- not participating in multimethod type-co= ndeferation end MD; package P is type T2 is new T1; overriding procedure SinglyT (A: T2); -- not participating in multimet= hod type-condeferation end P; package Q is type S2 is new S1; overriding procedure SinglyS (Y : S2); -- not participating in multime= thod type-condeferation end P; -- =C3=A0 la a blend of GENERIC in PL/I with UNION in Algol68 with OO dispa= tching package TypeConfederationForMD is type UT is union (T1, T2); -- Algol68 UNION-esque type US is union (S1, S2); -- Algol68 UNION-esque procedure Doubly (X : UT; Y : US); -- PL/I GENERIC-e= sque overriding procedure Doubly (X : T1; Y : S1); -- PL/I GENERIC-esque overriding procedure Doubly (X : T1; Y : S2); -- PL/I GENERIC-esque overriding procedure Doubly (X : T2; Y : S2); -- PL/I GENERIC-esque end U; Q.E.D. Btw, because T2 is an extended tagged T1 and because S2 is an extended tagg= ed S1, I think an alternate syntax would be expressive and useful for this = special case as well instead of the explicitly-itemized same-named variants= above. Note however that (just like in PL/I GENERIC) union can confederat= e any types, not merely tagged types and not merely tagged-type extensions = in a 'Class tree. type UT is union (T1'Class); -- a blend of Algol68 UNION and Ada95 = 'Class type US is union (S1'Class); -- a blend of Algol68 UNION and Ada95 = 'Class