RE: Supertypes RE: Extensible Enumerated types

RE: Supertypes RE: Extensible Enumerated types

[Beard, Frank]

Bob,

I like Jeff Creem's idea of:

type Fruit_Type is (Apple, Orange);
type New_Fruit_Type is new Fruit_Type with (Pear, Kiwi);

So your example would be:

-- from Package Prefix_Recs
type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev,
    Other);

--From Package Prefix_Recs.Army
type Army_Prefix_Type is new Prefix_Type with (Private, Corporal, Sergeant,
Lieutenant, Captain, Major, Colonel, General);

Wouldn't this serve your purposes without the need of adding a new
reserved word?

Frank


-----Original Message-----
From: Robert C. Leif, Ph.D. [mailto:rleif@rleif.com]
Sent: Wednesday, January 31, 2001 3:05 AM
To: comp.lang.ada@ada.eu.org
Subject: Supertypes RE: Extensible Enumerated types 

> This is suggestion includes the addition of a new keyword to Ada. I
realize
> that some would consider this rank heresy.
>
> Since Ada has Subtypes to specify a subset of a type, it would be
reasonable
> to create a symmetrical operation to create a superset of a type.

Re: Supertypes RE: Extensible Enumerated types

[Jeffrey Carter]

"Beard, Frank" wrote:
> I like Jeff Creem's idea of:
> 
> type Fruit_Type is (Apple, Orange);
> type New_Fruit_Type is new Fruit_Type with (Pear, Kiwi);

This seems like an excellent idea. The only difference between this and

type New_Fruit_Type is (Apple, Orange, Pear, Kiwi);

would be type conversions between the types:

F : Fruit_Type     := ...;
N : New_Fruit_Type := ...;

N := New_Fruit_Type (F); -- Always OK
F := Fruit_Type (N);     -- Raises Constraint_Error if N not in
                         -- Apple .. Orange

Are there any technical/implementation issues against this?

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Supertypes RE: Extensible Enumerated types

[Nick Roberts]

I've posted to this newsgroup elsewhere pretty much using Jeff Creem's
suggested syntax, also detailing the conversions and other issues.

--
Nick Roberts
http://www.AdaOS.org

Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?)

[Tucker Taft]

Mark Lundquist wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> wrote in message
> ...
> > I assume you have studied the proposal in the mapping document
> > and it is to this proposal that you are referring.
> >
> 
> BTW, where can we find this mapping document?  It'd be especially nice if
> there were an HTML version somewhere... (Someone has also said that it would
> be nice if the AI database were more Web-friendly, and I concur).

Compressed versions of these documents may be found at:

    http://www.adaic.org/pol-hist/history/9x-history/mapping/

In general, if you poke around in the "history" section under
"Why Ada?" in the site index, you should find it.  Unfortunately,
you have to follow your nose, because these are just directories,
not friendlier web pages with links.

> 
> Anyway, back to the extended enumeration type thing... for my part, I
> haven't read the proposal in the mapping document (since I don't have it
> :-), so someone needs to tell me what the feature means in that proposal.
> Also, I'm not entirely clear what people are asking for, so even if I did
> know what the idea was as it was proposed in the 9x process, I still
> wouldn't know if that's the same thing :-)
> 
> What I want to know is...
> 
> Given
> 
>     type E1 is (Dog, Cat);
>     type E2 is new E1 with (Kangaroo);
> 
> I understand what this is supposed to mean in terms of E2's enumeration
> literals.  What's not clear to me is whether E2 is supposed to have any
> particular relationship to E1.  The only meaninful relationship I can think
> of would be the derivation class -- the implication would be that the
> enumeration types are tagged.  In that case, you obviously have to know that
> E1 is tagged.  Since the syntax of its definition is identical to the
> current syntax for enumeration type definitions, then either (a) the idea is
> that all enumeration types be tagged (not likely! :-) or (b) people aren't
> really asking to do classwide programming on enumeration types after all, or
> (c) they are asking for that but haven't thought it through very far :-) :-)
> 
> A nice Ada syntax for expressing taggedness of an enumeration type escapes
> me right now... I guess it would have to be
> 
>     tagged type E1 is (Dog, Cat);

The proposal was more like:

      type E1 is tagged (Dog, Cat);

I believe.

> 
> If we're not asking for taggedness/classwide, then E1 and E2 have
> absolultely no relationship to each other except that they happen to have
> some of the same enumeration literals, right?  In other words, the second
> line above is precisely equivalent to saying,
> 
>     type E2 is (Dog, Cat, Kangaroo);
> 
> in current Ada, with no extra baggage.  In that case, the proposal is just
> for some syntactic sugar, correct?
> 
> So what is it, sugar or classwide? :-)
> 
> If it's classwide, what I would really like to see is a specific example, in
> Ada code, of a problem that would be solved by the proposed feature...

That was part of the problem.  There weren't too many compelling
examples.  The representation of E1'Class was almost certainly
going to have to be a combination of a tag and a value, which
can't be used easily as an index into an array, so you couldn't
really use E1'Class as a normal "discrete" type.  It was one
way to produce a unique identifier for something like a set
of error messages, but there wasn't much you could do with
the identifier, except perhaps compare for equality.  Even
comparing for less than/greater than was problematic.

Interestingly enough, Wirth dropped enumeration types from
Oberon because he did not find a good way for them to support
extensibility.  This choice seems like a definite case of throwing
big chunks of the baby out with the bathwater.  And unfortunately,
Java followed Wirth's lead, and now we are back (in Java) to defining
named integer constants with absolutely no compile-time checking
or debugger support for what we all know is an enumeration type
"deep down."

One step forward, three giant steps back.  Groan...

> 
> - mark

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA  USA
(AverCom was formed 1/1/01 from the Commercial Division of AverStar)
(http://www.averstar.com/services/ebusiness_applications.html)

Supertypes RE: Extensible Enumerated types

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: My fellow Ada users

This is suggestion includes the addition of a new keyword to Ada. I realize
that some would consider this rank heresy.

Since Ada has Subtypes to specify a subset of a type, it would be reasonable
to create a symmetrical operation to create a superset of a type.

-- from Package Prefix_Recs
type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev,
    Other);

--From Package Prefix_Recs.Army
Supertype Army_Prefix_Type is (Prefix_Type, Private, Corporal, Sergeant,
Lieutenant, Captain, Major, Colonel, General);

Prefix_Type'range would also be a possibility.

Army_Prefix_Type would inherit all of the operations of Prefix_Type.

I believe that super is lexicography a better choice than supra. I must add
that supertypes are appropriate for a super language.

Re: Supertypes RE: Extensible Enumerated types

[Marin David Condic]

I could see that as interesting - sort of building onto type extension. There
may be issues with representation that need to be looked at, do you think? I
guess my only reservation would be that it needs to be asked how generally
useful is this? Would it enable some significant new technique that would get
used often enough to make it worth disturbing the reserved word list?

MDC

Robert C. Leif, Ph.D. wrote:

> From: Bob Leif
> To: My fellow Ada users
>
> This is suggestion includes the addition of a new keyword to Ada. I realize
> that some would consider this rank heresy.
>
> Since Ada has Subtypes to specify a subset of a type, it would be reasonable
> to create a symmetrical operation to create a superset of a type.
>
> -- from Package Prefix_Recs
> type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev,
>     Other);
>
> --From Package Prefix_Recs.Army
> Supertype Army_Prefix_Type is (Prefix_Type, Private, Corporal, Sergeant,
> Lieutenant, Captain, Major, Colonel, General);
>
> Prefix_Type'range would also be a possibility.
>
> Army_Prefix_Type would inherit all of the operations of Prefix_Type.
>
> I believe that super is lexicography a better choice than supra. I must add
> that supertypes are appropriate for a super language.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================