Re: Question about record rep spec placement

[rgilbert@polaris.orl.mmc.com (Bob Gilbert)]

In article <E46D5J.EM3@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <5bof0o$q0i@zeus.orl.mmc.com>,
> Bob Gilbert <rgilbert@polaris.orl.mmc.com> wrote:
> >In article <32DF9F55.7EA3@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> [stuff about rep clauses in private parts]
> 
> I agree with the reasons Ken stated for putting rep clauses in private
> parts.  However, because of the freezing rules, it is not always
> possible to do that.  Therefore, my style is to put the rep clause right
> after the type.  This makes various changes less painful -- e.g. suppose
> you want to add something into the visible part that freezes the type.
> You'll have to move the rep clause to do that.  Besides, a style rule
> that says "Put this info in the private part when possible, but
> otherwise put it in the visible part" seems kludgy to me -- knowing that
> rule, I have no idea what it means that a rep clause is in the visible
> part.  Is it because clients are supposed to take advantage of it?  Or
> is it merely because there happens to be some freezing point of the
> type, and the programmer couldn't put the rep clause in the private
> part.

I too agree with Ken's reasons for putting rep clauses in the private
part (to support a documentation tool and because the client should
not have to be bothered with the details of the rep clause), but it
seems to me if you don't want the client to know about the details of 
the type, why not go ahead and make the type private?  This is where 
I find it odd to place only the rep clause in the private part for a 
type which is not private (as in Ken's example).

> This problem existed in Ada 83, too.  The freezing rules are slightly
> more permissive than the forcing occurrence rules of Ada 83, but not to
> the point where I've changed my mind about where to put rep clauses.
> 
> IMHO the freezing/forcing rules are a serious flaw in the language.
> 
> >  type T is {whatever};
> >  for type T use private;  -- Tell the user and compiler to look for
> >                           -- further specifics about T's representation
> >                           -- elsewhere in the package, perhaps even in
> >                           -- the package body.
> 
> What is the point of this idea?  Nobody said "Gee, wouldn't it be more
> readable if we knew a rep clause is coming later?"  

No, but I think somebody said "Gee, it sure would be more readable if we
could place the rep clause somewhere else and avoid making the client 
sift through a bunch of details that shouldn't matter to the client".  
The point of this idea is to inform the reader and compiler that a rep 
clause does exist for the type, just that it appears somewhere else.  
Perhaps the idea is unworkable, it was just an off-the-wall thought.

> So it's unclear to me why you would want the above.  Are you saying it
> makes life easier for the compiler?

I was looking at it more from a readability standpoint, can't say I
know much about the compiler issues.

> What matters is where the rep clause gets elaborated -- it's of no help
> to the compiler to know that it's coming, because the compiler can't
> "look ahead" to the rep clause and get any useful information, 

Not sure I understand.  Why can't the compiler "look ahead"?  

> because
> that information might consist of non-static expressions (in a few rep
> clause cases), and anyway, you can't elaborate a variable declaration
> (for example) at run time without knowing how to represent the variable.

Like I said, the idea may not be workable.

> Putting rep clauses in the body is not feasible.  If you could do that,
> you might as well put the full type of a private type in the body, too,
> and completely eliminate the concept of a private part.  This is
> certainly possible, but leads to a less-efficient run-time model.

This is along the lines of what I'm thinking for private types.  Since
you don't want the client to have much knowledge or control of a private
type, why clutter the package spec with all the details?  It's kind of a 
"you can look but don't touch" attitude which I think should be more of a 
"if you can't touch it, you don't need to be looking at it either".

>  Or it
> leads to a different program-library model.  It might be a reasonable
> idea, but it's not Ada.  Ada 83 was designed so that the compiler never
> needs to look at bodies when compiling a client [unless it, ahem, wants
> to do something useful with pragma Inline], and so that private types
> can be implemented as efficiently as an equivalent non-private type.

Okay, I accept that.  I believe that generics also fall into this category
of the compiler having to look at the bodies.
 
-Bob