Re: Ada Distilled by Richard Riehle

["Dan'l Miller" <optikos@verizon.net>]

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 Ada 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.
> > 
> > http://www.stroustrup.com/multimethods.pdf
> > Above is an interesting research report (and survey of the 2007 then-state 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 openmultimethod syntax, whereas C++ with openmultimethod feature would need to graft on a foreign-language-feeling Ada95-esque syntax.)
> 
> Yes, Ada's OO model is the only correct one, IMO.
> 
> The concept of operations nested class type declaration is evident 
> garbage in the light of MD.
> 
> > Cutting to the chase scene:
> > A) they seem to drop breadcrumbs per compilation-unit that are then stitched 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.
> > 
> > I am not understanding how the Chinese-remaindering alternative design is better in •any• metric at all (e.g., smaller memory footprint? but why the N/A in the table in §7.2?), unless their multidimensional dispatch array was sparse (for no good reason) instead of dense.
> 
> Before considering aspects of linking dispatching tables, the problem to 
> resolve is guaranteeing completeness of the table. Considering:
> 
>     package MD is
>        type T1 is ...;
>        type S1 is ...;
>        procedure Doubly (X : T1; Y : S1);
>     end MD;
> 
>     package P is
>        type T2 is new T1;
>        overriding procedure Doubly (X : T2; Y : S1);
>     end P;
> 
>     package Q is
>        type S2 is new S1;
>        overriding procedure Doubly (X : T1; Y : S2);
>     end P;
> 
> Where is
> 
>     overriding procedure Doubly (X : T2; Y : S2);
> 
> How to statically ensure its appearance, when lexically (clearly it must 
> be done before linking), where (visibility issue S2 must know nothing 
> 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 near the Ada95-era (singly-dispatched) method syntax.  Scattering the multimethods among T1, S1, T2, and S2 is what is called •multimethods•—and what is causing your unnecessary conundrum.  Divorcing their placement so that they are no longer juxtapositioned with T1, S2, T2, and S2 is called •openmultimethods•; the movement of all the multimethods to a confederation-of-multidispatching package away from the packages that contain the singly-dispatched methods is what is meant by the “open” there.

The answer is effectively already in Holzmüller's & Plödereder's work (and crudely 5 decades ago in PL/I), although I change the /overriding/ openmultimethod syntax to better visually correspond to your example (than to Holzmüller's & Plödereder'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-condeferation
    procedure SinglyS (A: S1);  -- not participating in multimethod type-condeferation
end MD;

package P is
    type T2 is new T1;
    overriding procedure SinglyT (A: T2);  -- not participating in multimethod type-condeferation
end P;

package Q is
    type S2 is new S1;
    overriding procedure SinglyS (Y : S2);  -- not participating in multimethod type-condeferation
end P;

-- à la a blend of GENERIC in PL/I with UNION in Algol68 with OO dispatching
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-esque
    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 tagged 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 confederate 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