Re: How to make Ada a dominant language

[Lao Xiao Hai <laoxhai@ix.netcom.com>]

This has been an entertaining discussion.    There are several points that
Russ makes that deserve some careful response.    Some earlier messages
covered some of the points.   Most of those responses dealt with the
syntactic issues.   I choose to respond to his "with" / "use" observation
since this is at the heart of Ada's design.   As a prefatory
remark, we note that the default of every Ada construct intended to
be safe.  One can take a default of safe and relax it to a construct that
is less safe.  It is more difficult in a language where the default is
unsafe,
to promote a construct to one that is more safe.

Chapter Eight of the Ada Language Reference Manual has a set of
carefully delineated rules regarding the difference between scope and
visibility.   In my experience, more programmers have more difficulties
with Ada because of these rules than any other part of the language.   Yet,
we see that most programmers choose not to study this issue until their
frustration emboldens them to dash their mouse to the floor and smash it
in rage.

The language design for Ada is unique in its differentiation between scope
and visibility.   More recent language designs, for example the namespace
option of C++, have adopted a somewhat anemic version of this feature,
but Ada remains more powerful in this respect.

An #include statement in some popular languages has  the approximate
semantics of an Ada with/use combination.   I say approximate because
there are some additional rules that make Ada a tad more reliable.

Consider an electrician who decides to string some wire through your house.
It is typical that the wire will have insulation over most of its length and

some well-defined interfaces at other points, usually the terminal points.
A
similar kind of thing is done in many other engineering designs.   A
pipeline
is built with specific locations where one can open or close it for
extracting
the content, or for adding some content.

A "with" clause, in Ada, is somewhat analogous to stringing the wire through

the house.   We keep the insulation intact to reduce the probability of
burning
down the house.   All the electricity we want is streaming through that
wire,
but our access to it is carefully controlled.   If we want access to the
current,
we can cut a little piece from the insulation and tap into it with another
wire,
but we take care to replace the insulation for the splice when we are done.

An #include, as defined for most languages, does not have a concept of
insulation.
Every feature is directly exposed, all the time.  Some very interesting
errors can
occur in large-scale software.   Since an Ada context clause ("with") makes
nothing
directly visible, the software engineer has responsibility to identify where
to
remove the insulation, how to remove it, and precisely how much to remove.

A visibility clause ("use") makes everything visible.  This is the
equivalent of
removing all the insulation at one time.   Good Ada design suggests that
this
may be too much exposure, for a variety of reasons.   Consequently, we
employ
one of several mechanisms as alternatives to the global visibility clause.
As engineers, we should always be interested in techniques for reducing
risk.

The somewhat tedious technical discussion that follows is guaranteed to bore

experienced Ada programmers, but may be of some use to those new to the
language such as Mr. Paielli.

Given a package specification,

            package P1 is
                type T1 is ...
                type T2 is ...
                procedure Process (Q_Data : in out T1);
                procedure Process (R_Data : in out T2);
           private
               -- private declarations
           end P1;

we have several approaches available to controlling visibility and reducing
ambiguity.

The global visibility clause:

           with P1;
           use  P1;
           procedure Test_1 is
               X : T1;
               Y : T2;
               Z :  T2;
           begin
               if y = Z then
                  Process(X);
               end if;
           end Test_1;

For this little program, there is probably no difficulty.  However, one
might
want to further disambiguate by ensuring the right call is made.  For
example,

             Process (Q_Data => X);

would be a better choice for the parameter association.    As a point of
interest,
it is appropriate to use a different symbol than assignment for this since
the
semantics of association and assignment are quite different.

Another way to control visibility might be as follows:

           with P1;
           procedure Test_2 is
               use type P1.T2;
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
           begin
               if Y = Z then
                  P1.Process(Q_Data => X);
               end if;
           end Test_2;

In this example, we have used the more restrictive version of the
visibility clause ("use type") so the equality operator will be
directly visible.   The problem with this is that, even though we
are now required to use dot notation for all operation calls, we
also make all the other infix operators visible.  For more rigorous
designs, we might want to avoid this approach.   Often, the
directly visibility of infix operators makes it easier to write some
code, but it also fails to restrict the writer to those options that,
from an engineering perspective, make sense.

Sometimes a programmer will localize the visibility clause.

           with P1;
           procedure Test_3 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
           begin
               declare
                   use P1;  -- or better yet, use type P1.T2
               begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
               end;
           end Test_3;

This does have the benefit of localizing the visibility clause.   However, a

well-crafted paper by Geoff Mendal once analyzed this option and found
it lacking in the rigor or disambiguity necessary for consistent
reliability.

Most Ada development organizations I deal with prefer the following:

           with P1;
           procedure Test_4 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
               function "=" (L, R : P1.T2) return Boolean renames P1."="'
           begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
           end Test_4;

In this example, we have made the equality operator directly visible through

renaming.   While this may seem somewhat bizzare to the newcomer, it
actually
has much to recommend it, from an engineering point-of-view.   This becomes
especially important when one wants to really restrict the set of operations

immediately available to a maintenance programmer in some distant time.

Another approach I have seen useful is a compromise.   I realize Tucker Taft

will leap all over me for continuing to suggest this alternative, but I find
some
organizations are using it with some success, and a minimum of risk.   This
is
the proactive approach of a nested infix operators package.  I personally
prefer
it to the "use type" clause.   I also prefer this to the creation of a child
library
unit, although that approach has much to recommend it.

           package P1 is
                type T1 is ...
                type T2 is ...
                procedure Process (Q_Data : in out T1);
                procedure Process (R_Data : in out T2);
                package Operators is
                    function "=" (L, R : P1.T2) return Boolean
                                                          renames P1."=");
                end Operators;
           private
               -- private declarations
           end P1;

Now we can have a use clause on the nested package only.

           with P1;
           procedure Test_5 is
               X : P1.T1;
               Y : P1.T2;
               Z :  P1.T2;
               use P1.Operators;
           begin
                    if Y = Z then
                         P1.Process(Q_Data => X);
                    end if;
           end Test_5;

In this case, the use clause applies only to the nested package.

I hope this clarifies a few issues related to the scope and visibility
features of Ada.   Certainly, there is more to be studied before one
can fully apprehend all of this topic.   However, it is, to my mind,
equally as important as the type safety that causes such a fuss.  This
aspect of Ada, along with type safety, is the foundation of the Ada
software engineering model.   We could change a lot of syntactic
rules, alter the reserved word list, and lots of other things, but we
would not want to relax the reliability of the language by abandoning
this important feature.

I hope this helps, Mr. Paielli.

Regards,

Richard Riehle

----------------------------------------------------------------------------------



Russ wrote:

> Well, I guess I touched some raw nerves with my proposal to clean up
> Ada's syntax. I certainly appreciate the feedback.
>
> I have come to the conclusion that my first item (eliminating the "end"
> keyword and making the indentation structure an inherent part of the
> syntax, as in Python) is NOT a good idea after all. The "end" lines
> really do help with readability, particularly for long procedures that
> end on a different page than they started.
>
> However, I still stand by the other items in my proposal. I think
> semicolons should be essentially eliminated, and I think "=" should be
> used for assignment and named association. I also still think the
> declaration syntax should be reversed. By the way, someone correctly
> pointed out that what I am proposing has a lot in common with Fortran
> 95.
>
> Furthermore, I think the idea of having another "dialect" of Ada is an
> innovative concept with real potential. If you reject it out hand, you
> simply have a closed mind.
>
> Most of the replies I received on this thread were very reasonable. A
> recurring theme, however, was that syntax is trivial and not worth
> discussing. I understand that the syntax is not the most important
> aspect of a language, but that doesn't mean it is not worth discussing
> or improving.
>
> I have a colleague who started programming in Fortran way back in the
> sixties (maybe even the fifties). He is a master algorithm developer and
> programmer. His code is meticulously correct, efficient, and minimal.
> When I introduced him to C and C++ several years ago, he was amazed that
> he had to clutter his code with all those semicolons and constantly put
> up with the compiler's nagging when one is left out. He adapted, of
> course, but his initial reaction was right. All those semicolons are
> nothing more than a lot of noise. They are litter in your code, and if
> you never minded them at all, then your code is probably filled with
> lots of other litter too. If so, I hope it is not being used in any
> safety-critical systems.
>
> Russ Paielli