Re: HELP: renames and enum values

Re: HELP: renames and enum values

[Samuel T. Harris]

Al Johnston wrote:
> 
> I am having a little trouble with the following:
> 
> package EU_AG.ET.Dsc is
> 
>   type OvrRd0State_Typ is (OVERRIDE_OFF,OVERRIDE_ON);
>   for  OvrRd0State_Typ'size use integer'size;
>   for  OvrRd0State_Typ use (OVERRIDE_OFF => 0,OVERRIDE_ON  => 1);
> end EU_AG.ET.Dsc;
> 
> with EU_AG.ET.Dsc;
> package SK_Types.Dsc is
>   package EU_AGETDsc renames EU_AG.ET.Dsc;
>   subtype OvrRd0State_Typ is EU_AGETDsc.OvrRd0State_Typ;
> end SK_Types.Dsc;
> 
> with SK_Types.Dsc;
> package THREE is
>   foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF;
> end THREE;
> 
> When I compile "THREE" the compiler complains that "OVERRIDE_OFF" is not
> 
> declared in "Dsc".  I could get around this by renaming each of the enum
> values
> (that is adding OVERRIDE _OFF renames EU_AG.ET.Dsc.OVERRIDE_OFF;
> to the sk_types.dsc package spec,) but that would be pretty nasty for a
> large
> enum type... plus the fact that it totally defeats the point of package
> in the first place.
> 
> Any one know of a better way of doing the reference to OVERRIDE_OFF in
> the package THREE?
> 
> thanks,
> 
> -al

Type OvrRd0State_Typ is a subtype. Subtypes do not propogate new
definitions for the enumeration literals. The literals remain
defined within package EU_AG.ET.Dsc. A derived type would create
new and visible enumeration literals but I assume you don't
want a derived type here.

Since package SK_Types.Dsc renames package EU_AG.ET.Dsc as
package EU_AGETDsc and package three only withs SK_Types.Dsc
and does not with EU_AG.ET.Dsc I assume you want a solution
which does not introduce a new with clause.

Within package three, you can add 'use EU_AGETDsc;' which will
makes the enumeration literals visible. So you would have ...

with SK_Types.Dsc;
package THREE is
  use SK_Types.Dsc.EU_AGETDsc;
  foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF;
end THREE;

So you actually were very nearly there :)

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

Re: HELP: renames and enum values

[Al Johnston]

Sorry... I should have said it... "without using a USE"...
and without referencing EU_AGETDsc...

I really cant make since of this behavior...  I should be
able to say something like
sk_types.dsc.overrd0state_typ.override_off;

What I really want here is a rename of a data type,
which doesn't seem to be available in ada...  I am
trying to "isolate" one group of routines that use
overrd0state_typ form another group of routines
that use it... I know that is NOT subtypes are for,
but they are the only thing (i have found so far) that
might allow me to do this....  oh well..

So... any way to do this other than with a use/ref
to original package??


thanks for the help... At least the language's behavior
makes a little more since to me now.

-al

Re: HELP: renames and enum values

[Robert Dewar]

In article <38EE494D.DDB9CE9@mindspring.com>,
  Al Johnston <sofeise@mindspring.com> wrote:

> What I really want here is a rename of a data type,
> which doesn't seem to be available in ada...

subtype x is y;

why isn't that good enough for renaming purposes????


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: HELP: renames and enum values

[dale]

Robert Dewar wrote:

> subtype x is y;
> 
> why isn't that good enough for renaming purposes????

...because beginners don't think of it?

Is there any reason why it shouldn't work? (apart from being another
way to accomplish the same thing), i.e. is there some fundamental 
philosoply embedded in Ada that means it would be a Bad Thing?


Dale

Re: HELP: renames and enum values

[Robert Dewar]

In article <dale-F87224.15225009042000@news.rmit.edu.au>,
  dale <dale@cs.rmit.edu.au> wrote:
> Robert Dewar wrote:
>
> > subtype x is y;
> >
> > why isn't that good enough for renaming purposes????
>
> ...because beginners don't think of it?
>
> Is there any reason why it shouldn't work? (apart from being
another
> way to accomplish the same thing), i.e. is there some
fundamental
> philosoply embedded in Ada that means it would be a Bad Thing?




Sorry, I don't know what you mean by "another way" here, this
is the ONE and ONLY method to get the effect of "renaming"
types, and is absolutely standard Ada, and yes it works fine.

And who knows what beginners might or might not think of, but
any decent Ada book should point out this standard usage. The
RM of course is quite clear on the semantic effect of such
a declaration, and that's the end of its responsibility, the
RM gives the (fairly) formal definition of the language, it is
not in the business of pointing out how it can be used :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: HELP: renames and enum values

[Dale Stanbrough]

Robert Dewar wrote:

> Sorry, I don't know what you mean by "another way" here, this
> is the ONE and ONLY method to get the effect of "renaming"
> types, and is absolutely standard Ada, and yes it works fine.
> 
> And who knows what beginners might or might not think of, but
> any decent Ada book should point out this standard usage. The
> RM of course is quite clear on the semantic effect of such
> a declaration, and that's the end of its responsibility, the
> RM gives the (fairly) formal definition of the language, it is
> not in the business of pointing out how it can be used :-)
> 

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!).

I do understand the use of subtype, but I was just wondering
if there were some fundamental reason why a renames for a type
would be excluded (apart from not wanting two ways to do the
same thing).


Dale

Re: HELP: renames and enum values

[Samuel T. Harris]

Al Johnston wrote:
> 
> Sorry... I should have said it... "without using a USE"...
> and without referencing EU_AGETDsc...

These seem bizare restrictions. Could you elaborate on the
context which is forcing such a straight-jacket upon you.

> 
> I really cant make since of this behavior...  I should be
> able to say something like
> sk_types.dsc.overrd0state_typ.override_off;
> 
> What I really want here is a rename of a data type,
> which doesn't seem to be available in ada...  I am
> trying to "isolate" one group of routines that use
> overrd0state_typ form another group of routines
> that use it... I know that is NOT subtypes are for,
> but they are the only thing (i have found so far) that
> might allow me to do this....  oh well..

A derived type will redefine all the literals.
They can be freely type converted between the
two types if interoperability is needed.
Why are derived types not applicable?
The degree of separation between these two
groups of routines seems to indicate the need
for derived types to insure no accidental
mixing of the routines is coded.

> 
> So... any way to do this other than with a use/ref
> to original package??

You can define a bunch of enumeration constants
which are initialized to their corresponding
literals from the original package. This does
require references to the original package.
If such references are not pleasant given your
content, then perhaps you can use deferred constant.
The initializations, and their references to the
original package, will then be in the package
specification's private part.

> 
> thanks for the help... At least the language's behavior
> makes a little more since to me now.

To give you more than you probably wanted, one reason
subtypes do not redefine the literals is that enumeration
literals are semantically identical to parameterless functions.
This allows the same literal to be used in two different
enumeration types via the usually function overloading rules.
This also precludes redefining the literals in subtypes
because this would create duplicate homographs (two
subprograms in the same declarative region with the same
parameter profile and return types).

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

Re: HELP: renames and enum values

[Samuel T. Harris]

Robert Dewar wrote:
> 
> In article <38EE494D.DDB9CE9@mindspring.com>,
>   Al Johnston <sofeise@mindspring.com> wrote:
> 
> > What I really want here is a rename of a data type,
> > which doesn't seem to be available in ada...
> 
> subtype x is y;
> 
> why isn't that good enough for renaming purposes????
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

It really doesn't rename the type.
Enumeration literals are not available from
the subtype.

When I do a package rename, I can reference
all the package content from the renamed
package.

So subtyping is related, but not
the same, as renaming.

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

Re: HELP: renames and enum values

[Al Johnston]

> > What I really want here is a rename of a data type,
> > which doesn't seem to be available in ada...
>
> subtype x is y;
>
> why isn't that good enough for renaming purposes????

S Harris gave the "correct" answer to why the above
is not correct (I started this thread, so I get to say what is
correct with respect to my intent).  He said:

>It really doesn't rename the type.
>Enumeration literals are not available from
>the subtype.

To get to the values associated with subtype "x" you
still have to reference type "y".  This defeats the whole
point of doing the "rename" (implemented as a subtype).

-al

Re: HELP: renames and enum values

[Al Johnston]

>
> > Sorry... I should have said it... "without using a USE"...
> > and without referencing EU_AGETDsc...
>
> These seem bizare restrictions. Could you elaborate on the
> context which is forcing such a straight-jacket upon you.

I am to "smart" (I hope) to start this thread... the debate over
using "use".  And in this case I can avoid it.  The code I am
reworking has the same type declared in multiple places.
I am reworking the code to get ride of them.  Avoiding the use
of use helps me catch the errors I make...  leaving/using the use
would mask many of the errors until a later change.

Re: HELP: renames and enum values

[Tucker Taft]

Al Johnston wrote:
> 
> I am having a little trouble with the following:
> 
> package EU_AG.ET.Dsc is
> 
>   type OvrRd0State_Typ is (OVERRIDE_OFF,OVERRIDE_ON);
>   for  OvrRd0State_Typ'size use integer'size;
>   for  OvrRd0State_Typ use (OVERRIDE_OFF => 0,OVERRIDE_ON  => 1);
> end EU_AG.ET.Dsc;
> 
> with EU_AG.ET.Dsc;
> package SK_Types.Dsc is
>   package EU_AGETDsc renames EU_AG.ET.Dsc;
>   subtype OvrRd0State_Typ is EU_AGETDsc.OvrRd0State_Typ;
> end SK_Types.Dsc;
> 
> with SK_Types.Dsc;
> package THREE is
>   foo : SK_Types.Dsc.OvrRd0State_Typ := SK_Types.Dsc.OVERRIDE_OFF;
> end THREE;
> 
> When I compile "THREE" the compiler complains that "OVERRIDE_OFF" is not
> 
> declared in "Dsc".  I could get around this by renaming each of the enum
> values
> (that is adding OVERRIDE _OFF renames EU_AG.ET.Dsc.OVERRIDE_OFF;
> to the sk_types.dsc package spec,) but that would be pretty nasty for a
> large
> enum type... plus the fact that it totally defeats the point of package
> in the first place.
> 
> Any one know of a better way of doing the reference to OVERRIDE_OFF in
> the package THREE?

One way would be to move the enumeration type declaration into
a subpackage all by itself.  You could then rename this subpackage
rather than the enumeration type itself, and all references to the 
enumeration type and the enumeration literals would uniformly 
use the subpackage name as a prefix.

> thanks,
> 
> -al

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: HELP: renames and enum values

[Ted Dennison]

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;

?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: HELP: renames and enum values

[Robert Dewar]

In article <38F5D6F9.5B8892F2@bton.ac.uk>,
  John English <je@bton.ac.uk> wrote:
>  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!


I have a different view of learning languages, I do not expect
my students to "guess" anything about a language, I expect them
to learn rules and apply them.

I agree that this rule might be non-intuitive if the basic
semantics of enumeration literals has not been presented in
a clear manner.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: HELP: renames and enum values

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> What's wrong with:
>    Enum_Literal : constant Enum_Type := Other_Enum_Literal;
> 
> ?

You lose the ability to overload the literals.

- Bob

Re: HELP: renames and enum values

[Samuel T. Harris]

John English 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!
> 

Perhaps I am not "one of them" since I figured this out
quickly the first time I ran into this renaming problem
way back in my youth. I learned Ada 83 by reading the
reference manual long before I had a compiler to play
with. During my initial reading, I found it strange that
enumeration literals would be defined as parameterless
functions. A little introspection quickly revealed the
necessity of this semantic definition to allow the same
literal to be used in different enumeration type definitions.

When I later actually had a compiler to use and needed to
rename some enumeration literals, the function renames
was the first thing I thought of. I actually did not
expect the compiler to accept it, figuring the semantic
definition was just some standarized sugar but was
pleasantly surprise with the successful results.

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

Re: HELP: renames and enum values

[Samuel T. Harris]

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!"

Re: HELP: renames and enum values

[John English]

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!

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: HELP: renames and enum values

[John English]

Robert Dewar wrote:
> In article <38F5D6F9.5B8892F2@bton.ac.uk>,
>   John English <je@bton.ac.uk> wrote:
> >  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!
> 
> I have a different view of learning languages, I do not expect
> my students to "guess" anything about a language, I expect them
> to learn rules and apply them.
> 
> I agree that this rule might be non-intuitive if the basic
> semantics of enumeration literals has not been presented in
> a clear manner.

Well, this is not quite what I meant; *if* they had to guess it,
they wouldn't in a million years. I don't expect my students to
guess things either, and I do indeed explain it, but in my
experience many students find it completely unintuitive that
the literals of a type are actually functions, and it takes a
bit of frowning and head-scratching before they finally write
it off as "hey, it's crazy, but you gotta live with it".

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: HELP: renames and enum values

[Tucker Taft]

John English wrote:
> ...
> 
> 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!

We sort of fixed this in Ada 95.  In Ada 83, if you did the
"obvious" thing:

   Enum_Literal : Enum_Type renames Other_Enum_Literal;

you got your hand slapped by the compiler because it is attempting
to rename a value as an object.  In Ada 95, the above is perfectly
legal, and I would expect most people to use it for renaming.

The only reason *not* to use the "obvious" renaming is if you
want the renaming itself to be overloadable.  That seems relatively
less common.  If you are sophisticated enough to want to have
your renamings overloadable, then you are probably sophisticated enough
to use function renamings to accomplish them.

So I would not consider this a teaching problem any more.
The beginning user can do the obvious thing, and the more
sophisticated user can get overloadability if they need it.

> 
> -----------------------------------------------------------------
>  John English              | mailto:je@brighton.ac.uk
>  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
>  Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
>  University of Brighton    |    -- see http://burks.bton.ac.uk
> -----------------------------------------------------------------

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA