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: border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: GNAT GPL is not shareware Date: Thu, 15 Jan 2015 10:31:03 +0100 Organization: A noiseless patient Spider Message-ID: References: <87bnmetex4.fsf@ludovic-brenta.org> <1otenmcbgnvlt$.dn9361nl2jm8$.dlg@40tude.net> <8ryfky4awox2$.q2gfw4pvsgau.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 15 Jan 2015 09:30:37 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="23dab0694e4174fdc880833ec67fa650"; logging-data="23352"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VOOA62t/QS1pSW0fV7J0Q" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Cancel-Lock: sha1:uTfBseJch9yAUemWjm4NzVObK5Q= Xref: number.nntp.giganews.com comp.lang.ada:191882 Date: 2015-01-15T10:31:03+01:00 List-Id: Le 15/01/2015 00:43, Robert A Duff a écrit : > "J-P. Rosen" writes: > >> Since you can't statically know what subprogram is being called, > > Well, you can't know which body will be dispatched to, but formally > speaking, the subprogram being calling is known statically (and might > be abstract). No, all you could know is a primitive subprogram of an ancestor of the one being called. The called subprogram may have a different (although matching) specifications too. >> Corresponding_Called_Entity returns Nil_Element in place of the >> subprogram declaration. > > Hmm. That seems like just a design mistake in ASIS. It seems like > it should return the entity denoted by the name in the call (which > always exists statically -- X.all(...) is never a dispatching call). > That is, Corresponding_Called_Entity should return what you say > about Corresponding_Called_Root_Entity below. But since it would be incompatible, we need a different query. > But I think you can work around the problem -- look at the name of > the call and see what it denotes. Corresponding_Name_Definition of the called subprogram returns Nil_Element in this case (similarly, because the real subprogram cannot be determined). >> ...But without a declaration, you cannot know the formal parameters >> (so no information about the modes, whether some parameters are >> defaulted, etc.) > > Right. That sort of thing is an annoying nuisance. > >> We need a Corresponding_Called_Root_Entity... I think Serguei >> added something like that. > > I searched for "function Corresponding_Called", and didn't see > anything like that. So if we have such a thing, it has a different > name. Apparently, not done yet. There is a discussion about it in the comments after Corresponding_Called_Entity specification > Are you sure you didn't end up working around the problem in > the way I suggested above? Oh yes. Look at Adacontrol's user guide, and count the phrases "due to a shortcoming of ASIS, dispatching calls..." -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr