Re: Representation Clauses And Freezing

["Marin D. Condic" <mcondic-nospam@acm.com>]

Stephen Leake wrote:
> 
> If you follow the compiler's advice, and change the size and alignment
> clauses to:
> 
>    for Rec_Type'Size use 16 * System.Storage_Unit;
>    for Rec_Type'Alignment use 4;
> 
> then it is "happy" again (well, except for all the spaces before the
> semicolons, but not around elipses :).
> 
Making the compiler happy isn't really the issue. If I could accept
whatever the compiler insisted on giving me, then I wouldn't need a
representation clause, right?

My question is, if in fact this is some sort of required behavior
because of freezing rules or other language issues, then *why* is it
required? If it is *not* required behavior, then that just means I've
got a compiler weakness and another compiler might actually make this
work.

> I have no explanation for why the record size and alignment changes
> when it is a private type. But why do you care?
> 
If it is legal to slam a representation clause on a tagged type and if
tagged types exist to enable object oriented design (hence the "private"
aspects), then one ought to be able to slam a representation clause on
the tagged record in the private part of the spec and not have to put
the record elements in the visible part of the spec. Otherwise, what's
the point?

Why do I care? I'm often confronted with problems that require control
of representation and I'd like to be in a position to say "Ada can do
that!" In the case where tagged records and control of representation
intersect, it appears that this is not the case - unless as suggested by
Tucker Taft elsewhere in the thread, this is just a compiler weakness.


> We've been around on this topic before; the general consensus has been
> that it is better to define a non-tagged record type that has a rep
> clause, and include that as a component in a tagged type.
> 
I find that answer to be unacceptable for a variety of reasons. Mostly
because you have a hard time building class-wide operations that depend
on representation and other attributes to get the job done that you want
done. It also has efficiency concerns and other problems that may not be
an issue for many systems, but they are for some of mine.

At this stage, I'm more interested in establishing some reason for why
such a restriction would exist - if it is not just a compiler bug. It is
possible that what I want to do is perfectly legitimate and its just an
obstinate implementation that won't give me what I want. Or its possible
it is a language restriction - in which case maybe there needs to be a
revision somewhere along the line to remove that restriction.

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/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================