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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a00ff2b882a06fda
X-Google-Attributes: gid103376,public
From: "Samuel T. Harris" <samuel_t_harris@Raytheon.com>
Subject: Re: HELP: renames and enum values
Date: 2000/04/13
Message-ID: <38F6323B.79B6A9F7@Raytheon.com>#1/1
X-Deja-AN: 610829058
Content-Transfer-Encoding: 7bit
References: <38ECE0EB.4BD4A53E@mindspring.com>
 <38EE2019.4C91075D@Raytheon.com> <38EE494D.DDB9CE9@mindspring.com>
 <8cp1hd$3so$1@nnrp1.deja.com> <dale-F87224.15225009042000@news.rmit.edu.au>
 <8cqf1i$i72$1@nnrp1.deja.com> <dale-1DD343.21533110042000@news.rmit.edu.au>
 <38F5D6F9.5B8892F2@bton.ac.uk> <8d4t6r$oam$1@nnrp1.deja.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: Raytheon Aerospace Engineering Services
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 2000-04-13T00:00:00+00:00
List-Id: <comp.lang.ada>

Ted Dennison wrote:
> 
> In article <38F5D6F9.5B8892F2@bton.ac.uk>,
>   John English <je@bton.ac.uk> wrote:
> > Dale Stanbrough wrote:
> > > All i was attempting to say is that
> > >
> > >    type blah renames bleh;
> > >
> > > could be predicted to have the same semantics as a subtype
> > > declaration (this would be the "other way" of performing
> > > subtyping).
> > >
> > > I know what beginners think of, because I had 8 years of
> > > teaching beginners. This is something that some of them
> > > thought of (but not many because most of them were introduced
> > > to subtypes long before renames!).
> >
> > What's even less obvious is the way to rename enumeration literals:
> >
> >  function Enum_Literal return Enum_Type renames Other_Enum_Literal;
> >
> > Now, that *really* confuses them, and none of them would ever be
> > able to guess it without being told!
> 
> What's wrong with:
>    Enum_Literal : constant Enum_Type := Other_Enum_Literal;
> 

package a is
  type x is (one, two, three);
  type y is (one, two, three);
end a;

with a;
package b is
  function one return a.x renames a.one;
  function two return a.x renames a.two;
  function three return a.x renames a.three;

  function one return a.y renames a.one;
  function two return a.y renames a.two;
  function three return a.y renames a.three;
end b;

with a;
package c is
  one : constant a.x := a.one;
  two : constant a.x := a.two;
  three : constant a.x := a.three;

  one : constant a.y := a.one;      -- compilation error
  two : constant a.y := a.two;      -- compilation error
  three : constant a.y := a.three;  -- compilation error
  -- these are co-resident homographs.
end c;

As I alluded to in a previous post, enumeration literals
are semantically defined as parameter-less functions. This
allows overloading them in different enumeration type
definitions. This also them multiple renames because the
correct renaming is a parameter-less function renames
declaration. Constants cannot be overloaded!

However, constants usually fill the bill in my actual
experience since overloaded enumeration literals simply
don't come up often in those rare cases where I need
to redefine the things. I say rare cases because there
are many other ways to get the adequate results that I
simply don't need to rename enumeration literals anymore.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"