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

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

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Tucker Taft et al.
I believe that at one time you mentioned the possibility of extending an
enumerated type. This would greatly facilitate object oriented programming.
For instance, I have created a Person_Names package. The components of the
name are contained in a record. The tile part: Mr, Ms, Miss, Mrs, Dr, Prof,
etc. must include other. If one needs to make Person_Names.Military one has
to add the ranks. For Person_Names.Clergy, we go from Priest, Rabbi to Pope.
I most strongly believe that although enumerated types are extremely useful,
it is in some cases impossible to anticipate all of them. Extending
enumerated types in child libraries would permit object oriented programming
with this construct.

I will be unable to participate in any discussion until Jan 26, 2001. I have
to Chair a session on Advanced Techniques in Analytical Cytology at SPIE
BiOS 2001. Unfortunately, I think that I am the only one who uses the word
Ada at this SPIE meeting. Many of the devices reported upon can be
life-critical. The level of software development is often quite depressing.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Tucker Taft
Sent: Friday, January 19, 2001 2:51 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: When will next Ada revision be? (83, 95, ?)


"Beard, Frank" wrote:
>
> Where can we go to see a list of the proposed updates to the language?

Look at:


http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-SUMMARY.DOC?rev=1.74

and search for "Class: Amendment" (they are toward the bottom of the file).

>
> Frank

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

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

[Robert Dewar]

In article <mailman.979975693.13263.comp.lang.ada@ada.eu.org>,
  comp.lang.ada@ada.eu.org wrote:
> From: Bob Leif
> To: Tucker Taft et al.

> I believe that at one time you mentioned the possibility of
> extending an enumerated type. This would greatly facilitate
> object oriented programming.

We did indeed consider this possibility, and I even think it
was in one of the earlier mapping documents, but it was
excluded because the implementation and description
difficulties outweighed the usefullness, and further more
for the specific examples presented, there seemed to be
perfectly acceptable alternative methods of doing things.

There is quite a bit of semantic structure in Ada that depends
on knowing the possible set of enumeration types statically.



Sent via Deja.com
http://www.deja.com/

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

[Jeff Creem]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:94c61v$h4a$1@nnrp1.deja.com...
> In article <mailman.979975693.13263.comp.lang.ada@ada.eu.org>,
>   comp.lang.ada@ada.eu.org wrote:
> > From: Bob Leif
> > To: Tucker Taft et al.
>
> > I believe that at one time you mentioned the possibility of
> > extending an enumerated type. This would greatly facilitate
> > object oriented programming.
>
> We did indeed consider this possibility, and I even think it
> was in one of the earlier mapping documents, but it was
> excluded because the implementation and description
> difficulties outweighed the usefullness, and further more
> for the specific examples presented, there seemed to be
> perfectly acceptable alternative methods of doing things.
>
> There is quite a bit of semantic structure in Ada that depends
> on knowing the possible set of enumeration types statically.


Of course I would find it useful (at times) to be able to extend the
set of an enumeration type (in a new derived type) even without having some
sort of a class based pointer to an arbitrary version of one of the new
types.

There are of course other perfectly acceptable methods but at times it would
be cleaner to be able to do things
like

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

A : Fruit_Type := Apple;
B : New_Fruit_Type := New_Fruit_Type(A);


In the past when I have ran into situations like this (where for very
specific reasons I could not add anything
to Fruit_Type) I have resorted to enumeration indexed arrays of enumeration
type look-up tables for the
conversion...Not bad but not as clean as the above.



Whether the extra complexity this imposes on compiler writes (or language
learners) is worth the occasional
convenience is certainly debatable.

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

[Mark Carroll]

In article <t6jeim807fic0a@corp.supernews.com>,
Jeff Creem <jeff@thecreems.com> wrote:
(snip)
>Whether the extra complexity this imposes on compiler writes (or language
>learners) is worth the occasional
>convenience is certainly debatable.

FWIW, I certainly make use of it in other languages. In particular,
you need to be able to iterate through the elements of a type, but if
there are two enumerated types with the same number of elements, if
elements don't implicitly cast from one type to the other, then you're
more likely to catch bugs which involve someone using the wrong type
or getting parameters the wrong way around, etc..

Still, there are ways of simulating it too; maybe I use such types
atypically often.

-- Mark

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

[Robert Dewar]

In article <94ce27$rrb$1@news.cis.ohio-state.edu>,
  carroll@cis.ohio-state.edu (Mark Carroll) wrote:
> In article <t6jeim807fic0a@corp.supernews.com>,
> Jeff Creem <jeff@thecreems.com> wrote:
> (snip)
> >Whether the extra complexity this imposes on compiler writes
(or language
> >learners) is worth the occasional
> >convenience is certainly debatable.
>
> FWIW, I certainly make use of it in other languages.
                                            ^^^^^^^^^

How about specifices, since not many languages support
this capability (C and C++ do not even have enumeration
types in the sense in which we are discussing things now
after all :-)


Sent via Deja.com
http://www.deja.com/

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

[Brian Rogoff]

On Sat, 20 Jan 2001, Robert Dewar wrote:
> In article <94ce27$rrb$1@news.cis.ohio-state.edu>,
>   carroll@cis.ohio-state.edu (Mark Carroll) wrote:
> > In article <t6jeim807fic0a@corp.supernews.com>,
> > Jeff Creem <jeff@thecreems.com> wrote:
> > (snip)
> > >Whether the extra complexity this imposes on compiler writes
> (or language
> > >learners) is worth the occasional
> > >convenience is certainly debatable.
> >
> > FWIW, I certainly make use of it in other languages.
>                                             ^^^^^^^^^
> 
> How about specifices, since not many languages support
> this capability (C and C++ do not even have enumeration
> types in the sense in which we are discussing things now
> after all :-)

Objective Caml, since version 3.0, has something close, called
"polymorphic variants". It's not quite the same, since sum types 
aren't quite the same as enums, but probably close enough for 
comparison. In Ocaml, the new variants can act as anonymous tags.

One reason the comparison is tough is that since Ocaml doesn't have 
overloading, the polymorphic variants are justifiable IMO simply because 
they allow a kind of overloading of variants. There are some neat tricks 
you can do with them, like providing a visitor which can be extended
easily, but in my own Ocaml programming I've found that its the fact that 
I can overload variants that's the big win, and this is obviously not a 
problem with Ada. 

See

    http://caml.inria.fr/ocaml/htmlman/manual003.html

for some info on polymorphic variants, or find Jacques Garrigue's Olabl
page and check out his publications on the topic.

I think for any given feature that someone wants to add to Ada they should
be able to provide a small example, preferably something natural. For
instance, in the resubmitted AI for downward funargs someone mentioned a 
paper in "Software Practice and Experience" about combinatorial searching
or somesuch. Now, while that may be interesting, and the example I gave a
while ago about composing integrators is interesting, and likewise
backtracking parsers, I think the simple example of iterators that was
presented during the 9X process (you can see something like it in Barnes'
book) is really the best. Very simple, very natural, it seems like you
should be able to do it in Ada, but you can't. Examples of the withing
problem (soon to be OBE I hope!) are also pretty simple.  

-- Brian

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

[Robert Dewar]

In article
<Pine.BSF.4.21.0101201408160.16701-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Sat, 20 Jan 2001, Robert Dewar wrote:
> > In article <94ce27$rrb$1@news.cis.ohio-state.edu>,
> >   carroll@cis.ohio-state.edu (Mark Carroll) wrote:
> > > In article <t6jeim807fic0a@corp.supernews.com>,
> > > Jeff Creem <jeff@thecreems.com> wrote:
> > > (snip)
> > > >Whether the extra complexity this imposes on compiler
writes
> > (or language
> > > >learners) is worth the occasional
> > > >convenience is certainly debatable.
> > >
> > > FWIW, I certainly make use of it in other languages.
> >                                             ^^^^^^^^^
> >
> > How about specifices, since not many languages support
> > this capability (C and C++ do not even have enumeration
> > types in the sense in which we are discussing things now
> > after all :-)
>
> Objective Caml, since version 3.0, has something close,

Well er ... exactly my point, not to many people are using
Objective Caml in their everyday programming tasks. So my
question still stands, the claim was that this feature was
being used in other programming languages (in common use),
and I don't see that ...


Sent via Deja.com
http://www.deja.com/

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

[Brian Rogoff]

On Sun, 21 Jan 2001, Robert Dewar wrote:
> In article
> <Pine.BSF.4.21.0101201408160.16701-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > On Sat, 20 Jan 2001, Robert Dewar wrote:
> > > How about specifices, since not many languages support
> > > this capability (C and C++ do not even have enumeration
> > > types in the sense in which we are discussing things now
> > > after all :-)
> >
> > Objective Caml, since version 3.0, has something close,
> 
> Well er ... exactly my point, not to many people are using
> Objective Caml in their everyday programming tasks. So my
> question still stands, the claim was that this feature was
> being used in other programming languages (in common use),
> and I don't see that ...

Hmmph, I don't recall the "common/popular" qualifier in the original
question, and I thought we were trying to ascertain the utility of such 
a feature by looking at another language with the same or similar
features. The feature was added to Ocaml after it had proved its worth 
in OLabl, in particular for making the interfaces to some C libraries 
(like Tk and Gtk) more convenient. As I said, since Ada allows overloading
of enumeration names and OCaml didn't allow sum type "tag" overloading 
for the non-polymorphic variants, the argument for extending Ada is
significantly weaker than the argument for extending Ocaml with extensible 
variants.

I'd like to see the old proposals that you mention from the 9X process. It
is a shame that those documents are not more web friendly. 
 
As far as popularity goes, I bet OCaml is more widely used than many 
languages discussed here. Putting my C hat on, Ada is not very widely used
either, nor is SNOBOL, SETL, Modula-3, Oberon, ... . You'll have to define 
"in common use" more precisely, in order to keep Ada in that set and
others out ;-).

-- Brian

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

[Robert Dewar]

In article
<Pine.BSF.4.21.0101211432040.26405-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> Hmmph, I don't recall the "common/popular" qualifier in the
> original question

My message was not responding to you, it was responding to Mark
Caroll's (I hope I remember the name right) message saying that
he found this feature useful in his current programming. So I
asked him what language he was using, and after a bit of too
and fro, he realized he had got confused, and was not saying
what he meant to say.

So I was indeed looking for a common/popular language, since
that is clearly what his message implied, but as above, it
turns out there was a confusion, which does not surprise me,
because I definitely would find it unusual if some programmer
said they used this feature frequently and found it useful

(it would mean they were an afficionado of obscure languages
:-)


Sent via Deja.com
http://www.deja.com/

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

[Brian Rogoff]

On Mon, 22 Jan 2001, Robert Dewar wrote:
[... snip ...]
> because I definitely would find it unusual if some programmer
> said they used this feature frequently and found it useful
> 
> (it would mean they were an afficionado of obscure languages
> :-)

Well, everyone knew that about me already, since I've already admitted 
that I like Ada :-P

-- Brian

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

[Robert Dewar]

In article
<Pine.BSF.4.21.0101220800560.3395-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> Well, everyone knew that about me already, since I've already
> admitted  that I like Ada :-P

I think it is useful to distinguish between languages that are
in major production use, and languages that are basically
academic fiddling around :-)



Sent via Deja.com
http://www.deja.com/

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

[Brian Rogoff]

On Mon, 22 Jan 2001, Robert Dewar wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> 
> > Well, everyone knew that about me already, since I've already
> > admitted  that I like Ada :-P
> 
> I think it is useful to distinguish between languages that are
> in major production use, and languages that are basically
> academic fiddling around :-)

Ouch! What really hurts the most is that I use Ocaml at my (non-academic) 
job and I only fiddle around academically with Ada...

I think if you look at the field I work in, roughly "VLSI CAD", Ada is 
nowhere to be found in "major production use", but I know of a few places 
(admittedly researchy or "in house" SW) that use Ocaml. Counterexamples 
welcome....

-- Brian

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

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]


"Brian Rogoff" <bpr@shell5.ba.best.com> a �crit dans le message news: Pine.BSF.4.21.0101221306400.3395-100000@shell5.ba.best.com...
> I think if you look at the field I work in, roughly "VLSI CAD", Ada is
> nowhere to be found in "major production use", but I know of a few places
> (admittedly researchy or "in house" SW) that use Ocaml. Counterexamples
> welcome....
>
A couple of years ago, CNET in France has developped LOF4, a VLSI design program entirely in Ada.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: LOF4 (Was Re: Extensible Enummerated types)

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1889 bytes --]

On Thu, 25 Jan 2001, Jean-Pierre Rosen wrote:
> "Brian Rogoff" <bpr@shell5.ba.best.com> a écrit dans le message news: Pine.BSF.4.21.0101230839000.15065-100000@shell5.ba.best.com...
> >> A couple of years ago, CNET in France has developped LOF4, a VLSI
> >> design program entirely in Ada.
> >Was this program in "major production use"? Not much info on the net
> >about this program either.
> It was at least used internally by CNET, but as I mentionned, it was quite a long time ago. The main developpers have moved and
> formed their own company, LEDA, specialized in VHDL products. I don't know what happenned to LOF4.

It would be interesting to find out if the spinoff company still uses
Ada. Any ideas? Personally, I think Ada would be an excellent language for
EDA tools development, since it allows you to program at a very low level
when you need to and yet easily remains readable and safe. I suspect the 
best way to make progress in this market is to develop open source "point
tools". There is very little Ada knowledge amongst EDA programmers and I'm
afraid VHDL has a very bad reputation amongst chip designers I know.

> >If we want to go all the way to France to compare obscurity, I'm afraid
> >Ada will not come out ahead, since I know that there is a (French) O'Reilly
> >book on OCaml, but I don't think there is one for Ada ;-).
> We have excellent books on Ada in French, just different publishers... If you are intersted in these, please go to
> http://pro.wanadoo.fr/adalog/biblio1.htm

Oh, I have no doubt that there are excellent Ada books in French, and I'd
love to be able to buy a translation of your book into English. The joke 
is that no language is truly successful until there is an O'Reilly book
for it :-). 

BTW, I think you missed this French Ada book  :-)

http://caml.inria.fr/books-eng.html#cnam

-- Brian

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

[Mark Carroll]

In article <94coa2$v2v$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
(snip)
>How about specifices, since not many languages support
>this capability (C and C++ do not even have enumeration
>types in the sense in which we are discussing things now
>after all :-)

Modula-3 is probably an example of a reasonable starting point.
http://m3.polymtl.ca/m3/pkg/pm3/language/modula3/src/m3defn/ordinal.html
has some information. Is that the sort of thing that helps, or would you
like examples of code?

I don't have strong opinions as to how one might one to deal with
types that are 'subsets' or 'supersets' of a particular enumerated
type IYSWIM. I can see that it might be nice to deal with them, but
personally I don't usually have to.

-- Mark

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

[Robert Dewar]

In article <94d3q6$a8d$1@news.cis.ohio-state.edu>,
  carroll@cis.ohio-state.edu (Mark Carroll) wrote:
> In article <94coa2$v2v$1@nnrp1.deja.com>,
> Robert Dewar  <robert_dewar@my-deja.com> wrote:
> (snip)
> >How about specifices, since not many languages support
> >this capability (C and C++ do not even have enumeration
> >types in the sense in which we are discussing things now
> >after all :-)
>
> Modula-3 is probably an example of a reasonable starting
> point.

Are you answering my question and saying that Modula-3 already
has this capability? If so, OK, but I was unaware of this.

Or are you saying this is a reasonable starting point for the
design of such an extension?

If so, I disagree, certainly in this forum, the reasonable
starting point is the worked out Ada 95 feature that was
rejected.

Tuck, is that available in some retrievable and postable form?



Sent via Deja.com
http://www.deja.com/

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

[Mark Carroll]

In article <94f1ir$kkc$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
(snip)
>Are you answering my question and saying that Modula-3 already
>has this capability? If so, OK, but I was unaware of this.

Yes, it does, and moreover that it's a specific example of one of the
contexts in which I do find enumerated types useful; I was trying to
answer your question in which you ask for specifics of that.

>Or are you saying this is a reasonable starting point for the
>design of such an extension?
>
>If so, I disagree, certainly in this forum, the reasonable
>starting point is the worked out Ada 95 feature that was
>rejected.
(snip)

Certainly, I meant _a_ potential reasonable starting point, rather
than _the_ reasonable starting point. (-: I don't know much about Ada
95 yet: I just recently subscribed to this group, as I'm thinking of
porting some of our Modula-3 stuff to Ada 95.

-- Mark

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

[Robert Dewar]

In article <94fbrp$iou$1@news.cis.ohio-state.edu>,
  carroll@cis.ohio-state.edu (Mark Carroll) wrote:
> In article <94f1ir$kkc$1@nnrp1.deja.com>,
> Robert Dewar  <robert_dewar@my-deja.com> wrote:

> Yes, it does, and moreover that it's a specific example of
> one of the contexts in which I do find enumerated types
> useful; I was trying to answer your question in which you ask
> for specifics of that.


OK, what you posted did not illustrate type extension for these
types, it just seemed to describe enumerated types, and the
definition of subranges for these types.

So please enlighten how does Modula-3 handle extension of these
types in an object oriented context of type extension.




Sent via Deja.com
http://www.deja.com/

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

[Mark Carroll]

In article <94fd5s$tkh$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
(snip)
>OK, what you posted did not illustrate type extension for these
>types, it just seemed to describe enumerated types, and the
>definition of subranges for these types.
(snip)

Doh - sorry, you're absolutely right - I didn't read the thread
carefully enough, and misunderstood things. Apologies for the
confusion.

-- Mark

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

[Nick Roberts]

I like this idea. It seems to me that it could be really useful sometimes
(enough to justify it). It also seems to me that there would be no major
implementation problem. It would require a number of changes and insertions
to the RM, but nothing drastic. Gets my vote.

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


"Jeff Creem" <jeff@thecreems.com> wrote in message
news:t6jeim807fic0a@corp.supernews.com...
> ...
> There are of course other perfectly acceptable methods but at times it
would
> be cleaner to be able to do things like
>
> type Fruit_Type is (Apple, Orange);
> type New_Fruit_Type is new Fruit_Type with (Pear, Kiwi);
>
> A : Fruit_Type := Apple;
> B : New_Fruit_Type := New_Fruit_Type(A);
> ...

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

[Robert Dewar]

In article <94f9qf$dc4s7$1@ID-25716.news.dfncis.de>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> I like this idea. It seems to me that it could be really
useful sometimes
> (enough to justify it). It also seems to me that there would
be no major
> implementation problem. It would require a number of changes
and insertions
> to the RM, but nothing drastic. Gets my vote.

I assume you have studied the proposal in the mapping document
and it is to this proposal that you are referring.

If so, what new has happened that would justify reopening
the discussion.

Or do you have some additional technical insight here, i.e.
a suggestion for modification of this proposal that would
simplify it?


Sent via Deja.com
http://www.deja.com/

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

[Mark Lundquist]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:94fdqb$u4b$1@nnrp1.deja.com...
> In article <94f9qf$dc4s7$1@ID-25716.news.dfncis.de>,
>   "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> > I like this idea. It seems to me that it could be really
> useful sometimes
> > (enough to justify it). It also seems to me that there would
> be no major
> > implementation problem. It would require a number of changes
> and insertions
> > to the RM, but nothing drastic. Gets my vote.
>
> 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).

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);

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

- mark

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

[Randy Brukardt]

Mark Lundquist wrote in message <94hr7f$oa0$1@usenet.rational.com>...

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

The entire AI database is on-line at www.ada-auth.org/~acats. What do
you want that isn't there?

The individual AIs live in the CVS version control system, so it is
possible to retrieve old versions as well as the current ones. (This is
a capability that I wish was available going much further back, as it
would cut off some silly discussions quickly.)

The files are text files; converting them to useful HTML is non-trivial.
I tried writing a program to do it for the defect reports, but it took a
lot of tweaking of both the program and the AIs to get it to handle a
subset of the content of that subset of AIs. Doing it in general
(especially the e-mail found at the end) is virtually impossible. (Of
course, just converting the files to HTML without adding any formatting
or links would be worthless, as it would not add any value.)

    Randy Brukardt
    ARG Editor

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

[Matthew Woodcraft]

Randy Brukardt writes:

> Mark Lundquist wrote in message <94hr7f$oa0$1@usenet.rational.com>...
> 
>>(Someone has also said that it would
>>be nice if the AI database were more Web-friendly, and I concur).
> 
>The entire AI database is on-line at www.ada-auth.org/~acats. What do
>you want that isn't there?

Well, a version of AI-SUMMARY.DOC with html links to the head revision
of each AI would be very nice...

-M-

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)

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

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Tucker Taft et al.

I followed your directions, "Compressed versions of these documents may be
found at:"

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

I found 3 compressed postscript files, which I have now transformed into PDF
files.

Ada 9X Snapshot of Mapping Specification Prior to Revision, Version 4.6,
5 June 1992, IR-MA-1250-3

Ada 9X Mapping Volume II Mapping Specification and Rationale (Annexes)
Abridged, Version 4.1, 4 March 1992, IR-MA-1250-3

Ada 9X Mapping Volume I Mapping Rationale, Version 4.1, 4 March 1992,
IR-MA-1249-2

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

I could not find any occurrences of "Why Ada?" or of "enumerated" pertaining
to the extension of enumerated types in any of the three documents.

If anyone wants the PDF versions, I can send them as e-mail attachments.

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

[Vincent Marciante]

Robert C. Leif, Ph.D. wrote:
> 
> If anyone wants the PDF versions, I can send them as e-mail > > attachments.

What is their size?

Vinny

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]
======================================================================

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

[Nick Roberts]

Following the lead from another poster to this thread, my proposal (and I
think this is what the other poster intended) involves no tagging, but is
simply as follows. I believe this proposal would be doable and valuable.

Let's start with a normal enumeration type declaration, in unit PC_Keyboard:

   type Key_Value is (A_Key, B_Key, ..., Scroll_Lock);

My proposal is that you can make an 'enumeration extension declaration' in
any declarative region (AT_Keyboard, say) that has visibility of
PC_Keyboard.Key_Value, perhaps like this:

   type Key_Value is new PC_Keyboard.Key_Value with (F11, F12, ...);

Type AT_Keyboard.Key_Value would be in essence an ordinary enumerated type,
with all the values of PC_Keyboard.Key_Value plus the extra ones specified
(positionally appended). There would be no tag or special indexing. Any
representation clause could be applied to it (e.g. changing its size or
internal codes). It may need to be made a bigger size (by the compiler if
not explicitly) as a result of having more values.

One extra rule would be that if PC_Keyboard.Key_Value had an enumeration
representation clause (defining its internal codes), then the compiler would
demand that AT_Keyboard.Key_Value had one as well (which would have to be
comprehensive). I believe the rule (in RM95 13.4(6)) which forces the
internal codes to obey the predefined ordering relation should be removed
(the compiler would, again, have to use a lookup table if necessary, tough).

Some operations would be redefined or added.

Conversion from PC_Keyboard.Key_Value to AT_Keyboard.Key_Value would pose no
problems (a change of representation may require actual conversion, but this
is something Ada already supports).

Conversion the other way would also be supported, and would include a check
that the value being converted lay within the set of values defined for
PC_Keyboard.Key_Value (which would raise Constraint_Error if it failed).

There would be overloadings of the "in" operator which allowed a test for a
value of one type against a range of the other type, or any subtype thereof.

The other operations would all be exactly the same.

Plainly, this example declares some extra keys for an AT keyboard, implying
that an AT keyboard has at least all the same keys as a PC keyboard. It is
better than explicitly redefining all the many PC keys, since there is
clearly room for an error creeping in there. It's a better model against the
real world. It also simplifies the conversion from one type to another,
possibly eliminating another source of error. The implementation would be
exactly the same as if one had defined all the values for
AT_Keyboard.Key_Value explicitly, apart from the new and different
operations (whose implementations are straightforward), and the extra simple
rule. QED.

PS: Yes I realise that there's not going to be a revision so this kind of
idle speculation is pointless, and yes I realise people with nohing better
to do ;-) will have a field day picking it apart. Sigh.

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

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

[Robert Dewar]

In article <95ctlj$ff437$1@ID-25716.news.dfncis.de>,
  "Nick Roberts" <nickroberts@callnetuk.com> wrote:
> PS: Yes I realise that there's not going to be a revision so
> this kind of idle speculation is pointless, and yes I realise
> people with nohing better to do ;-) will have a field day
> picking it apart. Sigh.

This is a misconception, no one could say at this stage when
the next revision of the Ada standard might be, but in any case
well conceived proposals can be considered as amendment AI's
by the ARG right now, without waiting for a new revision to be
in view. I will not comment on whether I consider this
particular proposal to be well conceived, I will leave that
to others.


Sent via Deja.com
http://www.deja.com/

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

[Jeffrey Carter]

Robert Dewar wrote:
> This is a misconception, no one could say at this stage when
> the next revision of the Ada standard might be, but in any case
> well conceived proposals can be considered as amendment AI's
> by the ARG right now, without waiting for a new revision to be
> in view. I will not comment on whether I consider this
> particular proposal to be well conceived, I will leave that
> to others.

Come, now, there are few people better qualified to make such comments
than Robert Dewar.

Nick Roberts' proposal is essentially the same as mine. I don't consider
it a big deal one way or the other. I don't agree with removing the
ordering constraint on enumerated types.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

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

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Jeff Carter et al.

I certainly agree. I too believe that the ordering constraint on enumerated
types should be retained. Robert Dewar wrote, "well conceived proposals can
be considered as amendment AI's by the ARG right now, without waiting for a
new revision to be in view."

I believe that they ARG should create alpha and beta versions of Ada 0y
prior to finalizing the standard. This would permit a good number of us to
use and to test them. The safety critical and other specialized needs users
should have a means to guarantee that they were not included in their Ada
source. The compiler could have a switch, with the default being pure Ada
95.

I suspect that the ARGs error-rate will be sufficiently low, that any final
changes would at most be be minor. In the case of an extensible enumerated
type, the effects of possible changes in the syntax can be minimized by
creation of a subprogram (method). This subprogram would create a string
that includes all of the items in an enumerated type or an extended
enumerated type. This list of items will significantly facilitate repairs in
the unlikely event that they are needed and help with maintenance.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Jeffrey Carter
Sent: Thursday, February 01, 2001 8:41 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Extensible Enummerated types FW: When will next Ada
revision be? (83, 95, ?)


Robert Dewar wrote:
> This is a misconception, no one could say at this stage when
> the next revision of the Ada standard might be, but in any case
> well conceived proposals can be considered as amendment AI's
> by the ARG right now, without waiting for a new revision to be
> in view. I will not comment on whether I consider this
> particular proposal to be well conceived, I will leave that
> to others.

Come, now, there are few people better qualified to make such comments
than Robert Dewar.

Nick Roberts' proposal is essentially the same as mine. I don't consider
it a big deal one way or the other. I don't agree with removing the
ordering constraint on enumerated types.

--
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

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

[Robert Dewar]

In article <mailman.981098883.32366.comp.lang.ada@ada.eu.org>,
  comp.lang.ada@ada.eu.org wrote:
> From: Bob Leif
> To: Jeff Carter et al.

<<Bob's suggestions on how the ARG should proceed snipped>>

Bob, it seems like you are writing this without first finding
out what is going on right now, which might be a good idea,
since this procedure has been discussed and agreed on, and
is being actively used now, and is unlikely to change without
some very good arguments.

The current procedure is the following. For language extensions
an "amendment" class AI is prepared, this is processed by the
ARG into a fully formed, fully worked out, language extension
proposal which is then approved by the ARG, and subsequently
by WG-9.

Vendors are then free to implement these extensions. It is
typically likely that at least one vendor will do so, since
if it is the case that no vendors see any value in implementing
a feature (considering their customer needs), the proposal
is unlikely to fly in the first place.

The idea is that eventually any revision of Ada might include
some or all of these extensions in either their unmodfied form,
or perhaps a modified form (like the rest of the language at
that stage, they would be subject to revision).

In terms of the existing features in the language, as you know
a corrigendum has already been approved that would of course
be the starting point for a new standard.

In the case of this particular proposal (on which I have not
commented simply because I have seen no good argument for its
utility (it would be nice to see a convincing example of an
application that would benefit from this proposal, rather than
simply language proposals), the proper approach is to convince
at least one member of the ARG to prepare an AI, or
alternatively prepare a complete AI, and submit it for
consideration.


Sent via Deja.com
http://www.deja.com/

(Private message. Sorry)

[Nick Roberts]

Bob, I hope you don't mind me putting this on Usenet, but you e-mailed me
some interesting comments (about AdaOS) quite a while back, but when I tried
sending a reply, your mailserver (I assume) kept rejecting it. I suspect
this was because I changed my e-mail address in the interim (silly of me).

Anyway, I hope you don't think I was being rude or anything. We were locking
horns most satisfactorily in respect of a number of issues (GPL versus
commercial, CORBA versus Annex E, borrowing from Oberon) and I was
disappointed to be caused to leave off.

Maybe we can resume contact?

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

PS: Hope this isn't taken to be heinous waste of bandwidth.

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

[Ted Dennison]

In article <mailman.979975693.13263.comp.lang.ada@ada.eu.org>,
  comp.lang.ada@ada.eu.org wrote:
> I believe that at one time you mentioned the possibility of extending
> an enumerated type. This would greatly facilitate object oriented
> programming. For instance, I have created a Person_Names package. The

Why can't you use the class' tag for that purpose?

--
T.E.D.

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


Sent via Deja.com
http://www.deja.com/

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

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Ted Dennison et al.

There actually is a class 'tag in the program. Unfortunately, it does NOT
solve the problem.
----------------------------------------
with Ada.Text_Io;
generic
   type Enum_Type is (<>);
   type Info_Type is private;
package Generic_Rec_W_Enum_Part_Pkg is
   type Enum_Rec_Type is tagged record
      Enum_Part : Enum_Type;
      Info_Part : Info_Type;
   end record;

--This is instantiated

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

package Prefix_Recs is new Generic_Rec_W_Enum_Part_Pkg
    (Enum_Type => Prefix_Type,
    Info_Type => Prefix_Bd_Type); --15 character bounded_string.

subtype Prefix_Rec_Type is Prefix_Recs.Enum_Rec_Type;

None_Rec : constant Prefix_Rec_Type := (None, Null_Prefix_Suffix_Bd);
  Mr_Rec   : constant Prefix_Rec_Type := (Mr,To_Bd("Mr."));
  Ms_Rec   : constant Prefix_Rec_Type := (Ms,To_Bd("Ms."));
  Miss_Rec : constant Prefix_Rec_Type := (Miss,To_Bd("Miss"));
  Mrs_Rec  : constant Prefix_Rec_Type := (Mrs,To_Bd("Mrs."));
  Dr_Rec   : constant Prefix_Rec_Type := (Dr,To_Bd("Dr."));
  Prof_Rec : constant Prefix_Rec_Type := (Prof,To_Bd("Prof."));
  Rev_Rec  : constant Prefix_Rec_Type := (Rev,To_Bd("Rev."));
  Other_Rec : Prefix_Rec_Type := (Enum_Part => Other,
    Info_Part => To_Bd("Other"));

The addition of a new type (field) to Prefix_Rec_Type does not permit
addition of new objects of Prefix_Rec_Type; because, Prefix_Rec_Type is
limited by the number of items in the enumerated type Prefix_Type.

The only obvious way to solve this problem is to permit the extension of
Prefix_Type by the addition of new enumerated values. I had to circumvent
the enumeration by including "Other". The use of Other significantly
decreases the capacity of monitoring membership in the set of an enumerated
type. Although my suggestion will require effort on the part of compiler
vendors, I believe that it will aid the programmers.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Ted Dennison
Sent: Monday, January 22, 2001 7:02 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Extensible Enummerated types FW: When will next Ada
revision be? (83, 95, ?)


In article <mailman.979975693.13263.comp.lang.ada@ada.eu.org>,
  comp.lang.ada@ada.eu.org wrote:
> I believe that at one time you mentioned the possibility of extending
> an enumerated type. This would greatly facilitate object oriented
> programming. For instance, I have created a Person_Names package. The

Why can't you use the class' tag for that purpose?

--
T.E.D.

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


Sent via Deja.com
http://www.deja.com/

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

[Nick Roberts]

Robert Leif's example seems to lead to a slightly hairier alternative (to
the simple proposal I made, unwittingly on behalf of Jeff Carter
apparently). Here, an enumerated type declaration, either a standard one,
e.g.:

   type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev);

or a special one, e.g.:

   type Prefix_Type is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev) with others;

declares a type which actually has more values (e.g. 256 or 65536) than are
specified. A size representation clause could be used to ensure a big enough
number are available. The first named subtype Prefix_Type denotes only the
declared values, as if the following had been declared:

   type {anon} is (None, Mr, Ms, Miss, Mrs, Dr, Prof, Rev);
   subtype Prefix_Type is {anon} range None..Rev;

so most things work as for current Ada. The other values have no designators
(but, I suppose, can still be referenced by using Val). A special kind of
declaration can then declare identifiers (or character literals) for these
values (starting at the first vacant position), e.g.:

   subtype New_Prefix_Type is Prefix_Type with (Guru, Ustad);

The new subtype New_Prefix_Type denotes the full new range None..Ustad. Note
how this allows multiple names to be declared for the same values:

  subtype My_Prefix_Type is Prefix_Type with (Master, Maestro);

It may be that an enumeration representation clause must be disallowed for
this kind of enumeration type. It may also be that the [Wide_]Image and
[Wide_]Value attributes must also be disallowed for such a type and any of
its subtypes.

Anyone saluting this alternative?

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

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