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, MSGID_SHORT,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!amdahl!nsc!rfg From: rfg@nsc.nsc.com (Ron Guilmette) Newsgroups: comp.lang.ada Subject: Re: limited private types Message-ID: <8197@nsc.nsc.com> Date: 1 Dec 88 23:06:03 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> Reply-To: rfg@nsc.nsc.com.UUCP (Ron Guilmette) Organization: National Semiconductor, Sunnyvale List-Id: 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.