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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3867e2f73fa21ec
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,UTF8
X-Received: by 10.66.221.42 with SMTP id qb10mr6663626pac.37.1367783159789;
        Sun, 05 May 2013 12:45:59 -0700 (PDT)
Path: 
 bp1ni1644pbd.1!nntp.google.com!news.glorb.com!aioe.org!.POSTED!not-for-mail
From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?=
 =?utf-8?Q?=29?=
 <yannick_duchene@yahoo.fr>
Newsgroups: comp.lang.ada
Subject: Re: Ada 2012: In-out parameters for functions
Date: Sun, 05 May 2013 21:45:52 +0200
Organization: Ada @ Home
Message-ID: <op.wwmmiqtcule2fv@cardamome>
References: <7704abab-86f2-4edc-ad4b-b3d4e70004fb@googlegroups.com>
 <UYadnS4eOq5gCB7MnZ2dnUVZ_jqdnZ2d@supernews.com>
 <op.wwiascfvule2fv@cardamome>
 <op.wwibdpw7ule2fv@cardamome> <km1h9d$k5k$1@munin.nbi.dk>
 <aumqbiFf76eU1@mid.individual.net> <op.wwlyp5ymule2fv@cardamome>
 <CDAC1492.2D8D2%yaldnif.w@blueyonder.co.uk>
NNTP-Posting-Host: 01/BPNoqk8s7XmPzrYdoUA.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: Opera Mail/12.15 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable
Date: 2013-05-05T21:45:52+02:00
List-Id: <comp.lang.ada>

Le Sun, 05 May 2013 14:52:18 +0200, Bill Findlay  =

<yaldnif.w@blueyonder.co.uk> a =C3=A9crit:
>> Seems this topic was not discussed at all for Ada 2012.
>
> I'm glad to hear it, because the idea is bonkers.
>
> Declarations collect relevant info to one easily found place in the co=
de,
> instead of having it splattered around at random.
>
> These suggestions about parameter mode make no more sense than suggest=
ing
> that, instead of declaring:
>
>   I : Integer; S ; String;
>
> One should instead have to write things like:
>
>    I% :=3D I% + 1;
>    S$ :=3D "";
>
> (A la BASIC)

Rational for Ada 2022 says:
> We wanted to help the users to tracks variable dependencies
> and side effects on variables. The declaration and thus the
> type of a variables is typically not very far and most of
> times, local (or when not that close, that's typically a
> constant defined in a specification, and a constant is less
> cause of errors than a variable). Function declarations are
> on the opposite, typically far away and not local, so it's
> easier to lose track of sub=E2=80=91program signatures than lose track=

> of variable types. Thus, Ada 2022 added some syntax to allow
> users to express there intended effects in a way which allow the
> compiler to catch any erroneous assumptions.

I fully agree with the Rational for Ada 2022.

Then, there is nothing bad in helping catching errors and unintended  =

behaviours.

Personally my option for a syntax would be something like with SML (SML =
 =

being the de=E2=80=91facto standard to me, at avoiding unwanted side=E2=80=
=91effects):


     -- Declaration:

     procedure P
       (A, B :    out The_Type;
        C, D : in out The_Type;
        E, F : in     The_Type);

     -- Use case:

     (A, B, C, D) :=3D P (C, D, E, F);


What appears on the LHS would be what's =E2=80=9Cout=E2=80=9D or =E2=80=9C=
in out=E2=80=9D and what appears  =

on the RHS would be what's =E2=80=9Cin=E2=80=9D or =E2=80=9Cin out=E2=80=
=9D, with what's =E2=80=9Cin out=E2=80=9D  =

appearing both on the LHS and RHS.

But I have no hope for it to be ever accepted, as the call=E2=80=91place=
 syntax  =

would surely be too much far from typical Ada syntax, and may be too few=
  =

people are used to this kind of syntax.


-- =

=E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1]
=E2=80=9CStructured Programming supports the law of the excluded muddle.=
=E2=80=9D [1]
[1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers=
ity