Re: Ada Distilled by Richard Riehle

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-07-28 17:01, Dan'l Miller wrote:
> 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.

Two language design failures, one that reached production code, another 
that luckily never did?

> You are gratuitously insisting on placing the multimethods near the Ada95-era (singly-dispatched) method syntax.

? Ada's syntax is naturally multiply dispatching. There is no 
syntactically preferable argument or result.

> Scattering the multimethods among T1, S1, T2, and S2 is what is called •multimethods•—and what is causing your unnecessary conundrum.

Actually it is full multiple dispatch: several controlling arguments 
from different type hierarchies, e.g. Print (Surface, Text)

Mutimethod traditionally is a narrower case when all controlling 
arguments are from one hierarchy, e.g. arithmetic operations: Left + Right.

> 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.

Ada 95 never had methods nested in type declaration. (Ada 83 did this 
error for protected objects and tasks, but the lesson was learned)

> 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.

This is a non-starter because sets of types (classes) must be open. All 
real-life cases for MD are when types to be added to the existing 
classes. Late bindings support is a KO criterion.

Otherwise, if you let expansion of your sets, you will run into exactly 
same problem I described. It is *not* a syntactic problem.

> 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

That does not make sense because T1'Class is a singular type. For the 
set of types rooted in T1 there is no name in Ada, since it does not 
have types of types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de