From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 26 Jul 93 18:30:28 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Forcing default representations
Message-ID: <EACHUS.93Jul26133028@spectre.mitre.org>
List-Id: <comp.lang.ada>

In article <9307201257.AA00575@eight-ball.boeing.com> crispen@eight-ball.boeing
.com (Bob Crispen) writes:

   > What I had in mind of course was analogous to the universal practice:

   >       type Colors is (Mauve, Puce, Ultraviolet);
   >	   for Each_Color in Colors loop

   > "in Colors" being shorthand for "in Colors'first..Colors'last".  I
   > believe every Ada compiler accepts this, but I can't find the
   > LRM entry that says where it has to.  Probably right under my nose.

In 3.6(2) of course:

   discrete_range ::= discrete_subtype_indication | range

since 13.4(2) says

   component_clause ::= 
      component_name at static_simple_expression range static_range;

   (The second occurances of discrete and component should be
italicized, as should both occurances of static.  The words "at" and the
the first "range" in component clause are reserved).

   > So, here's the question -- whose compiler has the bug in it?  Or have
   > I, in my quest to write portable code, ended up writing non-portable
   > code?  If you pick the latter, please say why!

     Any compiler that rejects your component clauses is correct.  The
DEC case is not quite as clear, but I don't read 13.4(8) as applying
here.  Report it as a bug if you want, however, I think that in no
case should DEC change this behavior if people depend on it.  (But
change your software to be portable, if your goal is portability. :-)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...