Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!tank!nic.MR.NET!umn-cs!stachour
From: stachour@umn-cs.CS.UMN.EDU (Paul Stachour)
Newsgroups: comp.lang.ada
Subject: Re: Reference Semantics
Message-ID: <10332@umn-cs.CS.UMN.EDU>
Date: 6 Dec 88 00:29:25 GMT
References: <10322@umn-cs.CS.UMN.EDU> <3739@hubcap.UUCP>
Reply-To: stachour@umn-cs.cs.umn.edu (Paul Stachour)
Organization: CSci Dept., University of Minnesota, Mpls.
Lines: 17

In article <3739@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>From article <10322@umn-cs.CS.UMN.EDU>, by stachour@umn-cs.CS.UMN.EDU (Paul Stachour):
>>   I'm for reference semantics.  ...
>
>    OK, we're sold on the benefits of reference semantics.  Let's assume
>    that "in out" parameters are always passed by reference.  Now why
>    should it be impossible for the programmer to choose pass-by-value,
>    as in "in" and "out" modes?  
Guess I was not explicit enough.  Yes, if a programmer specifies
only "in" (no writing) or "out" (no reading), there is no need to force
reference (values are consistant throughout the "world") sematics.
But I don't equate "no writing" with "pass-by-copy-in" or "no reading"
with pass-by-copy-out (though, surely, that is one reasonable way to
implement it).  It's hard not to confuse the desired semantics
(always having the correct, current, value) with the mechansims
(pass-by-reference); I apologize if my meaning was not clear.
   ...Paul