Re: Question of Visibility

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland. reston.ans.net!noc.near.net!inmet!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft)]

In article <1993Jul2.133624.6485@news.eng.convex.com> 
  pelakh@convex.com (Boris Pelakh) writes:

>In article <1993Jul1.214402.25611@rational.com> 
>  geneo@Rational.COM (Gene Ouye) writes:
>>And 8.4(8):
>>
>>	"The above rules guarantee that a declaration that is made directly
>>	visible by a use clause cannot hide an otherwise directly visible
>>	declaration."
>>
>
>I think this is exactly what I was looking for. Phew !

Your compiler is doing the right thing.  As RM 8.4(5) says:

   A potentially visible declaration is not made directly visible
   if the place considered is within the immediate scope of a homograph
   of the declaration.

Translating that gobble-dy-gook into non-language-lawyer-ease means
that adding a use clause can never hide something that is directly
visible in the absence of use clauses.  The only way to hide something
from package Standard is to declare something of the same name.
"Use"ing a package that declares something of the same name doesn't do it.  

The rules associated with use-visibility 
were designed to minimize maintenance problems,
but they also mean that things made "use" visible have a kind
of second-class visibility, being hidden by anything that is directly
visible in the absence of use visibility.

>>One question: what is preventing you from using dotted notation in the
>>              declaration of flag?  (never mind the obvious question of why
>>              do you need the use clause)
>
>The user has a large body of code interfacing to a FORTRAN library. FORTRAN
>requires .TRUE. = ~.FALSE. in a bit-wise way. They wanted to change the
>meaning of BOOLEAN throughout their entire source by introducing the type
>into one of the root packages, and not having to edit any of the other code.

I would recommend that your user just rename "boolean" to "bool" or 
"f77_bool" or equivalent.  

>Boris Pelakh		Ada Project Leader          pelakh@convex.com
>		     Convex Computer Corporation


S. Tucker Taft    stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138