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 15:09:48 GMT
From: agate!dog.ee.lbl.gov!network.ucsd.edu!news.cerf.net!shrike.irvine.com!ada
m@ucbvax.Berkeley.EDU  (Adam Beneschan)
Subject: Re: Type name in rep spec (was: Forcing default representations)
Message-ID: <CAs24D.I20@irvine.com>
List-Id: <comp.lang.ada>

rkaivola@mits.mdata.fi (Risto Kaivola) writes:

> crispen@eight-ball.boeing.com (Bob Crispen) writes:
> 
> >And, definitely non-trivially, can someone explain why some compilers
> >approve of (and even generate proper code for) the following:
> 
> >	type Four_Bytes is range 0..31;
> >	...
> >	for X use
> >         record
> >           Y at 0 range Four_Bytes;
> >           ...
> >        end record;
> 
> >and some don't?
> > Bob Crispen 
> 
> I think that a compiler that accepts this is definitely broken.
> According to the relevant chapter (13.4) of the RM, a component
> clause is defined as (omitting the italicised prefixes which do
> not reflect any syntactic categories, but are there to provide
> information to the human reader)
> 
> component_clause ::= name AT simple_expression RANGE range;
> 
> In 3.5 we find that (again substituting attribute for <range>_attribute)
> 
> range ::= attribute | simple_expression .. simple_expression
> 
> Actually, according to AI-00498, a range attribute is not allowed
> in a component clause, and this fact is reflected in the Annotated
> Ada Reference Manual for Ada9X.  But in your example, Four_Bytes
> does not even fall into the syntactic category attribute!  I wonder
> what the bug causing this behaviour is.  Probably the implementation
> simplifies its job by sort-of 'reusing' some of the code it uses in
> other situations of this sort, erroneusly.

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

> Adam Beneschan queries the legality of the following:
>
> >      type One_Byte is range 0..7;
> >      type Four_Bytes is range 0..31;
>
> >      for Landing_Gear_Parameters use
> >       record
> >         Position   at 0 range Four_Bytes;
> >         State      at 4 range One_Byte;
> >       end record;
>
> and another correspondent who hasn't given me permission to quote
> him says that his Alsys Ada compiler won't compile the code above,
> while all 3 of my VADS compilers (of different vintages, and for
> different targets) will.
>
> 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.
>
> 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!


There are actually two different syntactic rules at work here.  To
answer Bob's question, the definition of a loop_parameter_-
specification is

  loop_parameter_specification ::= identifier in [reverse] discrete_range
  (LRM 5.5)

where discrete_range is defined:

  discrete_range ::= discrete_subtype_indication | range  (LRM 3.6)

and, as Risko pointed out, range is defined as

  range ::= range_attribute | simple_expression .. simple_expression
  (LRM 3.5)

Since a subtype indication is a legal choice for a discrete_range, "for
Each_Color in Colors" is definitely legal.  

However, the syntax of a representation specification uses "range",
not "discrete_range", so while a type name is legal in a loop
statement--and in other contexts, e.g.
  
    type Color_Set is array (Colors) of Boolean;

it's not legal in a rep spec clause.  However, to answer Risko's
question, the compiler writes probably got lazy and didn't distinguish
between a "range" and a "discrete_range".  Also, I'm told that the
ACVC's don't do a lot of checking of rep spec clauses, so a bug like
this could slip through easily.

                                -- Adam