Re: Modernizing Ada

Re: Modernizing Ada

[Erland Sommarskog]

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

Adding Multiple Inheritance (was: Modernizing Ada)

[Ron Guilmette]

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

Re: Adding Multiple Inheritance (was: Modernizing Ada)

[Edward Berard]

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

Re: Adding Multiple Inheritance (was: Modernizing Ada)

[Scott Simpson]

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)

Re: Adding Multiple Inheritance (was: Modernizing Ada)

[Dik T. Winter]

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

Re: Modernizing Ada

[William Thomas Wolfe, 2847]

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

Re: Modernizing Ada

[Richard O'Keefe]

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.

Re: COBOL (Was: Modernizing Ada; now moving to comp.lang.misc)

[William Thomas Wolfe, 2847]

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

Re: COBOL (Was: Modernizing Ada; now moving to comp.lang.misc)

[Richard O'Keefe]

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

Re: Modernization

[William Thomas Wolfe, 2847]

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