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 10.66.252.9 with SMTP id zo9mr1632838pac.28.1371758205056;
 Thu, 20 Jun 2013 12:56:45 -0700 (PDT)
Path: 
 border1.nntp.ams3.giganews.com!border2.nntp.ams3.giganews.com!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!nntp.giganews.com!m6no3365101pbd.1!news-out.google.com!b2ni27533pby.1!nntp.google.com!news.glorb.com!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 20 Jun 2013 21:56:47 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Elaboration order handling (Was: Bug in 'gnatmake')
References: 
 <7f33982d-3bcf-452e-a3b3-3a0a28505ff1@x20g2000vbe.googlegroups.com>
 <87r4g0g9c0.fsf@adaheads.sparre-andersen.dk> <lysj0glghs.fsf@pushface.org>
 <87ip1bg4z2.fsf_-_@adaheads.sparre-andersen.dk>
 <wcczjun4a7y.fsf@shell01.TheWorld.com>
 <db04ccb2-a3f7-4daa-8846-df9a992a0f85@googlegroups.com>
 <kpr0oh$rt9$3@dont-email.me> <wccehbycm2q.fsf@shell01.TheWorld.com>
 <51c217f6$0$6642$9b4e6d93@newsspool2.arcor-online.net>
 <wccy5a562hu.fsf@shell01.TheWorld.com>
In-Reply-To: <wccy5a562hu.fsf@shell01.TheWorld.com>
Message-ID: <51c35e7c$0$6573$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 20 Jun 2013 21:56:44 CEST
NNTP-Posting-Host: 1d6d96fa.newsspool3.arcor-online.net
X-Trace: DXC=kTo:Sh`3GU6^cW`WBF>WQ<McF=Q^Z^V384Fo<]lROoR18kF<OcfhCO;
 f]oC8c]G>F;
 PCY\c7>ejV8^5IcJ?l]B\477c?Y^JGQL7
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Original-Bytes: 2879
Xref: number.nntp.dca.giganews.com comp.lang.ada:181989
Date: 2013-06-20T21:56:44+02:00
List-Id: <comp.lang.ada>

On 20.06.13 02:37, Robert A Duff wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>
>> On 19.06.13 14:38, Robert A Duff wrote:
>>
>>> Oh, and the fact that the whole model is overly restrictive.
>>> For example, it makes perfect sense to say:
>>>
>>>       package Symbols is
>>>           type Symbol is private;
>>>           function Intern(S: String) return Symbol;
>>>           Empty_Symbol: constant Symbol := Intern(""); -- Wrong!
>>>
>>> But that doesn't work in Ada.  It works fine in my hobby
>>> language.  ;-)
>>
>> Does your hobby language allow separate compilation?
>
> Yes.
>
> But I don't see how the compilation model ("separate compilation") is
> relevant to questions about the elaboration model, which is a run-time
> issue.

just wondering how compilation will be unaffected if
- some unit Client references Symbols.Empty_Symbol and
- the latter needs, for its elaboration (if any) the body
   of function Intern,
so that
- when optimizing, inlining, etc., everything needed for
   Intern would be needed, too.