limited private types

limited private types

[r_srinivasan]

folks,

I hope someone has a reasonable suggestion for the following problem :

I am developing a file processing application that requires opening and
closing of an unspecified number of files. Ideally i would like to
build a "stack" of "files".

Currently I am using text_io package. Unfortunately the type
text_io.file_type is a "limited private" type and this means no
assignments. I have been able to get around this somewhat by using
File_access type but there is no "close" procedure that will take a
file_access.

Any and all ideas would be appreciated.

regards

srini


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[Marin D. Condic]

r_srinivasan@my-deja.com wrote:
> I am developing a file processing application that requires opening and
> closing of an unspecified number of files. Ideally i would like to
> build a "stack" of "files".

Well, one possible alternative is to store the information necessary to
open and close the file rather than the file itself. (The string for the
name, etc.) Of course this depends on if you have to have them open all
at once or not.

There's probably other ways, but I have not given it enough thought just
yet. In general, I'd consider it a bad idea to have lots of files open
all at once if it can be avoided. Better to open and close them as
needed. If you do need them open all at once, maybe you could collect up
the names and once the number is known, allocate an array of File_Type
that matches the number you need.

What exactly are the requirements? There may be a better alternative.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: limited private types

[r_srinivasan]

An array of File_Type might well do the trick even though I might have
to think up some arbitrary limits to this array. while not too elegent,
will do the trick. Thank you.

In case it matters the application is a "C" preprocessor (like) that
supports inclusion of other files . I would rather not have to close
and reopen/seek etc.

regards

srini

In article <3907DF77.5BD05EBE@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> r_srinivasan@my-deja.com wrote:
> > I am developing a file processing application that requires opening
and
> > closing of an unspecified number of files. Ideally i would like to
> > build a "stack" of "files".
>
> Well, one possible alternative is to store the information necessary
to
> open and close the file rather than the file itself. (The string for
the
> name, etc.) Of course this depends on if you have to have them open
all
> at once or not.
>
> There's probably other ways, but I have not given it enough thought
just
> yet. In general, I'd consider it a bad idea to have lots of files open
> all at once if it can be avoided. Better to open and close them as
> needed. If you do need them open all at once, maybe you could collect
up
> the names and once the number is known, allocate an array of File_Type
> that matches the number you need.
>
> What exactly are the requirements? There may be a better alternative.
>
> MDC
> --
> ======================================================================
> Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
> Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
> Visit my web site at:  http://www.mcondic.com/
>
> "I'd trade it all for just a little more"
>     --  Charles Montgomery Burns, [4F10]
> ======================================================================
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]


<r_srinivasan@my-deja.com> a �crit dans le message :
8eaaa2$rkl$1@nnrp1.deja.com...
> An array of File_Type might well do the trick even though I might have
> to think up some arbitrary limits to this array. while not too elegent,
> will do the trick. Thank you.
>
> In case it matters the application is a "C" preprocessor (like) that
> supports inclusion of other files . I would rather not have to close
> and reopen/seek etc.
>
In this case, why don't you use a local variable for the file ?
Stacking will occur automatically...

There's only one trick: don't forget to close the file when you leave the
procedure that holds the variable. Otherwise, you'll leave a file open with
no way of closing it. If you declare a local file variable, it is advisable
to end the subprogram with:
exception
   when others =>
      if Is_Open (F) then
         close (F);
      end if;
end;

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: limited private types

[Marc A. Criley]

You can use an "access File_Type" type, allocate instances
of it, stack them, and Close them--Close(F.all).

Marc

r_srinivasan@my-deja.com wrote:
> 
> folks,
> 
> I hope someone has a reasonable suggestion for the following problem :
> 
> I am developing a file processing application that requires opening and
> closing of an unspecified number of files. Ideally i would like to
> build a "stack" of "files".
> 
> Currently I am using text_io package. Unfortunately the type
> text_io.file_type is a "limited private" type and this means no
> assignments. I have been able to get around this somewhat by using
> File_access type but there is no "close" procedure that will take a
> file_access.
> 
> Any and all ideas would be appreciated.
> 
> regards
> 
> srini
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: limited private types

[Ray Blaak]

r_srinivasan@my-deja.com writes:
> Currently I am using text_io package. Unfortunately the type
> text_io.file_type is a "limited private" type and this means no
> assignments. I have been able to get around this somewhat by using
> File_access type but there is no "close" procedure that will take a
> file_access.

Assuming:

  type File_Access is access Text_IO.File_Type;
  f_ptr : File_Access;

then why can't you do Text_IO.Close(f_ptr.all)?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: limited private types

[r_srinivasan]

The "access" technique does not work because text_io.close takes an "in
out" parameter and gnat complains that the "access".all is not
a "variable".

In article <un1mfl8cp.fsf@infomatch.com>,
  Ray Blaak <blaak@infomatch.com> wrote:
> r_srinivasan@my-deja.com writes:
> > Currently I am using text_io package. Unfortunately the type
> > text_io.file_type is a "limited private" type and this means no
> > assignments. I have been able to get around this somewhat by using
> > File_access type but there is no "close" procedure that will take a
> > file_access.
>
> Assuming:
>
>   type File_Access is access Text_IO.File_Type;
>   f_ptr : File_Access;
>
> then why can't you do Text_IO.Close(f_ptr.all)?
>
> --
> Cheers,                                        The Rhythm is around
me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside
me,
> blaak@infomatch.com                            The Rhythm has my soul.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[tmoran]

>The "access" technique does not work because text_io.close takes an "in
>out" parameter and gnat complains that the "access".all is not
>a "variable".
       This runs just fine with Gnat 3.12p NT:
with ada.text_io;
 use ada.text_io;
procedure Test is
  type ptrs is access file_type;
  p : ptrs;
begin
  p := new file_type;
  create(p.all, out_file, "pall");
  put_line(p.all, "hello world");
  close(p.all);
end Test;

Re: limited private types

[Erland Sommarskog]

Ron Guilmette (rfg@nsc.nsc.com.UUCP) wants to be able to defer the 
implementation of a (limited) private type to the body of his package.
He writes:
>Anyway, I *do* know about the special tricky Ada rule which allows you
>to defer a full type definition until the corresponding package body
>...
>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.
>...
>Since any given Ada compiler must generate code to copy scalar actual
>parameters into their corresponding formals, and since the most efficient
>...

Since you have thought so much on the not-so-obvious problem of parameter 
passing, you must have found the answer to the more obvious problem of
heap and stack allocation as trivial. I am probably stupid, because I
fail to see any attractive solutions to that. If in my block I declare:
   A : A_limited_type;
   B : Another_limited;
   C : ARRAY(1..20) OF Yet_another_limited;
If the implementation of the types in available in the specification 
of the types originating package, there is no problem. But if you defer
them to the body, and do not allow cheating with pointers? Enlighten
me, how to you allocate them on the stack? Implicit pointers? Some
implicit size-telling function called at run-time? Not very attractive,
since the place on the stack for other local variables is dependent 
of the size of the types.

To be straight I think that the pointer "trick" serves our needs 
perfectly here, and that your proposal is just YAUAC. (Yet Another 
Unnecessary Ada Change.)
-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment

Re: Ada language revision

[Wilmer Rivers]

[Do not eat this line under penalty of law.]

   This is a somewhat edited version of a message I sent by E-MAIL
to SALLEN%LOCK.SPAN@STAR.STANFORD.EDU (Stanley Roger Allen) in response
to message <8811141420.AA01652@ajpo.sei.cmu.edu>.  I shall not re-post
any excerpts from his original article, but as I interpreted it he
wanted to make 2 major complaints : (1) many or most changes that are
being suggested to Ada are not adequately thought out before they are
proposed, and (2) any changes that would deviate from the original
intent of Ada's goals should be eschewed.  Although the first point
may well be correct, I should like to take mild exception to the
second one, and I am posting these remarks publicly in order to en-
courage further discussion of this issue via this newsgroup.

   The article seems to suggest that any changes to Ada should be re-
stricted to refining the grand design that was set into motion long
ago, rather than accommodating any changes that would involve a new
direction for the language.  You can certainly build a strong case for
that.  ("Here's what Ada is supposed to do, and if you want to do some-
thing else, then come up with a different language, just don't call it
Ada.")  However, proponents of more drastic changes also have a point.
Suggesting that all changes should be confined to moving from Steelman
to TitaniumMan (or ReinforcedConcreteMan, or whatever) may be too rigid.
(No pun intended, but actually the concept of rigidity is appropriate
here.)  This concept of minimal evolution reminds me of the member of
the board of directors of the Metro system here in D.C. who recently
dismissed commuters' pleas for more farecard machines in certain subway
stations by noting that introducing more machines would "interfere with
the aesthetic purity of the design" of the stations.  He's right, but
(1) commuting patterns change; (2) the farecard machines have turned out
to be less reliable than they were in the original "aesthetically pure"
design; and (3) assuming you don't want the subway stations to serve as
museums or cathedrals, what counts is not so much their architectural
splendor as how easy they make it to catch a train.  So it is with pro-
gramming languages.  (1) Programming has changed in recent years [and of
course Ada is partly responsible for that]; (2) some features of Ada
haven't *really* worked so well as the designers had intended; and (3)
whether or not the LRM is the best thought-out set of rules and specifi-
cations since the U.S. constitution is less important than whether pro-
grammers can use Ada to get their job done.  Apparently, some of them
think they can't, so they want some changes that aren't consistent with
what Steelman (and maybe even Strawman) thought Ada was supposed to do.
Is that so terrible?  The dogmatic attitude of "If it's inconsistent
with all the great effort that we've put into Ada, then it's heresy and
we musn't do it" may not be the best one for revising the language.
Sometimes it's necessary (or at least desirable) to make fundamental
changes ab initio, even if they are in conflict with what you originally
had in mind.  For example, if someone wants a language that does some of
the things that were cited in the original posting as contrary to the
goals of Ada, then is it so unthinkable for him to suggest that the new
language he needs should nevertheless still be Ada?  Saying "Nope, that
definitely isn't what Ada is all about," really just begs the issue.  An
appropriate response would be, "Maybe Ada wasn't about that originally,
but why shouldn't it be about that now?"  You shouldn't automatically
legislate against progress by saying that the goal of the language is
cast in stone (or straw, wood, tin, iron, steel, titanium, reinforced
concrete, ...).

   Well, that's my own mild flame.  In summary, I am arguing that langu-
age design purists shouldn't be allowed to use the obvious necessity for
considering very carefully any proposed changes to the LRM as justifi-
cation for outlawing a priori any changes in the *intent* of the langu-
age itself.  As I said above, a strong case can in fact be made for that
attitude, but personally I don't think making the language's goals sac-
rosanct is in the best interest of the programming community.

			    Wilmer Rivers (rivers@beno.CSS.GOV)
			    Teledyne Geotech


[I suppose I should add the standard disclaimer stating that my own
views and those of my employers may differ, but actually I doubt that
the company cares very much about this issue one way or the other, and
they would probably perfer that I didn't spend any time caring about
it either.]

Re: Ada language revision

[William Thomas Wolfe,2847,]

   In view of the recent discussions re: appropriateness of revisions, I'm 
   hereby submitting the revisions I think appropriate for Ada 9X for general
   discussion and/or flamage:

      1) The assignment operator should be available for overloading
         as part of an ADT specification (i.e., a limited private type 
         which is enclosed within a (usually generic) package).  Currently, the
         closest we can come is to define an ASSIGN procedure.  Unfortunately,
         this is not consistent with the use of := for other object types, and
         worse yet, the ASSIGN procedure is not invoked during the evaluation of
         in parameters, making it impossible to achieve anything other than a
         shallow copy of a user-defined ADT which is used as a value parameter,
         the disastrous implications of which should be readily apparent.

      2) Similarly, there is no provision for defining the DESTROY procedure
         over an abstract data type such that UNCHECKED_DEALLOCATION is required
         to invoke it.  Again, we have inconsistency with the predefined 
         objects, and there are unfortunate implications for space efficiency.

      3) The rule that a limited private type cannot be a direct component of 
         another limited private type should be repealed.  This makes it hard
         to use one ADT as a building block in the construction of higher-level
         ADTs.  The standard workaround is to use an intervening pointer, with
         negative implications for time and space efficiency upon each access.

      4) It should be possible to overload generic packages with differing 
         generic parameter structures.  For example, suppose I have two
         generic linked list requirements: sometimes I need the ability to
         INPUT and OUTPUT the list to a file, and sometimes I don't.  If I
         can't overload the package with differing generic parameter structures,
         I'll have to include the procedures INPUT (LINKED_OBJECT) and 
         OUTPUT (LINKED_OBJECT) in every instantiation of a linked list;
         even if I have no intention of ever calling the INPUT and OUTPUT 
         procedures for this particular type of linked list.  Result: more work
         on my part to define unnecessary INPUT and OUTPUT procedures which will
         never be called, and possibly an unnecessarily large body of 
         instantiated code which contains code to handle procedures that I will
         never call. 

      5) The rule that functions must have only in parameters should be 
         repealed.  Data structures which are history-sensitive, such as tree
         structures which secretly keep a "current item" pointer in order to
         speed up groups of requests which all involve the same item, will
         subtly change as a result of calls to the Boolean function ITEM_EXISTS;
         this forces us to use an intervening pointer in order to implement
         such a function with only in parameters, and suffer the resulting time 
         and space penalties upon each and every access to the structure. 
 
      6) Exceptions should be capable of being passed as parameters.  Currently,
         it is not possible to write a function ASSERT which takes a Boolean
         expression and an exception, and raises the exception if the expression
         turns out to be false.  The workaround is to enclose every call to 
         ASSERT in a local block, with an exception handler specifying that
         the desired exception should be raised in response to the exception
         Assertion_Failed.

      7) Arrays should be initializable via named association.  It is very 
         tedious to write out 37 Falses simply in order to initialize the
         38th element of a Boolean array to True before I can finally specify 
         that all other elements of the array are False. 

       8) Record types should have the attributes NUMBER_OF_FIELDS, 
          FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).  Not having
          these attributes prevents the construction of a generic report
          generator which will accept a record type as a generic parameter,
          and provide a function GENERATE_REPORT which, given a file of those
          records, will automatically generate a report in which the column
          headers are labeled with the field names (with spaces substituted for
          underscores), and automatically laid out across the page with the
          appropriate spacing between columns.  Assuming the availability of an
          appropriate system call, the name of the source file could even be 
          used as the report title.   But without being able to read that record
          descriptor, the implementation of such a generic report generator is
          very hard to achieve in any reasonably clean way. 


   Well, there they are.   Now where was that fireproof outfit...?


                                                   Bill Wolfe

                                             wtwolfe@hubcap.clemson.edu

Re: Ada language revision

[Ron Guilmette]

In article <3563@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>
>   In view of the recent discussions re: appropriateness of revisions, I'm 
>   hereby submitting the revisions I think appropriate for Ada 9X for general
>   discussion and/or flamage:

Well, since somebody else started this ball rolling, I guess it might be safe
to do a little Ada bashing and launch off into a jihad of my own.

>      3) The rule that a limited private type cannot be a direct component of 
>         another limited private type should be repealed...

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?  Why?
Well, I'll tell you why.  It seems to me that it is because of Ada's silly
specification of parameter passing conventions, where the implementor gets
to decide if he/she wants to pass any given scalar type object using
value-result.  This should also be repealed.  All parameters should be passed
by reference.  Period.  Then programmers would never have to guess about
implementation semantics and the compiler would never have to know what the
real implementation of a given limited private type was until the package
body was being compiled.

>      6) Exceptions should be capable of being passed as parameters.

I agree completely, but I would go much further and say that any category of
run-time (not compile-time) entity which can be represented by an identifier
(including exceptions and record field names, but not generic units) should
be "passable" as parameters.  Further, I think that *all* entities which
can be designated by an identifier (including exceptions, record field names,
and generic units) should be "passable" as generic (instantiation) parameters.

>      7) Arrays should be initializable via named association.

If Ada only had "classes" (a la Simula & C++) we could trash a whole lot of
specialized convoluted syntax and semantics having to do with initialization
and constructors also.

>       8) Record types should have the attributes NUMBER_OF_FIELDS, 
>          FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).  Not having
>          these attributes prevents the construction of a generic report
>          generator which will accept a record type as a generic parameter,
>          and provide a function GENERATE_REPORT which, given a file of those
>          records, will automatically generate a report in which the column
>          headers are labeled with the field names...

OK, but how do you number the fields in a variant record?

-- 
Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg

Re: Ada language revision

[Stephe Leake]

In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
(among other things):

>   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?

What would this gain? Do you have any specific examples where this
would have improved the readability or functionality of an
application? Let's not just suggest changes because they "sound good".
Let's put some thought into it, including concrete examples.

   ... I would go much further and say that any category of
   run-time (not compile-time) entity which can be represented by an identifier
   (including exceptions and record field names, but not generic units) should
   be "passable" as parameters.  Further, I think that *all* entities which
   can be designated by an identifier (including exceptions, record field names,
   and generic units) should be "passable" as generic (instantiation) parameters.

Again, why? What would we gain, what would we lose?

   >      7) Arrays should be initializable via named association.

According to LRM 4.3.2 (3), they are. (Doesn't anybody read the manual?)

   If Ada only had "classes" (a la Simula & C++) we could trash a whole lot of
   specialized convoluted syntax and semantics having to do with initialization
   and constructors also.

What convoluted syntax? There is _one_ construct; the aggregate. It is
a _very_ powerful construct, and I consider it one of the best
features of Ada. Perhaps you could give us an example of how Simula or
C++ would do something that an aggregate can't do.

Let's try to keep the discussion concrete, so we can come up with real
suggestions to the review commitee, not just a letter to Santa Claus.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Ada language revision

[Dennis Doubleday]

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?
>
>What would this gain? Do you have any specific examples where this
>would have improved the readability or functionality of an
>application? Let's not just suggest changes because they "sound good".
>Let's put some thought into it, including concrete examples.

There is a VERY good reason for it, if you're at all concerned about
portability.  The declaration of a limited private type is an
IMPLEMENTATION decision.  It doesn't belong in the specification, it
belongs in the body.  If I'm trying to export some abstract data type
from a package, I'd like to have a specification that could be moved,
intact, from one machine to another.  Only the body should need
changing.  However, since I must give the full declaration of the type
in the private part of the spec instead of in the body, it may be that
I will have to change that part of the spec if I want to port the
package to a machine which requires a different implementation of the
type. 

Why does your post sound so hostile?  How do you know that Ron hasn't
put any thought into his suggested changes?

Dennis Doubleday                       dd@sei.cmu.edu
Software Engineering Institute         (412)268-5873
Carnegie Mellon University
Pittsburgh, PA 15213

limited private types

[Stephe Leake]

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?
   >
   >What would this gain? Do you have any specific examples where this
   >would have improved the readability or functionality of an
   >application? Let's not just suggest changes because they "sound good".
   >Let's put some thought into it, including concrete examples.

   There is a VERY good reason for it, if you're at all concerned about
   portability.  The declaration of a limited private type is an
   IMPLEMENTATION decision.  It doesn't belong in the specification, it
   belongs in the body.  If I'm trying to export some abstract data type
   from a package, I'd like to have a specification that could be moved,
   intact, from one machine to another.  Only the body should need
   changing.  However, since I must give the full declaration of the type
   in the private part of the spec instead of in the body, it may be that
   I will have to change that part of the spec if I want to port the
   package to a machine which requires a different implementation of the
   type. 

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:

package My_Private_Type

type Hidden is limited private;
...
private

type Real_Hidden;
type Hidden is access Real_Hidden;

end My_Private_Type;

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.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: limited private types

[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.

Re: limited private types

[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.

Re: limited private types

[ryer]

I agree it would be nice to be able to defer specifying the details
of the private type until the body is compiled.  Also, the reason for
the present restriction is so that the compiler can know the size of
the type.  Implicitly generated heap objects would work ok (forcing all
passage of private types by reference).  HOWEVER:

Ada now provides the pointer-based semantics when the user explicitly codes
an access type.  It ALSO provides the more efficient direct allocation/access
when the user does not code a access type.   The language changes proposed 
would eliminate one option.  It is possible to build an Ada compiler which 
NEVER uses the heap or any sort of pointer to access ordinary objects of 
static sizes, and at least one is very careful of this.  This is important
to those who use Ada for realtime systems.  

Many actual private types in real programs turn out to be integers.  Passing
these by value makes a big difference in the performance of the generated
code.  (Often a procedure parameter is already in a register at the call
site, and some optimizers contrive to make it the appropriate one so the cost
for passing it is zero as compared to a store at the call site followed by
a load in the caller).  Some Ada applications are built for small machines
with restricted memory and modest throughput and have to meet timing constraints
that are very tight (e.g. 100 hertz).  

As we used to say in the Ada language design days, "any good compiler will
resolve this", in this case by only introducing an implicit access type when
the private type's definition is missing from the spec and otherwise generating
the same code as now.  I hope we've learned that compiler writers sometimes
take the easiest path and defer the optimal approach to some future release.
We've gone through years of performance problems with Ada because of compilers
that weren't optimal.  Efficient approaches were proposed for every language
feature when the language was being designed, and features were dropped it
nobody could come up with an efficient implementation.  It turns out that 
compilers aren't as good as the language designers contemplated even now.

There had been no mention of the impact on the generated code in this note
stream and I had to post this flame.  In the 9X cycle, we need to ask
not only whether an efficient implementation is feasible, but whether
it is likely to appear in most compilers within a reasonable time.

I "vote" strongly against the proposal that ALL parameters should be
passed by reference  -- that clearly would make Ada less efficient on
most machines however good the compilers are.

The slow acceptance of Ada has been due to performance problems in the
generated code and speed and reliability problems in the compilers, not
due to a lack of flexibility in dealing with private types or other features.
Lets not add complexity and reduce performance this time around.

Mike Ryer
Intermetrics, Inc.

Re: limited private types

[stt]

All Ada compilers already deal with "stack" objects
of size unknown at compile time (e.g. x : string(1..f(y));).
Some compilers do this more efficiently than others,
but the big advantage is that the compiler takes care
of freeing the associated storage when the object goes away.
When access types are used, it is always a challenge to
figure out how to ensure that the storage gets efficiently
reclaimed.  (This is one of the big reasons why
I believe user-defined "finalization" should be added into the language.)

Nevertheless, access types with a deferred incomplete designated
type are still used in complex systems, because they break
recompilation dependencies.  It seems like allowing the
deferral of any private type to a package body would be little or no
additional burden on compiler writers, and would provide
the same nice break in recompilation dependency when used.  
For non-discriminated types,
the size would be an elaboration-time constant.  For discriminated types,
the size would be determined by a function call (many
compilers already create size functions to save code space
for complex variant record size calculations).
However, it would be appropriate to require that the full
definition of the private type be a record type, so that
pass-by-reference semantics would be allowed.  

The syntax for such a deferred private record type might be:
     . . .
  private
      type Priv is record;
     . . .

I fully agree with the importance of pass-by-value semantics
for all scalars/access-values.  It is easy enough to wrap a scalar
into a record if pass-by-reference semantics are preferred for some
particular application.  The improved speed possibilities for pass-by-value
scalars far outweigh any abstraction disadvantage.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: limited private types

[Stephe Leake]

In article <8197@nsc.nsc.com> rfg@nsc.nsc.com (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.

This sounds reasonable, but will obviously have a performance impact
where lots of scalar parameter passing is going on (something I don't
do much - records are much more expressive than scalars). But since
the problem is really only with (limited) private types, how about
insisting only those must be passed by reference?

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899