Re: Modernizing Ada

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (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