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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!TAURUS.BITNET!amiram
From: amiram@TAURUS.BITNET.UUCP
Newsgroups: comp.lang.ada
Subject: language problem
Message-ID: <8703261730.AA28726@taurus>
Date: Thu, 26-Mar-87 12:30:29 EST
Article-I.D.: taurus.8703261730.AA28726
Posted: Thu Mar 26 12:30:29 1987
Date-Received: Wed, 1-Apr-87 07:28:11 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

A colleague of mine, Yossi Veler of AITECH has come up with the following
program in Ada, which seems to create a serious problem.

procedure boolsub is
   subtype bool is boolean range true..true;
   type arr is array(1..10) of bool;
   a : arr := (1..10 => true); -- this seems like the only legal value
begin
   a := not a;
-- Here a(1)=a(2)=...=a(10)= FALSE !!!! No exception occurs etc.
   a := (1..10 => false);
-- This does cause an exception
end boolsub;

The program seems legal : we inspected the LRM and also the implementers
guide, and we ran it on both the DDC and VERDIX compilers. It seems that
a combination of innocent features in Ada produces a result that seems to
contradict with the basic philosophy of the language, that is an object
posseses a value which is not in the appropriate type.

It seems that several features interact to produce this undesirable situation:
1) Boolean is an enumerated type, and one can take a subtype of it.
2) Boolean array operations, which are the only ones operating on all elements
of an array.
3) At run time, array assignements are not checked element by element ( I
believe in all but this case this check is indeed not required ).

Has anyone noticed this before? Is there a way out of it?