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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,9983e856ed268154
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.180.75.8 with SMTP id y8mr26691wiv.4.1344411485357;
        Wed, 08 Aug 2012 00:38:05 -0700 (PDT)
Path: 
 n2ni22693269win.0!nntp.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Should Inline be private in the private part of a package spec?
Date: Wed, 08 Aug 2012 08:38:04 +0100
Organization: A noiseless patient Spider
Message-ID: <m2d331zvdv.fsf@nidhoggr.home>
References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net>
	<e416cb92-6ec8-4514-8fa9-c35d6432b117@googlegroups.com>
	<wcc4noj4zof.fsf@shell01.TheWorld.com> <jvnchp$r5c$1@munin.nbi.dk>
	<wccr4rkqed5.fsf@shell01.TheWorld.com>
	<op.wiml9rw3ka8ora@aspire.local>
	<502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net>
	<op.wim0pbprka8ora@aspire.local>
	<50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net>
	<502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net>
	<b3b3dd65-4dbe-4230-a332-58bc6cdd3847@googlegroups.com>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="edf2659fbb8cb6d4b5f62db4b36ac1e6";
	logging-data="12978"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+bjkBfiSXYfroNRxUPAB1nzqdXY8ZwiHk="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (darwin)
Cancel-Lock: sha1:tCqNgtfC0HsC8iyuhy6d16xsUxo=
	sha1:0KPByWSDAFXZhOaw9KCHJiYDfCE=
Content-Type: text/plain
Date: 2012-08-08T08:38:04+01:00
List-Id: <comp.lang.ada>

Shark8 <onewingedshark@gmail.com> writes:

> On Monday, August 6, 2012 4:10:08 PM UTC-6, Georg Bauhaus wrote:

>> And, just like it is not normally important to know optimization
>> issues when writing a call, it is not important to know the
>> convention of an import when writing the call (of the Ada subprogram
>> from the package spec). This is why I have likened optimization to
>> calling conventions. They share the same degree of irrelevance from
>> the caller's perspective.
>
> No, that's not only wrong but _very_ wrong. Conventions are *vital* to
> a specification. Let us consider just one subprogram: Procedure
> Add(Object : In Out Our_Type; Value : In Integer);

Of course the Convention makes a difference to the calling sequence in
the object code (that's what it's _for_).

But why should the person who is writing the Ada code that makes the
call care one jot about the calling convention? In what way does it make
a difference to the code she writes?

After all, the calling sequence for a PowerPC target is going to be very
different to the calling sequence for an x86_64 target. You wouldn;t
expect the Ada (or even C) source code to reflect the difference!