Re: Constraint checking of actuals passed to Attributes

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Now wait a cotton pickin moment (is that the way that phrase
> is spelled? :-)
> 
> What does the RM say:
>...

You asked me about the *intent*.  I don't claim that the RM precisely
specifies the intended rules, so you're quoting of the RM is irrelevant.
I do claim that the intent should be clear, at least for simple things
like integers, to someone who doesn't use an overly legalistic reading
of the RM.

After all, you argue that the RM wording has the same effect as the Ada
83 wording.  Clearly, if that were the intent of the language design
team, then we would have left the wording as in Ada 83, because it's
much simpler wording -- it just says that using an uninit scalar var is
erroneous.  We must have intended to make *some* change, since we
introduced new terminology ("invalid", "abnormal"), and new rules.

> That's why I dislike this business of divining intent so
> intensely. You end up asking the design team what they remember
> having in mind, and they may not even remember correctly.

It is indeed possible that I don't remember the intent correctly, or
never understood it correctly.

> This is perfectly predictable, quite reasonable (think about
> NaN's in floating point, and ENTIRELY allowable from the quoted
> paragraph read in the most friendly form possible).

Yes, NaN's are part of the reason the "intent" is so hard to specify
precisely, which is why the RM doesn't try.

> Similarly if I was on an IBM 7040, then it would be free to
> cause a fatal parity error terminating the program on any
> access to an uninitialized variable, and that would be just
> fine too (again, very NICE behavior, at least during the
> testing phase). ...

I believe the intent was not to allow such abrupt termination of the
program.  I agree that's "NICE behavior".  I've always thought Ada
should have a notion of killing a program (like "exit" or "abort" in C)
stronger than exceptions.  But it doesn't, and there was no mandate to
add such a notion in Ada 9X, so the only possible way of notifying of
errors is to raise an exception.

>... The WATFOR compiler used to do this (it used
> the hardware diagnostic instruction to set parity wrong on
> all uninitialized data).

ASIDE: You have to be careful about these low-level hardware-oriented
implementations, because they might not match Ada's notions.  For
example, in Ada, it is perfectly OK to copy an array full of
uninitialized components, using an assignment statement.  If the
hardware complains about that, then it's wrong.  I learned this when
writing an Ada compiler for the Symbolics Lisp machine, which had a
4-bit tag on every word, and there was an "undefined" tag, and it
detected any load of an undefined word.  But we had to disable that (by
zeroing uninit vars), which was kind of sad.

> It was my understanding that we put the words implementation
> defined in that paragraph precisely to allow a variety of
> possible implementations, all of which are reasonable.

Perhaps, but if doing so allows absolutely anything, then we made a
mistake (ie, we didn't write words precisely defining our intent).  We
certainly did not intend to allow the use of an uninit var as an array
index to trash arbitrary memory locations.  I realize that some
reviewers didn't like that (Bevin Brett, for example, thought the
trade-off should be in favor of efficiency).

- Bob