Re: Record rep specs for private components

Re: Record rep specs for private components

[Edward Berard]

I have a problem with the following:

>   package a is
>      type aa is private;
>   private
>      type aa is range 0..1000;
>   end a;
>
>   with a;
>   package b is
>      type bb is record
>         bbb : a.aa;
>      end record;
>      for bb use record
>        at mod 2;
>        bbb at 0 range 0..15;       --Legal?
>      end record;
>      x : bb;
>   end b;

If type a.aa is private, then its underlying implementation should be
unknown outside of package a. This means that it should be impossible
for another program unit to specify how much space an instance of this
type should take up. [Of course, package a could supply operations
which could provide alternative representations of known sizes, and
these could be used in other program units.]

In short, if the rep spec is legal Ada, it should not be, and should
be fixed in Ada 9X.

				-- Ed Berard
				   (301) 353-9652

Re: Record rep specs for private components

[Joe Orost]

In article <523@ajpo.sei.cmu.edu> eberard@ajpo.UUCP writes:
>If type a.aa is private, then its underlying implementation should be
>unknown outside of package a. This means that it should be impossible
>for another program unit to specify how much space an instance of this
>type should take up. [Of course, package a could supply operations
>which could provide alternative representations of known sizes, and
>these could be used in other program units.]
>
>In short, if the rep spec is legal Ada, it should not be, and should
>be fixed in Ada 9X.

According to AI-00551/02 (DRAFT):

"If a component type is a private type, the size allowed in a component
clause for the type is determined by applying the above rules to the full
declaration of the private type."

I agree.

				regards,
				joe

--

 Full-Name:  Joseph M. Orost
 UUCP:       rutgers!petsd!joe
 ARPA:	     petsd!joe@RUTGERS.EDU, joe@PETSD.CCUR.COM
 Phone:      (201) 758-7284
 US Mail:    MS 322; Concurrent Computer Corporation; 106 Apple St
             Tinton Falls, NJ 07724

Re: Record rep specs for private components

[Goodenough]

In article Re: Record rep specs for private components of 20 Jun 89 13:06:12
GMT joe@petsd.UUCP (Joseph M. Orost) writes:

>According to AI-00551/02 (DRAFT):
>
>"If a component type is a private type, the size allowed in a component
>clause for the type is determined by applying the above rules to the full
>declaration of the private type."

AI-00551 is currently up to version 05, and is still under consideration by
the ARG.  AI-00550 briefly justifies why rep clause support is being required
for certain private types, namely, that if such clauses are not supported for
private types, the effect could be to discourage the use of private types,
since the decision to make a type private would then be equivalent to saying
that objects of the type never need to be positioned explicitly by component
clauses.  As a matter of language design, you don't want programmers to be
concerned about such effects when deciding whether to make a type private.
This would link privateness and rep clause issues in an undesirable way.

Ed Berard says that the underlying implementation of a private type should
not be known outside its parent package, and goes on to say:

"This means that it should be impossible for another program unit to specify
how much space an instance of this type should take up." 

But the point of a private type is not that its implementation is unknown --
it is that a program can't exploit that knowledge in unsafe ways.  To ensure
this, the language limits operations on objects of a private type to those
that are declared explicitly in the type's package.  The type's representation
is hidden in the sense that no representation-dependent operations are
visible.  This means, in general, that the logical properties of a program
are unchanged if the private type's representation is changed later.  Of
course, the effect of a program is similarly unchanged if a component clause
is given for a component having a private type, since the component clause
does not change the set of values allowed for the component, or the effect of
operations on the component.  So the ability to give a component clause is
quite consistent with the notion of a private type.

Of course, if a component clause is given for a private type and the private
type's full declaration is changed later, the component clause might no longer
be accepted (e.g., the component might require more space).  But such an
invalid component clause will be detected when the unit containing the rep
clause is recompiled, so there is no violation of safety.

In short, it would be a mistake to forbid the application of a component
clause to a component just because the component has a private type.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Record rep specs for private components

[Edward Berard]

In article <3560@fy.sei.cmu.edu>, Goodenough@sei.cmu.edu writes:
> 
> AI-00551 is currently up to version 05, and is still under consideration by
> the ARG.  AI-00550 briefly justifies why rep clause support is being required
> for certain private types, namely, that if such clauses are not supported for
> private types, the effect could be to discourage the use of private types,
> since the decision to make a type private would then be equivalent to saying
> that objects of the type never need to be positioned explicitly by component
> clauses.  As a matter of language design, you don't want programmers to be
> concerned about such effects when deciding whether to make a type private.
> This would link privateness and rep clause issues in an undesirable way.
> 

I am strongly in favor of private types. Indeed, it is through the
information hiding provided by private types that module (and object)
coupling is reduced. I also understand the need for "rep specs."
However, the purpose of rep specs often seems at odds with the
purpose of private types, i.e., the very purpose of rep specs is to
explicitly define the underlying implementations.

> Ed Berard says that the underlying implementation of a private type should
> not be known outside its parent package, and goes on to say:
> 
> "This means that it should be impossible for another program unit to specify
> how much space an instance of this type should take up." 
> 
> But the point of a private type is not that its implementation is unknown --
> it is that a program can't exploit that knowledge in unsafe ways.  To ensure
> this, the language limits operations on objects of a private type to those
> that are declared explicitly in the type's package. The type's representation
> is hidden in the sense that no representation-dependent operations are
> visible.  This means, in general, that the logical properties of a program
> are unchanged if the private type's representation is changed later.  Of
> course, the effect of a program is similarly unchanged if a component clause
> is given for a component having a private type, since the component clause
> does not change the set of values allowed for the component, or the effect of
> operations on the component.  So the ability to give a component clause is
> quite consistent with the notion of a private type.
> 
> Of course, if a component clause is given for a private type and the private
> type's full declaration is changed later, the component clause might no
>longer be accepted (e.g., the component might require more space). But such an
> invalid component clause will be detected when the unit containing the rep
> clause is recompiled, so there is no violation of safety.
> 
> In short, it would be a mistake to forbid the application of a component
> clause to a component just because the component has a private type.
> 
> John B. Goodenough

[Before I begin the next discussion, I will admit that there are a few
issues that I do not about. For example, is rep spec support required
for all private types? Is rep spec support required for limited
private types? Is rep spec support limited to scalar private types,
i.e., it is not allowed for composite private types? What about
(limited) private types with discriminants, or private types
implemented using records with variant parts?]

Simply put, I would prefer that private types be very black boxes.
John Goodenough, and others, suggest that there is some benefit to
making some aspects of a private type visible outside of the program
unit in which it is declared, i.e., a "slightly gray" black box. While
I understand the point (and the usefulness), I think the current
situation has two undesirable drawbacks:

	1. A software engineer who is specifying a record layout using
	   both rep specs and private types must refer to the original
	   private type declaration when allowing space for the
	   private type. This requires both time to find the original
	   component, and possibly several tries at allocating the
	   correct amount of space (remember, the private type can be
	   more complex than a simple integer). The software engineer
	   may even allow more space than is necessary.

	2. If the software engineer is required to allow for a large
	   amount of space originally, and a change to the underlying
	   implementation of the private type greatly reduces
	   necessary space, the compiler may not notify the software
	   engineer that less space is needed. If the software
	   engineer is trying to optimize space, this may prove
	   costly.

I propose (what I feel) is a possible solution: size attributes for
private types which can be used in component clauses. One, or more,
attributes could be used to calculate the minimum amount of space
required. This would decrease the need to refer to the program unit in
which the private type was originally declared, and allow the compiler
to allocate the necessary space (provided that the software engineer
made correct use of the attributes).

If these attributes are already in Ada, then no languages changes are
needed. If not, could such attributes be candidates for Ada 9X?

				-- Ed Berard
				   Berard Software Engineering, Inc.
				   18620 Mateney Road
				   Germantown, Maryland 20874
				   Phone: (301) 353-9652

Record rep specs for private components

[Joe Orost]

We're having a discussion within the posix-ada group about the legality of
record rep-specs for record components of a private type.  I want to find
out what current compilers accept.  Can a few of you try this on various Ada 
compilers (Don't bother if you have VERDIX or SYSTEAM; I tried those):

   package a is
      type aa is private;
   private
      type aa is range 0..1000;
   end a;

   with a;
   package b is
      type bb is record
         bbb : a.aa;
      end record;
      for bb use record
        at mod 2;
        bbb at 0 range 0..15;       --Legal?
      end record;
      x : bb;
   end b;

Please send mail.  I will summarize to the net.

				regards,
				joe

--

 Full-Name:  Joseph M. Orost
 UUCP:       rutgers!petsd!joe
 ARPA:	     petsd!joe@RUTGERS.EDU, joe@petsd.ccur.com
 Phone:      (201) 758-7284
 US Mail:    MS 313; Concurrent Computer Corporation; 106 Apple St
             Tinton Falls, NJ 07724

Re: Record rep specs for private components

[Joe Orost]

In article <1620@petsd.UUCP> I write:
>We're having a discussion within the posix-ada group about the legality of
>record rep-specs for record components of a private type.  I want to find
>out what current compilers accept.  Can a few of you try this on various Ada 
>compilers (Don't bother if you have VERDIX or SYSTEAM; I tried those):
>
>   package a is
>      type aa is private;
>   private
>      type aa is range 0..1000;
>   end a;
>
>   with a;
>   package b is
>      type bb is record
>         bbb : a.aa;
>      end record;
>      for bb use record
>        at mod 2;
>        bbb at 0 range 0..15;       --Legal?
>      end record;
>      x : bb;
>   end b;
>
Here is the summary:

	Compiler	Legal?
	   V		  Y
	   S		  N
	   D		  Y
	   A		  Y

Looks like compiler S has a problem.

--joe@petsd.ccur.com