Re: limited private types

[rfg@nsc.nsc.com (Ron Guilmette)]

In article <748@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>
>In article <7796@aw.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes:
>
>   In article <739@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>   >In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
>   >>   I have some problems with limited private types too.  Specifically, if such
>   >>   types are really only accessable through a "limited" functional interface,
>   >>   then why shouldn't we be able to declare such types in the public part of
>   >>   a package and then defer the full declaration until the package body?

>This is true, but it doesn't allow separate compilation; you cannot
>compile bodies that use the limited private type untill the size of
>that type is known. One way around this is to declare the limited
>private type to be a pointer to a type whose full declaration is
>defered to the body of the package:

OK. Now there no >'s in from so this is me (Ron Guilmette) talking again.
Sorry for all the >>>>'s above, but I just couldn't pass up the chance to
totally confuse the issue by quoting quotes of comments on quotes of
comments of what I said way back when.  :-)

Anyway, I *do* know about the special tricky Ada rule which allows you
to defer a full type definition until the corresponding package body
(if that type is only used in the package spec to help define pointer
types).

>Admittedly, access types are not the best in all situations, but this
>does enhance portability.
>
>   >Why does your post sound so hostile?  How do you know that Ron hasn't
>   >put any thought into his suggested changes?
>
>I didn't mean to sound hostile, I was simply frustrated with the lack
>of information. If Ron was concerned with the issue you raised, he
>should have said so explicitly. Believing someone has good reasons,
>and knowing what those reasons are, are two different things.

Also, although I didn't explicitly say it, I did mean to make a point
about the "separation of concerns" between a spec and a body, which
Ada generally supports very well.  (I don't think that "portability"
per se is quite the issue that I'm concerned about).  Anyway, don't
worry about apparent hostility.  I'm generally pretty thick skinned
(and some would say thick-headed).

The point I wanted to make was this.  If you look at all the things that
you are allow to do with an object of a limited private type (as given
in LRM 7.4.2 and 7.4.4) in the scope where the given type is *actually*
limited (i.e. within the *whole* scope of the type name but *not* in the
same scope as the full type definition for the type) then you find out
that there isn't very much you can do with (or to) an object of a limited
private type.

Basically, about the only thing you can do with such objects is to pass
them as actual parameters to subprograms.  Obviously, if you do this, then
for each such subprogram, the actual *definition* of the given subprogram
must be compiled only *after* the full type declaration has already been
compiled.

"Why?" you ask.  Well it is because of the fact that Ada insists that
scalars must always be passed by value-result.  Non-scalars may be passed
any old way (e.g. by reference).

Since any given Ada compiler must generate code to copy scalar actual
parameters into their corresponding formals, and since the most efficient
way to do this is to know ahead of time the total size (e.g. 32 bits)
of the given parameter, and since the full type definition of a given
limited private type (object) may sometime be scalar, The Ada designers
made the only wise choice available to them, i.e. to insist that the
full type declaration for any arbitrary limited private type be given
in the same compilation (unit) as the (original) limited type declaration.

This rule insures that the compiler will always know the actual size
of all formal parameters at least before the end of the current compilation.
Thus, the "scalar-by-value-result" rule (see LRM 6.2{6}) may be obeyed
while parameter passing is kept efficient.

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.

Note that the programmer himself can easily achieve the semantics of
"pass-by-value-result" if he/she is given the base semantics of "pass-
by-reference" but not vise versa!  To get value-result semantics given
a base of by-reference semantics, all one has to do is make one's own
temporary copies (of the variable(s) involved) within the subprogram in
question.