* Re: Modernizing Ada
@ 1989-10-13 20:28 Erland Sommarskog
1989-10-14 19:13 ` Adding Multiple Inheritance (was: Modernizing Ada) Ron Guilmette
1989-10-14 20:50 ` Modernizing Ada William Thomas Wolfe, 2847
0 siblings, 2 replies; 10+ messages in thread
From: Erland Sommarskog @ 1989-10-13 20:28 UTC (permalink / raw)
Bill Wolfe writes:
>Tucker Taft (stt@inmet) writes:
>> Here is the wording from the Ada9x project plan:
>> A revision requirement that does not meet the "upward compatibility"
>> criteria will only be considered if it affects a very large
>> portion of the Ada community and its absence in the
>> revised standard has a serious negative impact on application development.
>
> Multiple inheritance, for example, meets both criteria and therefore
> should be considered regardless of whether or not upward compatibility
> is affected. Every effort must be made to minimize the difficulty of
> the transition, but not at the expense of capabilities which are vital
> to the modernization of our software engineering technology.
It's not that I have anything against multiple inheritance, rather
the opposite, but I'm not 100% sure that it should be included in
Ada 9X. It would like throwing the yeast into the oven while the
bread is baking.
It's easy to say "multiple inheritance" but it should be
implemented too. And I'm not talking compiler technology here.
My issue is the langauge definition. The inheritance mechanism
should integrated with existing constructs in Ada. Say that you add
classes a new compilation unit to Ada. Easy? Yes, but why then
keep packages? OK, make the classes package types, but somehow
I feel that we will ending up having something in the langauge
that will be obsolete once we have a inheritance mechanism, multiple
or not.
And, by the way, isn't there a very simple reason why Ada don't
have inhertiance and dynamic binding today? Wasn't that explicitly
forbidden in the requirements? Have the requirements changed?
(Well, that's not unlikely, because it was not a sound requirement.)
Getting inheritance into Ada would give us an Ada++ with the
same advantages and disadvantages as C++. Compatible, but at the
cost of keeping constructs that shouldn't be there.
It is possible that the refusal to accept inheritance in Ada
way back in 1980 will mean that Ada never becomes the star
as intened. But that might as will be the case if we exclude
inheritance from 9X or if we include it. In the latter case
because the language gets too large with redundant features.
All this said with the following reservation: I haven't seen
any concrete proposal on how an inheritance mechanism in Ada
should be look like. Therefore is my discussion on the consequences
on such a construct somewhat hypothetical, but so is everybody
else's too.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"My baby's a 26. On a scale from one to ten, my baby's a 26." - Chic
^ permalink raw reply [flat|nested] 10+ messages in thread
* Adding Multiple Inheritance (was: Modernizing Ada) 1989-10-13 20:28 Modernizing Ada Erland Sommarskog @ 1989-10-14 19:13 ` Ron Guilmette 1989-10-14 20:38 ` Edward Berard 1989-10-15 1:16 ` Dik T. Winter 1989-10-14 20:50 ` Modernizing Ada William Thomas Wolfe, 2847 1 sibling, 2 replies; 10+ messages in thread From: Ron Guilmette @ 1989-10-14 19:13 UTC (permalink / raw) In article <8910132028.AA07013@helios.enea.se> sommar@enea.se (Erland Sommarskog) writes: > It's easy to say "multiple inheritance" but it should be >implemented too. And I'm not talking compiler technology here. >My issue is the langauge definition. The inheritance mechanism >should integrated with existing constructs in Ada. Say that you add >classes a new compilation unit to Ada. Easy? Yes, but why then >keep packages? OK, make the classes package types, but somehow ^^^^^^^^^^^^^ >I feel that we will ending up having something in the langauge >that will be obsolete once we have a inheritance mechanism, multiple >or not. >All this said with the following reservation: I haven't seen >any concrete proposal on how an inheritance mechanism in Ada >should be look like. Therefore is my discussion on the consequences >on such a construct somewhat hypothetical, but so is everybody >else's too. Well... I know that I'm definitely *not* the only one to have started to think about how to munge MI into Ada, and I may just be putting my foot in my mouth here, but I wonder if anybody here would like to start discussing the pros and cons of various schemes for adding MI to Ada. The addition of PACKAGE TYPES (kinda like task types, only different) seems like a nice way to add the notion of CLASSES without adding another keyword. Seems to me like the syntax & semantics of member references should just fall out also. If we just added a statement called "inherit" then we would be in business. For instance: package type PT_1 is procedure FOO; end PT_1; package type PT_2 is type PT_2_TYPE is private; private type PT_2_TYPE is ...; end PT_2; with PT_1, PT_2; package type PT_3 is inherit PT_1 as PART_1; inherit PT_1 as PART_2; inherit PT_2 as PART_3; VAR : INTEGER; procedure MEMBER_PROC (I : INTEGER); end PT_3; procedure USE_THEM is begin THREE_VAR : PT_3; WEIRD : PT_3.PART_3.PT_2_TYPE; -- private type ... THREE_VAR.VAR := 99; THREE_VAR.MEMBER_PROC (99); THREE_VAR.PART_2.FOO := 99; end USE_THEM; Any comments? // rfg ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Multiple Inheritance (was: Modernizing Ada) 1989-10-14 19:13 ` Adding Multiple Inheritance (was: Modernizing Ada) Ron Guilmette @ 1989-10-14 20:38 ` Edward Berard 1989-10-15 20:57 ` Scott Simpson 1989-10-15 1:16 ` Dik T. Winter 1 sibling, 1 reply; 10+ messages in thread From: Edward Berard @ 1989-10-14 20:38 UTC (permalink / raw) Ron Guilmette (rfg@ics.uci.edu) writes: > sommar@enea.se (Erland Sommarskog) writes: > > It's easy to say "multiple inheritance" but it should be > >implemented too. And I'm not talking compiler technology here. > >My issue is the langauge definition. The inheritance mechanism > >should integrated with existing constructs in Ada. Say that you add > >classes a new compilation unit to Ada. Easy? Yes, but why then > >keep packages? OK, make the classes package types, but somehow [...] ... > > >All this said with the following reservation: I haven't seen > >any concrete proposal on how an inheritance mechanism in Ada > >should be look like. [...] ... > > Well... I know that I'm definitely *not* the only one to have started to > think about how to munge MI into Ada, and I may just be putting my foot > in my mouth here, but I wonder if anybody here would like to start > discussing the pros and cons of various schemes for adding MI to Ada. > > The addition of PACKAGE TYPES (kinda like task types, only different) > seems like a nice way to add the notion of CLASSES without adding another > keyword. [...] ... > [...] ... > // rfg For those of you who are interested, there is a small group of individuals who are working to formally suggest object-oriented extensions to the Ada language. They held a three-day meeting in the Boston, Mass. area during September. For more information, contact Rich Hilliard at MITRE: E-mail : rh@mbunix.mitre.org Office : The MITRE Corporation MS A155 Bedford, MA 01730 TELEPHONE : (617) 271-7760 The time for revision suggestions for Ada 9X is almost over. If you think you have any good ideas, be quick about it. -- Ed Berard (301) 353-9652 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Multiple Inheritance (was: Modernizing Ada) 1989-10-14 20:38 ` Edward Berard @ 1989-10-15 20:57 ` Scott Simpson 0 siblings, 0 replies; 10+ messages in thread From: Scott Simpson @ 1989-10-15 20:57 UTC (permalink / raw) In article <604@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >For those of you who are interested, there is a small group of >individuals who are working to formally suggest object-oriented >extensions to the Ada language. I know of two such existing extensions already (I'm sure Ed has heard of these): Classic Ada from Software Productivity Solutions (SPS@radc-softvax.arpa). DRAGOON from a European consortium. A guy from DRAGOON came out and spoke to us. DRAGOON is targeted at distributed systems and supports assertions. I'm sure I have left some other extensions out. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding Multiple Inheritance (was: Modernizing Ada) 1989-10-14 19:13 ` Adding Multiple Inheritance (was: Modernizing Ada) Ron Guilmette 1989-10-14 20:38 ` Edward Berard @ 1989-10-15 1:16 ` Dik T. Winter 1 sibling, 0 replies; 10+ messages in thread From: Dik T. Winter @ 1989-10-15 1:16 UTC (permalink / raw) In article <1989Oct14.121338.1316@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> writes: I must be extremely dense, but what is wrong if we modify it as follows (and get proper Ada on the fly)? (Lines marked + are added; lines marked - are deleted.) - package type PT_1 is + generic package PT_1 is procedure FOO; end PT_1; - package type PT_2 is + generic package PT_2 is type PT_2_TYPE is private; private type PT_2_TYPE is ...; end PT_2; with PT_1, PT_2; - package type PT_3 is + generic package PT_3 is - inherit PT_1 as PART_1; + PART_1 is new PT_1; - inherit PT_1 as PART_2; + PART_2 is new PT_1; - inherit PT_2 as PART_3; + PART_3 is new PT_2; VAR : INTEGER; procedure MEMBER_PROC (I : INTEGER); end PT_3; + with PT3; procedure USE_THEM is begin - THREE_VAR : PT_3; + THREE_VAR is new PT_3; - WEIRD : PT_3.PART_3.PT_2_TYPE; -- private type + WEIRD : THREE_VAR.PART_3.PT_2_TYPE; ... THREE_VAR.VAR := 99; THREE_VAR.MEMBER_PROC (99); THREE_VAR.PART_2.FOO := 99; end USE_THEM; The only distinction is that THREE_VAR is not a variable, but a package. It is long ago that I did something with Simula-67, and also I do not follow closely the buzz-word discussion. In any case what this proposer attempted to get into Ada 9X is already possible in Ada 83, unless I am very obtuse indeed. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Modernizing Ada 1989-10-13 20:28 Modernizing Ada Erland Sommarskog 1989-10-14 19:13 ` Adding Multiple Inheritance (was: Modernizing Ada) Ron Guilmette @ 1989-10-14 20:50 ` William Thomas Wolfe, 2847 1989-10-15 9:54 ` Richard O'Keefe 1 sibling, 1 reply; 10+ messages in thread From: William Thomas Wolfe, 2847 @ 1989-10-14 20:50 UTC (permalink / raw) From sommar@enea.se (Erland Sommarskog): > My issue is the langauge definition. The inheritance mechanism > should integrated with existing constructs in Ada. Say that you add > classes a new compilation unit to Ada. Easy? Yes, but why then > keep packages? OK, make the classes package types, but somehow > I feel that we will ending up having something in the langauge > that will be obsolete once we have a inheritance mechanism, multiple > or not. Actually, there are a lot of things which seem "scattered" when one starts thinking about expressing even user-defined types in Ada, regardless of whether inheritance is present or not. For example, currently the language defines attributes for predefined types, and implementations may also define attributes, but a user-defined type can't define its own attributes. The result is that one has to use operations over the type to do "synthetic" attributes. But now we have an inconsistency: for the predefined types we can use the attribute notation (which is actually rather common in object-oriented languages), and all is well. But for the "synthetic" attributes, we must use the subprogram call notation. Why is there this scattering of the attribute concept across the syntax for attributes and the syntax for subprograms? For its time, Ada was an outstanding design, but it seems that the object-oriented concepts were still a little fuzzy and not completely integrated. Properly integrating the various constructs would result in a clean, crisp 9X which will not be subject to the great criticisms of excessive complexity which have plagued Ada 83; if this is done, 9X will be a heck of a lot easier to learn (and adopt) than 83 was. Jean Ichbiah, in "Ada: Past, Present, Future" (CACM, October 1984) commented on the criticism of excessive complexity that regardless of the number of details, complexity depends upon "whether or not it is easy to infer the details from major structural lines"; quite true, but there is some simplification and integration that could be done with these structural lines to make a cleaner product. IMHO, it is probably possible to add multiple inheritance to Ada without cleaning up what in certain areas is a fragmented design, just as it is possible to let that original fragmentation persist. However, the results won't be pretty, and we have an opportunity before us to correct errors of commission as well as of omission. More importantly, though, it will demonstrate Ada's will to survive. COBOL, had it been willing to update itself properly, would over time have turned into what Ada is today (more or less); believe it or not, COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" motives that Ada started with!! Because of COBOL's demonstrated inability to change with the times, the DoD decided to just scrap COBOL completely and start over. I would hope that this fate is not in store for Ada as well. We already are going to have to solve substantial problems with the tasking model, handle the impact of asynchronous exceptions, etc., and there is enough change needed already to ensure that we have every incentive to act now. As long as progress continues to be made in software engineering technology, we cannot stand still. Our inertia must always be a *forward* inertia -- the tendency to keep advancing. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Modernizing Ada 1989-10-14 20:50 ` Modernizing Ada William Thomas Wolfe, 2847 @ 1989-10-15 9:54 ` Richard O'Keefe 1989-10-15 17:44 ` COBOL (Was: Modernizing Ada; now moving to comp.lang.misc) William Thomas Wolfe, 2847 0 siblings, 1 reply; 10+ messages in thread From: Richard O'Keefe @ 1989-10-15 9:54 UTC (permalink / raw) In article <6780@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" > motives that Ada started with!! Because of COBOL's demonstrated > inability to change with the times, the DoD decided to just scrap > COBOL completely and start over. COBOL has changed *dramatically* with time. Successive COBOL standards have not merely added new things (like nested programs, terminators on compound statements, new statements) but have also discarded old things (like the ALTER statement). The main complaint that I have heard from COBOL users is that new standards change too much too fast; adapting to a new standard is not just a matter of recompling. In fact there is no shortage of companies that make a living converting other people's old COBOL programs to new standards. COBOL is guilty of a lot of things, but not of standing still. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: COBOL (Was: Modernizing Ada; now moving to comp.lang.misc) 1989-10-15 9:54 ` Richard O'Keefe @ 1989-10-15 17:44 ` William Thomas Wolfe, 2847 1989-10-16 3:50 ` Richard O'Keefe 0 siblings, 1 reply; 10+ messages in thread From: William Thomas Wolfe, 2847 @ 1989-10-15 17:44 UTC (permalink / raw) From ok@cs.mu.oz.au (Richard O'Keefe): > COBOL has changed *dramatically* with time. Successive COBOL standards > have not merely added new things (like nested programs, terminators on > compound statements, new statements) but have also discarded old things > (like the ALTER statement). Oh, come on. How about recursion? How about generics? How about multitasking? Are you seriously suggesting that COBOL has made more than a shabby pretense of keeping up with the technology of software engineering? These are band-aids, which totally disregard the many fundamental problems that COBOL has been steadfastly ignoring for decades. (Followups to comp.lang.misc...) Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: COBOL (Was: Modernizing Ada; now moving to comp.lang.misc) 1989-10-15 17:44 ` COBOL (Was: Modernizing Ada; now moving to comp.lang.misc) William Thomas Wolfe, 2847 @ 1989-10-16 3:50 ` Richard O'Keefe 1989-10-17 0:46 ` Modernization William Thomas Wolfe, 2847 0 siblings, 1 reply; 10+ messages in thread From: Richard O'Keefe @ 1989-10-16 3:50 UTC (permalink / raw) In article <6783@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > From ok@cs.mu.oz.au (Richard O'Keefe): > > COBOL has changed *dramatically* with time. > Oh, come on. How about recursion? How about generics? How about > multitasking? Are you seriously suggesting that COBOL has made more > than a shabby pretence of keeping up with the technology of software > engineering? This is a very strange form of argument. Has Fortran 8X got multitasking? Nope. Is Fortran 8X dramatically changed from Fortran 77? Yes. Wolfe's original claim was COBOL has stood absolutely still therefore DoD has abandoned it. Nothing could be further from my mind than to suggest that COBOL is an advanced language or that it has generics or multitasking (although the COBOL I used back in the 70's did have multitasking). My points are: COBOL has not stood absolutely still; It has in fact changed fast enough to hurt COBOL users. The reason for mentioning this in comp.lang.ada (other than to correct a false claim about COBOL's stasis) is the second point. Converting from one COBOL standard to the next is seldom just a matter of recompiling. I repeat, there are companies that make large sums of money converting other people's programs from (old) COBOL to (new) COBOL. Do we really want that to happen to Ada? If there turn out to be compelling reasons for the Ada 8X -> Ada 9Y transition to require more than recompilation, would it be possible to require an Ada 9Y compiler vendor to provide a validated conversion tool for 8X? Not necessarily a tool to do all the conversion, but at least one to indicate all the places where changes are needed. It is particularly important to detect the parts of a program which will pass syntax and semantics checking in a 9Y compiler but do something different ("quiet changes", to use the X3J11 term). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Modernization 1989-10-16 3:50 ` Richard O'Keefe @ 1989-10-17 0:46 ` William Thomas Wolfe, 2847 0 siblings, 0 replies; 10+ messages in thread From: William Thomas Wolfe, 2847 @ 1989-10-17 0:46 UTC (permalink / raw) From ok@cs.mu.oz.au (Richard O'Keefe): > Wolfe's original claim was > COBOL has stood absolutely still I didn't say "absolutely"; as you noted in your original article, several relatively trivial changes have been made. > therefore DoD has abandoned it. > Nothing could be further from my mind than to suggest that COBOL is an > advanced language or that it has generics or multitasking (although the > COBOL I used back in the 70's did have multitasking). My points are: > COBOL has not stood absolutely still; > It has in fact changed fast enough to hurt COBOL users. > [...] Converting from one COBOL standard to the next is seldom just a > matter of recompiling. I repeat, there are companies that make > large sums of money converting other people's programs from (old) > COBOL to (new) COBOL. Perhaps this has something to do with COBOL not having the equivalent of Ada's pragma Interface, which itself is another example of a needed reform. > Do we really want that to happen to Ada? If there turn out to be > compelling reasons for the Ada 8X -> Ada 9Y transition to require > more than recompilation, would it be possible to require an Ada 9Y > compiler vendor to provide a validated conversion tool for 8X? As mentioned earlier, I think there have been at least rumblings to the effect that the US Government would order a translator built, and then make it freely available via the Ada Software Repository. I would think it safe to assume that AJPO will do an outstanding job of making the transition run smoothly; undoubtedly there will be considerable opportunities for the discussion of issues and the development of transition strategies, tools, and techniques, probably advancing software engineering technology considerably in the process. Bill Wolfe, wtwolfe@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1989-10-17 0:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1989-10-13 20:28 Modernizing Ada Erland Sommarskog 1989-10-14 19:13 ` Adding Multiple Inheritance (was: Modernizing Ada) Ron Guilmette 1989-10-14 20:38 ` Edward Berard 1989-10-15 20:57 ` Scott Simpson 1989-10-15 1:16 ` Dik T. Winter 1989-10-14 20:50 ` Modernizing Ada William Thomas Wolfe, 2847 1989-10-15 9:54 ` Richard O'Keefe 1989-10-15 17:44 ` COBOL (Was: Modernizing Ada; now moving to comp.lang.misc) William Thomas Wolfe, 2847 1989-10-16 3:50 ` Richard O'Keefe 1989-10-17 0:46 ` Modernization William Thomas Wolfe, 2847
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox