Re: Gripe about Ada, rep specs that won't.

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

In article <dewar.827845854@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>But if 7 bits are required to generate a 'Size of 7, which is reasonable,
>then the same requirement would require a record with 1023 booleans
>to have a 'Size of 1023, which is NOT reasonable, since large objects
>like this are reaonably rounded to a storage unit boundary.

But the paragraph we're arguing about has an explicit exception for
things that are bigger than a "word".  The implementation defines what
"word" means, but it's intended to match what the hardware can do --
i.e. if you have 32-bit registers, and you can add, multiply, subtract,
and divide 32-bit integers in a single instruction, then clearly a word
ought to be 32 bits.  So there's no requirement that 1023 booleans be
packed into 1023 bits -- the implementation can round up to 1024,
because that's a multiple of the word size.

>In Ada 83, the programmer had control in the 7 bit case by explicitly
>setting the size to 7. This is absolutely standard coding practice in
>most large applications we see, the programmer is definitely interested
>in the value of the size.

True, although in my experience, many Size clauses are pretty confused
-- the Ada 83 RM is confused about what it means, the ARG ruled on it
(and I doubt if the average programmer read those rulings), and now we
find that RM95 didn't get it right, either.

>However, the Ada 95 RM does not, as we have discussed, require any rep
>clauses for 'Size  of records to be accepted.

True, I and I agree it should have.

>P.S. It is always worth a disclaimer that this discussion is still largely
>theoretical. GNAT and most other Ada 95 compilers will fully implement
>the rep clauses that are needed. I would define this set as
>
>  Those that are simply mapped to the hardware

One could argue about exactly what that means.  RM95-13 is attempt to
define this concept more precisely, and we see that we forgot some
things.  The ARG can rule on those points.  But I still think that's the
right approach -- otherwise, you end up with implementers deciding that
"simply mapped to the hardware" means "we don't have to implement chap
13 at all", as in the early days of Ada 83.  Or else you end up with the
ARG legislating all kinds of fancy stuff that people don't really need,
as in the later days of Ada 83.  Legislation by the courts makes me
uneasy.

>     +
>
>  Those that are widely used in existing code
>
>     +
>
>  Those that soeone is willing to pay for

You keep stating this disclaimer, and I keep agreeing with it, but we
continue to argue about it.  Methinks we both just like to argue,
instead of doing our jobs.  ;-)

The above sets are pretty much overlapping.  I mean, people who design
low-level data formats, for the most part make them fairly efficient on
the machine(s) they're interested in, and efficient more-or-less means
"simply mapped to the hardware", so most of the things one needs to
interface to are in all of the above sets.

There are exceptions.  E.g. the segment tables on the 386 are weird,
primarily for upward compatibility with earlier processors (you have to
fit the bits in where you can).  And once in a while you run across some
weird device that hands you a stream of 9-bit values, and you want to
deal with it as an array.

- Bob