Re: Default rep specs for record types - documented??

[Anonymous Coward <bogus_addy@bogus_domain.net>]

In article <uacgktuhd.fsf@acm.org>, Stephen Leake wrote:
>>
>> What's disappointing is that rep specs add considerable clutter.
> 
> Yes. Ada explicitly favors being precise over being concise.

Precision need not be at odds with conciseness.  Consider an
enumerated type:

  type my_enum is (first, second, third);

I am *guaranteed* by the LRM that the representation will code "first"
as zero, "second" as 1, and "third" as 2.  Adding this rep spec:

  for my_enum use (first => 0, second => 1, third => 2);

gives me no more precision, yet it dirties the code.  

Consequently, I will never rep spec an enum unless I intend to deviate
from the default rep spec.  And when I do deviate, the code will be
more readable, because the reader will say "hey wait a minute, why is
this rep spec'd and the others are not.. hmm.. there's something
different here.."  So differences will stand out, as they should.

So being able to count on default representations (which are
changable) is a good thing, because you can be both precise and
concise.

However, in the case of records, I've changed my opinion based on what
I've read here.  A compiler should be given opportunity to optimize
where practical, and imposing a default rep spec could hinder the
compilers ability to optimize record layout.

>> Readable code avoids redundancy, so having default representation
>> aspects that are guaranteed enable less noisey code. 
> 
> Representation clauses are not 'redundant'; they provide information
> that is not provided by the type declaration.

That seems to depend on what aspect of what kind of type we're talking
about.  In the enum case above, the "for .. use" rep spec *is*
redundant.  

> One problem is that the compiler does _not_ warn you if you leave a
> component out of the rep clause; a 'pragma Complete_Representation'
> would be nice. Specifying the total size can mitigate this, but I
> recently had a bug due to this problem.

I can think of cases where rep spec'ing partial records would be
useful.  But I would agree that there should certainly be a warning.

>> I'm not looking forward to rep specing records bit for bit simply to
>> enforce the same order of elements that's specified in the operation
>> specs.
> 
> If 'operation specs' are defining the hardware you are interfacing
> to, then yes, you need a rep clause for each hardware register. The
> time spent writing those clauses _will_ be repaid later when it
> comes to testing on the hardware; there _will_ be fewer bugs.

Perhaps, but for interfacing with C operations (which is my case), I
would prefer to simply write "pragma convention (C, my_record)" and be
able to expect the compiler to base the representational spec purely
off the operational spec, just as the C compiler would for a structure
that only has an operational spec.  

I should not have to micromanage the bitwise layout of a record to
interface with C code.  It puts me at a lower level, and positions me
to make human errors (like writing an incomplete rep spec for a
record), when such errors can be avoided by keeping it high level.

> Someone mentioned a 'pragma Preserve_Layout', which presumably means
> "assume a representation clause that puts things in declaration order,
> with the base size for each component, and no gaps". That would be
> useful, in situations where the type declarations do in fact match the
> hardware precisely. Hmm. That is true for most of the rep clauses I've
> written recently. I'll have to suggest that to AdaCore as a possible
> enhancement; it would have prevented my bug. 

Yes, I agree.. that would be useful.  Or maybe better yet, mandate
that pragma convention (C,...) matches representation order to
declaration order to keep the number of pragmas minimal.