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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site ssc-bee.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!ssc-vax!ssc-bee!bmac3
From: bmac3@ssc-bee.UUCP (Scott Pilet)
Newsgroups: net.lang.ada
Subject: Re: Ada '88 musings
Message-ID: <453@ssc-bee.UUCP>
Date: Thu, 9-Jan-86 15:33:43 EST
Article-I.D.: ssc-bee.453
Posted: Thu Jan  9 15:33:43 1986
Date-Received: Sat, 11-Jan-86 07:38:06 EST
References: <4700013@ada-uts.UUCP>
Organization: Boeing Aerospace Co., Seattle, WA
List-Id: <comp.lang.ada>

>   3)  Extend identifier visibility rules to eliminate need
>       for most "use" clauses.
> 
> (3) is probably necessary for the upward-compatible
> implementation of (2), to give correct visibility
> characteristics to user-defined ":=".
> 
> The problem with (2) is that built-in ":=" is "directly" visible
> even when other implicitly defined operations (like "=") are not.
> To avoid forcing everybody to "use" the defining package
> of a limited type to get visibility on ":=" (or the horrendous
> pkg.":="(a, b)), we come to:
> 
> The implementation for (3):
> Add a third place to search for identifiers after consulting
> "direct" visibility and "use" visibility -- "defining-package"
> visibility.  Defining-package visibility would mean that
> after consulting the "use"d packages, each package in which
> the type of a parameter is defined is consulted for a subprogram/operator
> definition.  Note that the package of the result-type is NOT included.
> 
> In fact, if more than one package is represented among the types
> of the parameters, then it is guaranteed that at most one
> of them could have visibility to all of the parameter types,
> and hence only one of them could possibly provide a definition
> for the subprogram/operator.
> 
> For example:
>     x+y    Assume type of x is pkg_x.type_x and type of y is pkg_y.type_y
>            and pkg_y looks like this:
> 	   
>            with pkg_x;
> 	   package pkg_y is
> 	       type type_y is new integer;
> 	       function "+"(a:pkg_x.type_x; b:type_y) return type_y;
>            end pkg_y
> 
>    Then it should not be necessary to "use" pkg_y for Ada semantics
> to resolve "+" in x+y.
> This should eliminate most of the need for "use" clauses.
> 
> All of these ideas are half-baked, but we still have 2 years
> to finish the baking...
> 
> Tucker Taft
> Intermetrics, Inc.
> 733 Concord Ave
> Cambridge, MA  02138   (617) 661-1840

In a large system effort, some other programmer may have a package
with a y and a "+" that would allow x+y.  The lack of a "use" statement
adds to the complexity for debugging and sets the system up for a disaster
in the future.  The existence of a "use" statement may be nice for small
Ada programs, but in a large project the use of it may add to the confusion.
"with"ing and "rename"ing ensures that the software engineer is positive
of where an identifier is from and what it is.  More errors will be detected
by the software tools used by the engineers in a large software project
following this type of methodology.  As a tool to aid the software engineer,
a compiler message suggesting some resolution of an undefined identifier,
operator, or procedure (etc.) is helpful, but a compiler allowing ambiguities
that are technologically preventable can be disaster.

scott pilet
--these statements are my own and not Boeing's