private types and recompilation

private types and recompilation

[David Erickson]

When Ada 83 was designed, why did the designers choose to put
the details of private types in package specifications, rather than
in package bodies (which is more in the spirit of information hiding, and
better supports independent compilation).

As it stands now, if I write a program that withs a package that specifies
private types, I must recompile that program if the details of the private 
types are modified, even if there is no change to the non-private 
specifications of the package.

For example, if a linked list implementation is chosen, a LIST package
might look like this:

generic
  type ATOM is private;
package LIST_ADT is
  type POSITION is private;
  type LIST is private;
  procedure CREATE(L: in out LIST);
  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
  ...

private
  type LIST;
  type POSITION is access LIST;
  type LIST is record
    A: ATOM;
    NEXT: POSITION;
  end record;
end LIST_ADT;


but a program that uses the LIST package does not see the details of the 
private types, so why should a change in those details, say to an array
implementation, cause the program to be recompiled.

The problem could be avoided if the private portion of the package was 
moved to the package body or if it could be declared "is separate".

-Dave Erickson

Re: private types and recompilation

[Kenneth Anderson]

In comp.lang.ada you write:

>When Ada 83 was designed, why did the designers choose to put
>the details of private types in package specifications, rather than
>in package bodies (which is more in the spirit of information hiding, and
>better supports independent compilation).

I'm not sure, but I think because the compiler needs to know the size
of the types so that it can allocate space for parameters in the
subprograms that are defined in the spec.


>generic
>  type ATOM is private;
>package LIST_ADT is
>  type POSITION is private;
>  type LIST is private;
>  procedure CREATE(L: in out LIST);
>  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
>  ...

>private
>  type LIST;
>  type POSITION is access LIST;

You only need the previous two lines.  The declaration below can be
hidden in the body of the package.

>  type LIST is record
>    A: ATOM;
>    NEXT: POSITION;
>  end record;
>end LIST_ADT;


>-Dave Erickson

Ken
--
-------------------------------------------------------------------------------
-
Ken Anderson                           |  "I'd much rather live in perfection,
U.C. Irvine                            |   than deal with reality." -- Kenbod
-------------------------------------------------------------------------------
-
Happy! Happy! Happy! Joy! Joy! Joy!    |  Practice random kindness and
                         -- Stimpy     |  senseless acts of beauty.
                                       |  -- Anne Herbert
-------------------------------------------------------------------------------
-

Re: private types and recompilation

[Christian S. Collberg]

In article <9301271722.aa25516@Paris.ics.uci.edu> kanderso@mabillon.ICS.UCI.EDU
 (Kenneth Anderson) writes:
>In comp.lang.ada you write:
>
>>When Ada 83 was designed, why did the designers choose to put
>>the details of private types in package specifications, rather than
>>in package bodies (which is more in the spirit of information hiding, and
>>better supports independent compilation).
>
>I'm not sure, but I think because the compiler needs to know the size
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>of the types so that it can allocate space for parameters in the
^^^^^^^^^^^^^
>subprograms that are defined in the spec.
>
>


Yes, this is correct. See my thesis "Flexible Encapsulation" (Yes, this is a
blatant plug :-)) for a description of an Ada-like language (Zuse) which --
through the use of novel translation techniques -- allows private parts of
hidden types to be hidden within package bodies.

Christian
-- 
Christian.Collberg@dna.lth.se
Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden

Re: private types and recompilation

[David Emery]

In this particular situation, Ada can do what you want.  You can
complete an incomplete type in the package body.  So, given:

	private
	  type LIST;
	  type POSITION is access LIST;
	  type LIST is record
	    A: ATOM;
	    NEXT: POSITION;
	  end record;
	end LIST_ADT;

you can do the following:

	private
	  type LIST;
	  type POSITION is access LIST;
	end LIST_ADT;

	package body LIST_ADT is

	  type LIST is record
	    A: ATOM;
	    NEXT: POSITION;
	  end record;

	...
	end LIST_ADT;

(Thanks to Tucker Taft who argued for this feature in Ada 83.)

				dave

Re: private types and recompilation

[Tucker Taft]

In article <9301271722.aa25516@Paris.ics.uci.edu> 
  kanderso@mabillon.ICS.UCI.EDU (Kenneth Anderson) writes:

>In comp.lang.ada you write:
>
>>When Ada 83 was designed, why did the designers choose to put
>>the details of private types in package specifications, rather than
>>in package bodies (which is more in the spirit of information hiding, and
>>better supports independent compilation).
>
>I'm not sure, but I think because the compiler needs to know the size
>of the types so that it can allocate space for parameters in the
>subprograms that are defined in the spec.

Parameters are not a great problem, because they can in general
be passed by reference (though if the full type is a scalar or
access type, pass by copy is required).  However, to be able
to allocate local variables of a private type outside the
defining package, and to implement the "=" operator and ":=" operation
correctly, some knowledge of the representation is required.
It is possible to defer all of this to link-time, but for languages
like Ada (and C++, by the way), the choice was made in favor
of minimizing run-time overhead, at the expense of more recompilation.

A general principle in Ada is that every abstraction has
a "logical interface" (the visible part), a "physical interface" (the
private part), and an "implementation" (the body).
If you don't change the logical interface, then you don't have
to edit the source of the clients.  If you don't change the
physical interface, then you don't have to recompile the clients;
only relink.

This principle of separation is carried out quite consistently 
throughout the language, and has been maintained (and somewhat
enhanced with private child packages) in Ada 9X.

As far as the official rationale, here is a paragraph from
the '86 Rationale for the Design of the Ada Programming Language
(section 9.3.3 "Influence of Separate Compilation on the
Design of Packages," page 183):

    The declaration of a private type therefore does not in itself
    provide enough information for storage allocation and other
    operations.  The full declaration of the type is needed, and so
    is any representation clause that the user wants: storage allocation
    will therefore require the information provided by the private part.
    Note that placing this information in the package body would not
    be satisfactory since it would create unnecessary dependences of
    other compilation units on this body, with the consequence that
    changes in the algorithms provided in the body would require
    recompilation of these other compilation units, even in the
    absence of change to the full type declaration.

As a relatively late change to Ada 83, the rules for "incomplete"
types were relaxed somewhat, so that if a private type was
in fact an access type, then the full definition of its designated
type could be deferred into the package body, as mentioned
in the response by Ken Anderson:
  
>>generic
>>  type ATOM is private;
>>package LIST_ADT is
>>  type POSITION is private;
>>  type LIST is private;
>>  procedure CREATE(L: in out LIST);
>>  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
>>  ...
>
>>private
>>  type LIST;
>>  type POSITION is access LIST;
>
>You only need the previous two lines.  The declaration below can be
>hidden in the body of the package.
>
>>  type LIST is record
>>    A: ATOM;
>>    NEXT: POSITION;
>>  end record;
>>end LIST_ADT;
>
>
>>-Dave Erickson
>
>Ken

By the way, in Ada 9X, there is another alternative, namely an
"abstract tagged type."  Such a type (say, "T") can be used as the root 
of a hierarchy of (tagged) types, and the corresponding "class-wide 
type" (T'CLASS) can be used as the type of a subprogram formal parameter, 
allowing algorithms to be written that have no knowledge of the
reprsentation of the various derivatives of the abstract type.

Such "class-wide" algorithms work by relying strictly 
on the "primitive" operations of the abstract type.
Parameters of a class-wide type are naturally passed by reference,
and calls on the primitive operations of such a type are dynamically 
bound to the appropriate operation, based on a "tag" that identifies
the specific type of the actual object associated with the given formal
parameter.  It is interesting to note that the '86 Rationale foreshadowed
this capability (quoting from earlier in section 9.3.3):

    ...  A more flexible architecture -- evolved perhaps from today's
    "tagged architectures" -- would indeed allow data representation
    choices to be deferred until link time, or even later.

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: private types and recompilation

[Pat Rogers]

In article <9301271722.aa25516@Paris.ics.uci.edu> kanderso@mabillon.ICS.UCI.EDU
 (Kenneth Anderson) writes:
>In comp.lang.ada you write:
>
>>When Ada 83 was designed, why did the designers choose to put
>>the details of private types in package specifications, rather than
>>in package bodies (which is more in the spirit of information hiding, and
>>better supports independent compilation).
>
>I'm not sure, but I think because the compiler needs to know the size
>of the types so that it can allocate space for parameters in the
>subprograms that are defined in the spec.
>
>

Well, not really that, so much as that objects of the private type can be 
allocated by users of the package before the package body is ever compiled.  
So the compiler must have sufficient info from the package spec.  Incomplete
type definitions might help you (sometimes called the "Deferred Implementation
Scheme"):

package P is

  type Exported is private;
  ...  operations on the type Exported ...
private
  type Implementation; -- incomplete type def
  type Exported is access Implementation;
end P;

package body P is
  
  type Implementation is ...

end P;

Note however that the language doesn't always force a recompilation, say,
when a comment is added, or a private part is altered. It depends upon
what was changed, but some implementations are "smart" about it.

Pat

Re: private types and recompilation

[Mark A Biggar]

In article <9301271722.aa25516@Paris.ics.uci.edu> kanderso@mabillon.ICS.UCI.EDU
 (Kenneth Anderson) writes:
>In comp.lang.ada you write:
>>When Ada 83 was designed, why did the designers choose to put
>>the details of private types in package specifications, rather than
>>in package bodies (which is more in the spirit of information hiding, and
>>better supports independent compilation).
>I'm not sure, but I think because the compiler needs to know the size
>of the types so that it can allocate space for parameters in the
>subprograms that are defined in the spec.
>>generic
>>  type ATOM is private;
>>package LIST_ADT is
>>  type POSITION is private;
>>  type LIST is private;
>>  procedure CREATE(L: in out LIST);
>>  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
>>  ...
>>private
>>  type LIST;
>>  type POSITION is access LIST;
>You only need the previous two lines.  The declaration below can be
>hidden in the body of the package.
>>  type LIST is record
>>    A: ATOM;
>>    NEXT: POSITION;
>>  end record;
>>end LIST_ADT;

Sorry but you can't do that because LIST is mentioned in the non-private
part of the package spec, its completing declaration must be included in the
private part.  It is only incomplete types that are first introduced in the 
private part that can be completed in the package body.  So if you wrote
the package like the following then you can push the completed type to the
body.  Besides the above package definition is clumsy anyway because the
abstraction for a linked list does not need both the node type and the access
to the node be externally visible.

generic
    type ATOM is private;
package LIST_ADT is
    type LIST is private;
    procedure CREATE(L: in out LIST);
    procedure INSERT(L: in out LIST, A: ATOM);
    ...
private
    type NODE;
    type LIST is access NODE;
end LIST_ADT;

package body LIST_ADT is
    ...
    type NODE is record
	A: ATOM;
	NEXT: LIST;
    end record;
    ...
end LIST_ADT;

Notice that the incomplete type NODE is only mentioned in the private part
of the spec so its completing declaration can wait until the package body.

--
Mark Biggar
mab@wdl1.wdl.lroal.com

Re: private types and recompilation

[Alex Blakemore]

erickson@taurus.cs.nps.navy.mil (David Erickson) writes:
> When Ada 83 was designed, why did the designers choose to put
> the details of private types in package specifications, rather than
> in package bodies

The private part info is for use by the compiler which must know how much
storage to reserve for objects of a private type based solely on
information in the spec.  Even if the program cannot know the
representation details, the compiler must.

So if you change the private part, you must recompile clients since
that info has changed.  But you are "guaranteed" that the compilation
will succeed since the client cannot reference the implementation
details.

Rational allows you to change the private parts without invalidating
clients if you use their subsystems.

*** But there is a really nice trick that makes this much less of a
problem. You can define a private type as an access type which
designates an incomplete type to defer defining the representation to
the package body.  That gives the compiler enough info to allocate the
proper amount of storage for objects of the private type.  The only
disadvantage to this is the extra time and complexity of using an
access type.

But you are already using access types anyway.  So you can simply move
the following lines to the package body and then any modifications to
the type LIST do not force recompilations of the specification.

>   type LIST is record
>     A: ATOM;
>     NEXT: POSITION;
>   end record;

You must leave these lines in the private part.
  type LIST;
  type POSITION is access LIST;

-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted