Re: Question about record rep spec placement

[bobduff@world.std.com (Robert A Duff)]

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.

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?"  So it's unclear to
me why you would want the above.  Are you saying it makes life easier
for the compiler?

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

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.  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.
Incremental compilation was not considered a requirement.  Note the
different design decisions made by Eiffel, with respect to
specs/bodies/private parts, given that the Eiffel design assumes that
all Eiffel compilers will be incremental.

- Bob