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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ce0900b60ca3f616
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-11-06 00:38:46 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail
From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)
Newsgroups: comp.lang.ada
Subject: Re: Side-Effects in Functions [Rosen Trick]
Date: Tue, 06 Nov 2001 08:38:44 GMT
Message-ID: <3be79e7c.551796@News.CIS.DFN.DE>
References: <kPoE7.9567$xS6.13287@www.newsranger.com>
 <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com>
 <9rue9f$j4t$1@nh.pace.co.uk> <wVzE7.10194$xS6.14029@www.newsranger.com>
 <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com>
 <tu6e2r1fqpq0f6@corp.supernews.com> <3BE35498.9F6381A2@acm.org>
 <9s230d$107b5a$2@ID-25716.news.dfncis.de>
 <5ee5b646.0111040507.5ca7ea23@posting.google.com>
 <9s3tl3$111hco$1@ID-25716.news.dfncis.de>
 <5ee5b646.0111041846.93f3e07@posting.google.com>
 <9s5eub02j61@drn.newsguy.com> <3be666fe.6426140@News.CIS.DFN.DE>
 <9s5skb09lv@drn.newsguy.com> <3be6a7a3.22977140@News.CIS.DFN.DE>
 <slrn9udfg3.4dc.randhol+abuse@kiuk0156.chembio.ntnu.no>
 <3be6b6c9.26855093@News.CIS.DFN.DE> <3BE6CF73.2020705@home.com>
NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111)
X-Trace: fu-berlin.de 1005035924 35214725 212.79.194.111 (16 [77047])
X-Newsreader: Forte Free Agent 1.21/32.243
Xref: archiver1.google.com comp.lang.ada:15904
Date: 2001-11-06T08:38:44+00:00
List-Id: <comp.lang.ada>

On Mon, 05 Nov 2001 17:42:14 GMT, "Warren W. Gay VE3WWG"
<ve3wwg@home.com> wrote:

>I think one of the issues at stake here is that Ada was meant to be
>
>easy to read. If you allow procedures to return values, then it is
>no longer a valid assumption that what looks like a function call,
>does not produce side effects (ie. you cannot assume that the arguments
>are not modified, without looking at the declaration).

Why something that looks like a call returning a result should have no
side effects? There are two completely different and independent
properties of a subroutine:

a) It does not modify arguments
b) It returns a result

What we have in Ada is:

subroutine is a function => a & b
subroutine is a procedure => not b

Now the question, why on Earth b=>a?

>To pull it off, you'd have to make some sort of syntactical difference
>
>in procedure-function calls, to maintain the status quo for functions.
>In case I am not explaining this clear enough, the following example
>might help:
>
>declare
>    Arg : Boolean;		-- Argument
>    R   : Boolean;		-- Result
>begin
>
>    R := My_Function(Arg);	-- Assumed that Arg is not modified
>    R := My_Proc_Function[Arg];	-- A procedure returning.. identified by []
>
>I am not suggesting the [] make a good syntax here, but you'd have
>to do something like this to maintain the distinction that Functions
>already enjoy within Ada.

Seems like Hungarian notation reincarnation. It is IMO a wrong idea.
All that a user should know about a subroutine is its contract. The
parameter mode is a part of the contract. When a user do not want (in
your example) Arg to be modified, he/she must simply say it by
declaring Arg constant, which would make the second call illegal.

Regards,
Dmitry Kazakov