From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!oliveb!orc!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re: "silly" (?) Ada semantics
Message-ID: <20600047@inmet>
Date: 7 Jun 90 17:27:00 GMT
References: <1919@sparko.gwu.edu>
Nf-ID: #R:sparko.gwu.edu:1919:inmet:20600047:000:1177
Nf-From: inmet.inmet.com!stt    Jun  7 13:27:00 1990
List-Id: <comp.lang.ada>


Re: compile-time detectable constraint errors

One revision being considered for Ada9X is that
a class of constraint errors which are clearly
detectable at compile time ("statically" detectable)
be identified in the Reference Manual,
and that a validated compiler be required to flag them.

It is not clear whether the compiler should produce a Required Warning,
or actually reject the compilation unit.  If the compiler can reject
the compilation unit, then we may have to account for conditional
compilation in the Reference Manual as well.
This is because a reasonable use of conditional compilation
may be selecting two distinct algorithms, one of which would
include a statically detectable constraint error but only
in the cases when it would *not* be selected by a controlling
IF statement.

As usual, these issues are more complex than they first appear, and
the original design of the language considered many of these problems
and had to make a choice based on conflicting requirements.
Hindsight may justify making a different choice, but it should
not do so without fully reconsidering the original concerns.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138