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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!xanth!nic.MR.NET!umn-cs!stachour From: stachour@umn-cs.CS.UMN.EDU (Paul Stachour) Newsgroups: comp.lang.ada Subject: Re: limited private types Keywords: limited-private, paramater-passing, pass-by-reference Message-ID: <10322@umn-cs.CS.UMN.EDU> Date: 5 Dec 88 01:48:48 GMT References: <44449@beno.seismo.CSS.GOV> <3563@hubcap.UUCP> <7882@nsc.nsc.com> <739@marvin.cme-durer.ARPA> <7796@aw.sei.cmu.edu> <748@marvin.cme-durer.ARPA> <8197@nsc.nsc.com> Reply-To: stachour@umn-cs.cs.umn.edu (Paul Stachour) Organization: CSci Dept., University of Minnesota, Mpls. List-Id: In article <8197@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes: > >What I was proposing was the suspension of the "scalar-by-value-result" >rule, and a substitution (in LRM 6.2{6,7,8}) of language which would >instead insist that *all* parameters, regardless of type, be passed >by reference. > >This would yield two benefits: > >1) We could put our (corresponding) full type declarations for our > limited types into packages bodies where they seem to belong (and > where they require fewer re-compilations when changed) and > >2) we could make the language simpler by having one single (standard?) > type of parameter passing *semantics* for *all* types of objects. > >Another (dubious?) benefit of my "pass-by-reference-only" rule would be >that it would make all the ex-FORTRAN people feel comfortable (and would >probably simplify mixed-language interfacing where Ada & FORTRAN were >concerned). Note that FORTRAN has *always* used the "pass-by-reference-only" >rule. I have programmed in a variety of languages over the 25 years (wow, it is hard to belive, but it is 25 years) that I have been programming. In that time, I've learned a LOT about parameter-passing. I learned about Multics and good PL/I implementatations only after I already had 15 years of work, like 10 years ago. One of the things I discovered was how efficent its parameter-passing was, as well as being flexible. PL/I likes to pass everything by reference, and that's good (I'll say why in a moment). Multics uses 2n+1 (or n+1) words for each parameter-list. nwords for arg-pointers, nwords for arg-desicriptors (iff needed), and 1-word for the arg-count, discriptor-count, and whether args or discriptors exist at all. Functions get an extra-arg (the result) created in the caller. This means, in general, that one can often use an arg-list fully prepared at compilation-time (sometime modified at execurion-time), and just pass one-pointer to a calling routine. Long and well-thought Ada-style paramater-lists (including defaults) can be done very well using this mechanism. But the real advantage of reference semantics comes when you have data-structures being accessed by multiple tasks, as we are now starting to do in Ada, and Multics has done well for more than the 10 years I've known it. You pass an argument to a subroutine, it changes it, and the change is immediately, instantly, visable to all routines. And without the messiness of passing explicit pointers. Now, languages that don't allow reference semantics at all are really ugly. C's sometimes-you-must (stucts) and sometimes-you-mussent (arrays) are confusing. Ada's consistancy (at least for composites) is refreshing after the last two years I've been fighting C to get jobs done. However, I don't believe that Ada REQUIRES reference semantics for composites, it merely allows them. And in these days of distributed programs, it is questionable what kind of efficiency one can get with reference semantics over many machines. [The questions are similar to those of efficiency in virtual-machines 20 years ago; questions which were well-settled by the measurements in Multics showing that IO actually got cut in half in virtual-memory + sharing paradym over thant of physical-memory + explicit IO. Too bad most hardware/software groupings we call computer systems still can't seem to do good virtual-memory management, but that's another discussion.] I'm for reference semantics. They are natural, efficient, and don't force this explicit-pointer "junk". But let's make sure what we can do with them in today's environment before we ask Ada 9X to mandate them.