Re: limited private types

[stachour@umn-cs.CS.UMN.EDU (Paul Stachour)]

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.