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!gegeweb.org!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 27 May 2014 17:45:07 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: spec/body/rep (Was: Compilation error (GNAT bug?))
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>
In-Reply-To: <j4oi1y5qh2lm.18ky7h8pb8wfc.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <5384b302$0$6663$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 27 May 2014 17:45:06 CEST
NNTP-Posting-Host: 10b9240e.newsspool3.arcor-online.net
X-Trace: 
 DXC=n6g<Rj^34UZI?44J>Z[:RQMcF=Q^Z^V3X4Fo<]lROoRQ8kF<OcfhCO[4hg]m>G_fkYnc\616M64>ZLh>_cHTX3j]MflKRNNX8PZ
X-Complaints-To: usenet-abuse@arcor.de
Xref: news.eternal-september.org comp.lang.ada:20068
Date: 2014-05-27T17:45:06+02:00
List-Id: <comp.lang.ada>

On 27.05.14 10:55, Dmitry A. Kazakov wrote:
> On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote:
>
>> On 14-05-27 08:16 , J-P. Rosen wrote:
>>> Le 23/05/2014 23:21, Randy Brukardt a écrit :

(I hadn't seen Randy Brukardt's original reply in my news reader,
sorry for responding late. (And I should have mentioned Link_Name,
not Linker_Options.))

>> Would there be some sense in being able to specify such library-level
>> renamings as configuration pragmas? This might give us a standard way to
>> choose component versions depending on the configuration (leaving as
>> compiler-specific the way to select which configuration is to be
>> compiled... :-)

A configuration pragma seems to have the property that
just one may cover many units, whereas library level
renamings lack this formal connection, and there may be many.
(Directories, or discipline, providing for a more or less formal
mode of development.)

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:

> I have issues with this approach in general. The problem is that there is
> no any check that the interfaces of the target-specific packages are same
> in the sense that all target-independent clients were compilable with any
> "implementation."

Assuming that a universal expression of "compilability" in any
configuration is nice, but likely impossible, would you still think
that what Randy has called a semantics-denying fiction could
be preserved for some aspects? For example,

    procedure Doubled (X : in out Natural)
    with Post => (if
                    X'Old <= Natural'Last / 2
                  then
                    X = X'Old * 2
                  else
                    False),
      Import,
      External_Name => "d2";


If the External_Name aspect of Doubled were moved to
a representation unit tied to whatever Doubled lives in,
then developing the program that calls Doubled should work
up to a point, namely when Natural's representation finally
matters. And doesn't it matter now, in any case, when porting
(configuring)?