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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: spec/body/rep (Was: Compilation error (GNAT bug?))
Date: Tue, 27 May 2014 17:57:38 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <lm3593$s2e$1@loke.gir.dk>
References: <llg749$itn$1@speranza.aioe.org> <lyoays70lj.fsf@pushface.org>
 <537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net>
 <lm06or$b58$1@loke.gir.dk> <lm1748$1lp$1@dont-email.me>
 <buip8nFgg52U1@mid.individual.net>
 <j4oi1y5qh2lm.18ky7h8pb8wfc.dlg@40tude.net>
 <5384b302$0$6663$9b4e6d93@newsspool3.arcor-online.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1401231460 28750 69.95.181.76 (27 May 2014 22:57:40 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 27 May 2014 22:57:40 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:20083
Date: 2014-05-27T17:57:38-05:00
List-Id: <comp.lang.ada>

"G.B." <rm-dash-bau-haus@dash.futureapps.de> wrote in message 
news:5384b302$0$6663$9b4e6d93@newsspool3.arcor-online.net...
...
> When the compiler knows about "representation units" (I think Bob Duff
> once mentioned such a thing using this name), and the language ties
> them to (the private part of) a unit, then at least programmers will
> have something explicit and reliable, issues notwithstanding:

But this solves nothing. There has to be some implementation-defined (or 
project-defined) way of selecting which "representation unit" is selected 
for a particular compilation. And that's the problem, with any of these 
solutions. (I agree with Dmitry about the problem of keeping the versions of 
the packages in sync. I believe this has to be solved by the 
version-control; one of the reasons that I find typical VCs useless is that 
they refuse to solve that problem and solve other unlikely problems 
instead.)

In any case, adding a new kind of unit would require sweeping changes to the 
language standard and to implementations. It would require a pretty 
significant problem to even consider such a change. We did in fact consider 
that for the mutually-dependent package problem, but ultimately decided to 
avoid it in favor of the "virtual" limited view solution. If we're unwilling 
to use such a solution to solve a critical problem, I can hardly imagine 
using it to solve a problem that's not hard to solve with some tools (as 
with Dmitry's project manager solution) or discipline (as in J-P's comment 
in or out of a library-level renames).

                                Randy.