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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5b0235b23a9db0f2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-30 08:17:42 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!logbridge.uoregon.edu!news.bu.edu!inmet!not-for-mail From: Tucker Taft Newsgroups: comp.lang.ada Subject: Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?) Date: Tue, 30 Jan 2001 11:17:39 -0500 Organization: AverStar (formerly Intermetrics) Burlington, MA USA Message-ID: <3A76E923.318F7C1E@averstar.com> References: <94c61v$h4a$1@nnrp1.deja.com> <94f9qf$dc4s7$1@ID-25716.news.dfncis.de> <94fdqb$u4b$1@nnrp1.deja.com> <94hr7f$oa0$1@usenet.rational.com> NNTP-Posting-Host: nebula.burl.averstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: inmet2.burl.averstar.com 980871460 22478 141.199.8.77 (30 Jan 2001 16:17:40 GMT) X-Complaints-To: usenet@inmet2.burl.averstar.com NNTP-Posting-Date: 30 Jan 2001 16:17:40 GMT X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:4711 Date: 2001-01-30T16:17:40+00:00 List-Id: Mark Lundquist wrote: > > Robert Dewar 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)