Re: Ada Distilled by Richard Riehle

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

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)?

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