Question of Visibility

Question of Visibility

[Boris Pelakh]

I am trying to determine whether I am in the right (if I am not, I will have
to patch a compiler). Examine the following example :

with text_io;
package boolean_type_pkg is
  type boolean is (FALSE, TRUE);
  for boolean use (FALSE => 16#00#, TRUE => 16#ff#);
  package boolean_io is new text_io.enumeration_io(boolean);
end boolean_type_pkg;

with boolean_type_pkg; use boolean_type_pkg;
procedure boolean_test is
  flag : boolean := TRUE;
begin
  boolean_io.put(flag);
end boolean_test;

My (Verdix-derived) front-end determines flag to be of type STANDARD.BOOLEAN.
I say that is correct since according to 8.1.11, STANDARD is an all-enclosing
declarative region, and thus has visibility precedence to the with'ed in pkg.
My customer claims that is wrong. Any opinions ? Alternatively, is there any
compiler out there that will accept the above code ? Mine rejects it since
boolean_io.put requires BOOLEAN_TYPE_PKG.BOOLEAN.

-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
			

Re: Question of Visibility

[Gene Ouye]

Boris Pelakh (pelakh@convex.com) wrote:
: I am trying to determine whether I am in the right (if I am not, I will have
: to patch a compiler). Examine the following example :

: with text_io;
: package boolean_type_pkg is
:   type boolean is (FALSE, TRUE);
:   for boolean use (FALSE => 16#00#, TRUE => 16#ff#);
:   package boolean_io is new text_io.enumeration_io(boolean);
: end boolean_type_pkg;

: with boolean_type_pkg; use boolean_type_pkg;
: procedure boolean_test is
:   flag : boolean := TRUE;
: begin
:   boolean_io.put(flag);
: end boolean_test;

: My (Verdix-derived) front-end determines flag to be of type STANDARD.BOOLEAN.
: I say that is correct since according to 8.1.11, STANDARD is an all-enclosing
: declarative region, and thus has visibility precedence to the with'ed in pkg.
: My customer claims that is wrong. Any opinions ? Alternatively, is there any
: compiler out there that will accept the above code ? Mine rejects it since
: boolean_io.put requires BOOLEAN_TYPE_PKG.BOOLEAN.

: -- 
: Boris Pelakh		Ada Project Leader          pelakh@convex.com
: 		     Convex Computer Corporation
: "If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek 
TNG.
: 			

Boris,

I believe that much of section 8.4 applies here as well as 8.1(11) -- 
especially paragraphs 4, 5, 8, and the example in paragraph 11.  Also
sections 8.3 and 8.6 seem applicable.

In particular, 8.4(5) discussing declarations made visible by a use clause
states:

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

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

8.4(11):

	package D is
	   T, U, V, : Boolean;
	end D;

	procedure P is
	   package E is ... (elided for clarity)

	   procedure Q is
	      T, X : Real;
	      use D, E;
	   begin
	      -- the name T means Q.T, not D.T

	      ... (other comments elided)

Relative to your example, I equate Boolean_Type_Pkg.Boolean to D.T above.
(I recognize that Q.T and D.T are of different types and I don't think that
that makes any difference WRT your example.)  Also, as you noted, 8.1(11)
states: "The package STANDARD forms a declarative region which encloses all
library units: the implicit declaration of each library unit is assumed to
occur immediately within this package".  Thus, I equate Standard.Boolean to
Q.T above (because it is in the declarative region immediately surrounding
your procedure Boolean_Test (i.e., Standard)).
I then conclude that Standard.Boolean should not be hidden by the use clause
(as per 8.4(5) and 8.4(8)).

BUT...
as much as I would like to believe I am a language lawyer, compared to other
posters in this newsgroup I am only a language law clerk.  If anyone believes
my post to be invalid, please correct me.

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)

Gene Ouye (geneo@rational.com)
(301) 897-4014

Re: Question of Visibility

[Boris Pelakh]

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 !

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

-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
			

Re: Question of Visibility

[agate!spool.mu.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!cs0.dasd.h]

In article <1993Jul1.183945.21032@news.eng.convex.com>, pelakh@convex.com (Bori
s Pelakh) writes:
> 
> with text_io;
> package boolean_type_pkg is
>   type boolean is (FALSE, TRUE);
>   for boolean use (FALSE => 16#00#, TRUE => 16#ff#);
>   package boolean_io is new text_io.enumeration_io(boolean);
> end boolean_type_pkg;
> 
> with boolean_type_pkg; use boolean_type_pkg;
> procedure boolean_test is
>   flag : boolean := TRUE;
> begin
>   boolean_io.put(flag);
> end boolean_test;
> 
> My (Verdix-derived) front-end determines flag to be of type STANDARD.BOOLEAN.
> I say that is correct since according to 8.1.11, STANDARD is an all-enclosing
> declarative region, and thus has visibility precedence to the with'ed in pkg.
> My customer claims that is wrong. Any opinions ? Alternatively, is there any

You are right.  The VAX compiler does the same thing (and rightly so).  It
flags and inconsistency in the boolean_io.put(flag); statement since the
variable ->flag is not of the same type as is required by the instance
boolean_io.

My Tartan/960MC compiler gives me a stranger message though in saying that
the type boolean in the test procedure is not visible.  Evidently it is
confused about where the type boolean should come from (standard or
boolean_type_pkg).

> compiler out there that will accept the above code ? Mine rejects it since
> boolean_io.put requires BOOLEAN_TYPE_PKG.BOOLEAN.
> 
Just out of curiosity - why redefine the type boolean?  Is it just to use
the values in the representation clause?
> -- 
------------------------------------------------------------------------------
Todd A Sorensen               Honeywell Defense Avionics Systems Division
505-828-5611                  internet: tsorense@dasd.honeywell.com
                              internet: tas@dasd.honeywell.com
------------------------------------------------------------------------------ 

Re: Question of Visibility

[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

Re: Question of Visibility

[Bor is Pelakh]

In article <C9t9Ly.EML@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker T
aft) writes:
>>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.  

Actually, the solution they finally accepted was to put 

	subtype boolean is boolean_pkg.boolean;

in the units where the type was necessary.

-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
			

Re: Question of Visibility

[Dave Bashford]

In article ... stt@spock.camb.inmet.com (Tucker Taft) writes:
>In article ... pelakh@convex.com (Boris Pelakh) writes:
>>In article ... geneo@Rational.COM (Gene Ouye) writes:
[...]
>>>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.  

I'm confused. How does renaming "boolean" solve the "not having to edit
any of the other code" requirement ?  That was the ultimate goal wasn't it ?
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)

Re: Question of Visibility

[Wes Groleau X7574]

In all the discussion on "hiding" STANDARD.BOOLEAN with a different bit
pattern, I have yet to see two issues addressed:

1. I would expect STANDARD.BOOLEAN in any implementation to match the internal
hardware's conditional instructions.

2. IF one somehow succeeded in hiding STANDARD.BOOLEAN, wouldn't the compiler
generate the same code as before for  if  statements?

Wes Groleau

Re: Question of Visibility

[Gene Ouye]

Wes Groleau X7574 (groleau@e7sa.crd.ge.com) wrote:
: In all the discussion on "hiding" STANDARD.BOOLEAN with a different bit
: pattern, I have yet to see two issues addressed:

: 1. I would expect STANDARD.BOOLEAN in any implementation to match the interna
l
: hardware's conditional instructions.

: 2. IF one somehow succeeded in hiding STANDARD.BOOLEAN, wouldn't the compiler
: generate the same code as before for  if  statements?

: Wes Groleau

Wes, I tried to email this to you, but it bounced back:

FYI:
On Friday I sent an email to Boris (couldn't post it because our news was
acting up) that mentioned the following:

o "Use"-ing a Boolean_Types_Pkg would not redefine the predefined operators
  that return Standard.Boolean.  This means that the code will have to change.
  If nothing else, there will have to be explicit conversions between the
  Boolean_Type_Pkg.Boolean and Standard.Boolean before/after every call to
  the FORTRAN library that expects/returns boolean values.

o If the code has to change, IMHO it would be best to place a skin over the
  pragma Interface to the FORTRAN library that would do the conversion between
  the Ada and the FORTRAN perceptions of Boolean.  That would hide the FORTRAN
  specifics at an appropriate level, and would not make the entire Ada
  application dependent on FORTRAN's representation of a Boolean.

Gene Ouye (geneo@rational.com)