Re: Boolean Representation

[dewar@gnat.com]

In article <360E9B5E.FF081471@hso.link.com>,
  "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> As to portability, any compiler which does not support
> the Chapter 13 features _required_ is simply not a candidate
> compiler for the project. Indeed, having the representation
> clause present insures an explicit "compatibility" test
> when evaluating a new compiler. If the compiler does
> not support the representation clause, then I'll know
> it the first time I try to compile it.

That is reasonable as a general policy, but I will repeat that it is
misapplied here. Given the two choices:

1. Count on a one-bit Boolean having representation 0 for False,
and 1 for True.

2. Deriving from Boolean, and applying a rep clause.

It is clear that both from a pragmatic point of view and a formal
RM point of view, 1. is far superior, and 2. is as far as I am
concerned just wrong.

From an RM point of view, you should not rely on non-required chapter
13 features that are likely to be non-portable unless you have to. Indeed
if you have to, then Sam's approach above is of course reasonable. But
in this case, there is no need to use the rep clause, and good programming
practice is to avoid non-essential rep clauses.

For example, adding a confirming rep clause for an enumeration type is
an example of a totally unnecessary nonsense rep clause when using an
Ada 95 clause, but is at least not non-portable, since all compilers
supporting Annex C must allow this clause (even if they may well
generate inefficient code as a result).

But the RM is quite explicit in suggesting that compilers need not support
enum rep clauses for derived types of Boolean. Since such permissions are
not put in their for idle amusement, you can assume that there will indeed
be compilers that take advantage of this, e.g. to compile better code.

Yes, you can include this rep clause and use it as a filter for acceptable
compilers, but that is a bad choice, since you may be excluding a compiler
just because it does not provide a feature that you should not be using
anyway.

On the other hand, it is quite clear from the RM that the intention is
that a one-bit Boolean have representation 0,1 and it is quite impossible
to imagine that any compiler would not provide this.

Yes, I appreciate Sam may have been burned before, because you have to
definitely know quite a bit to know what you can and cannot count on,
but we are not discussing a general principle here, but rather one very
specific example.

I completely agree with Sam's general position here, I completely disagree
that the application of this general position is appropriate to this
particular case.

The pragmatic case, as opposed to the formal RM case is equally strong in
favoring approach 1, since in fact ALL Ada compilers DO of course use 0/1
as the default representation for 1-bit boolean (if you know a little about
architecture, you will know that the only reason for allowing flexibility
in boolean representation is to allow all 0 bits for False, and all 1 bits
for True, and no other non-standard choice makes sense).

On the other hand, it is definitely the case that using the rep clause may
make your program needlessly non-portable. If portability is not an issue,
that's OK, but it is remarkable how often non-portable code has to get
ported :-)

Similarly, it is quite likely that if a compiler *does* support a rep clause
for derived booleans, that it will introduce significant inefficiency in the
generated code.

Sometimes one can tolerate inefficient code if you have no choice, but here
you do have a choice.

Once again, Sam's general point of view is right here, but knowing how to
apply that position constructively and helpfully is indeed not easy. Here
at Ada Core Technologies, we find that a significant part of our support
consists of helping people use rep clauses in the most efficient way,
and to understand how their code is or is not portable.

Coding by superstition, rather than careful reasoning on a case by case
basis is almost always risky, and can definitely lead to an incorrect choice.
In particular, it is amazing how common it is, as in this case, for an
attempt at writing portable code that exactly specifies what you mean,
to be exactly counter-productive and end up making the code less portable!


Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum