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:c542:: with SMTP id
 v63-v6mr3261796iof.18.1532745682565;
        Fri, 27 Jul 2018 19:41:22 -0700 (PDT)
X-Received: by 2002:aca:75c9:: with SMTP id
 q192-v6mr174188oic.3.1532745682349;
 Fri, 27 Jul 2018 19:41:22 -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!g2-v6no2370320itf.0!news-out.google.com!l67-v6ni1515itl.0!nntp.google.com!d7-v6no2350981itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 27 Jul 2018 19:41:22 -0700 (PDT)
In-Reply-To: <pjg320$tfe$1@gioia.aioe.org>
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: <c65ea05a-492c-4941-abab-0416ea64ffee@googlegroups.com>
 <72ccb7fa-a9cb-42e6-8c29-3c06da281a45@googlegroups.com>
 <piuij8$n89$1@franka.jacob-sparre.dk>
 <2212eb54-cb4a-446f-9cdf-287ef220e2c2@googlegroups.com>
 <d0e88613-df8a-4d04-b76e-b2c68d3ba735@googlegroups.com>
 <cfcf8cc1-9d9d-41e2-9b93-cf0449646b6a@googlegroups.com>
 <b5a81608-da11-4253-b2a9-d4f50a531844@googlegroups.com>
 <1b5a58b2-65b7-4df8-80b5-03e208d249e1@googlegroups.com>
 <pjfu1l$lmn$1@gioia.aioe.org>
 <99a9127d-1024-4690-aa1d-8b3026a0f57d@googlegroups.com>
 <pjg320$tfe$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d77e1e0a-ce27-4cb3-a83f-fa5b962cb1b7@googlegroups.com>
Subject: Re: Ada Distilled by Richard Riehle
From: "Dan'l Miller" <optikos@verizon.net>
Injection-Date: Sat, 28 Jul 2018 02:41:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org comp.lang.ada:53995
Date: 2018-07-27T19:41:22-07:00
List-Id: <comp.lang.ada>

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
> >=20
> > Full multiple dispatch was added experimentally back in the day for Ada=
 as part of the Ada9X exploratory contracts, by SRI iIRC.
>=20
> MD is a difficult problem with regard to separate compilation. I don't=20
> know how to solve it in a consistent way.
>=20
> But the language design goal should be that any operation declared=20
> publicly must have all arguments and results controlling or class-wide.=
=20
> 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 ope=
nmultimethods.  (Ada95 fortunately chose a variant of open methods for the =
syntax of single-dispatch, which should extend quite nicely to openmultimet=
hod syntax, whereas C++ with openmultimethod feature would need to graft on=
 a foreign-language-feeling Ada95-esque syntax.)

Cutting to the chase scene:
A) they seem to drop breadcrumbs per compilation-unit that are then stitche=
d together  in the linker to then author the (dense?) multidimensional arra=
y in one fell swoop,
instead of
B) each compilation-unit contributing its portion fully-formed in situ in t=
he one multidimensional dispatch array.

I am not understanding how the Chinese-remaindering alternative design is b=
etter in =E2=80=A2any=E2=80=A2 metric at all (e.g., smaller memory footprin=
t? but why the N/A in the table in =C2=A77.2?), unless their multidimension=
al dispatch array was sparse (for no good reason) instead of dense.