Is this valid Ada?

Is this valid Ada?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!paperboy.micro.umn.edu!cs.um]

The following code fragment compiles on two of the Ada compilers that I am
presently using.  However, on two other compilers that I am using it won't
compile.  The later two compilers provide an error message indicating that
the call to Is_This_Ambiguous is an ambiguous statement and references 
paragraph 8.7 of the LRM.

I have read paragraph 8.7 several times and cannot find anything that leads
me to believe that this code fragment is not legal.  Consequently, I don't
know which pair of compilers has a bug.  If the code is legal, then the
compilers issuing the error message have a bug.  If the code is illegal, 
then the compilers not issuing the error message have a bug.

Anyone care to offer an opinion?

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

PACKAGE Ambiguous_Type IS

  TYPE Is_This_Ambiguous IS NEW Integer;

END Ambiguous_Type;

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

WITH Ambiguous_Type; USE Ambiguous_Type;

PROCEDURE Test IS

  PROCEDURE Is_This_Ambiguous IS
  BEGIN
    NULL;
  END Is_This_Ambiguous;

BEGIN

  Is_This_Ambiguous;

END Test;

----------------------------------------
-- 
  ____  ____        Steve Case - HQG526           email: case@shamash.cdc.com
 / ___||___ \       Control Data Corporation      AT&T : (612) 853-3345
| |___  ___| |      3101 East 80th Street                 
 \____||____/       Bloomington, MN 55425

Re: Is this valid Ada?

[Jack Dean]

In article <37806@shamash.cdc.com>, case@shamash.cdc.com (Steven V. Case) write
s:
|> 
|> Anyone care to offer an opinion?
|> 
|> ----------------------------------------
|> 
|> PACKAGE Ambiguous_Type IS
|> 
|>   TYPE Is_This_Ambiguous IS NEW Integer;
|> 
|> END Ambiguous_Type;
|> 
|> ----------------------------------------
|> 
|> WITH Ambiguous_Type; USE Ambiguous_Type;
|> 
|> PROCEDURE Test IS
|> 
|>   PROCEDURE Is_This_Ambiguous IS
|>   BEGIN
|>     NULL;
|>   END Is_This_Ambiguous;
|> 
|> BEGIN
|> 
|>   Is_This_Ambiguous;
|> 
|> END Test;
|> 

The way I read 8.7 of the LRM, this should be legal.  The potential
problem stems from the overloading of of Is_This_Ambiguous.  One possible
resolution is the parameterless procedure Test.Is_This_Ambiguous.  The
other possible resoulution is the implicit conversion function
Ambiguous_Type.Is_This_Ambiguous, which takes a parameter of type
Integer, and returns a result of type Ambiguous_Type.Is_This_Ambiguous. 
Now clearly the syntax rules and the parameter profile rules eliminate
this second resolution.  Since there is only one valid interpretation,
the use of the overloaded entity is legal.


-- 
Jack Dean                         dean@sweetpea.jsc.nasa.gov

Re: Is this valid Ada?

[Bill Yow]

In article <37806@shamash.cdc.com>, case@shamash.cdc.com (Steven V. Case) write
s:

|> Anyone care to offer an opinion?
|> 
|> ----------------------------------------
|> 
|> PACKAGE Ambiguous_Type IS
|> 
|>   TYPE Is_This_Ambiguous IS NEW Integer;
|> 
|> END Ambiguous_Type;
|> 
|> ----------------------------------------
|> 
|> WITH Ambiguous_Type; USE Ambiguous_Type;
|> 
|> PROCEDURE Test IS
|> 
|>   PROCEDURE Is_This_Ambiguous IS
|>   BEGIN
|>     NULL;
|>   END Is_This_Ambiguous;
|> 
|> BEGIN
|> 
|>   Is_This_Ambiguous;
|> 
|> END Test;
|> 


Yes, it is legal.

The two compilers that correctly compiled the program realized that 

  begin
    Is_This_Ambiguous;
  end test; 

has to be a call to the procedure Test.Is_This_Ambiguous because having the
Ambiguous_Type.Is_This_Ambiguous type there would have been an error.

Would having the type there be a Syntactic or Semantic error?

The other two compilers are being lazy and not looking at what the overloaded
symbol is (type, procedure).

Now the question is, should not all Ada compilers compile this?

I could see this error causing major portability problems for someone.



|> ----------------------------------------
|> -- 
|>   ____  ____        Steve Case - HQG526           email: case@shamash.cdc.co
m
|>  / ___||___ \       Control Data Corporation      AT&T : (612) 853-3345
|> | |___  ___| |      3101 East 80th Street                 
|>  \____||____/       Bloomington, MN 55425

						Later,
						Bill Yow
						(713) 283-4051
						yow@sweetpea.jsc.nasa.gov
						byow@mcimail.com

My opinions are my own!			

Re: Is this valid Ada?

[csn!news.den.mmc.com!possum.den.mmc.com!dow]

In article <37806@shamash.cdc.com> case@shamash.cdc.com (Steven V. Case) writes
:
>The following code fragment compiles on two of the Ada compilers that I am
>presently using.  However, on two other compilers that I am using it won't
>compile.  The later two compilers provide an error message indicating that
>the call to Is_This_Ambiguous is an ambiguous statement and references 
>paragraph 8.7 of the LRM.
>
>I have read paragraph 8.7 several times and cannot find anything that leads
>me to believe that this code fragment is not legal.  Consequently, I don't
>know which pair of compilers has a bug.  If the code is legal, then the
>compilers issuing the error message have a bug.  If the code is illegal, 
>then the compilers not issuing the error message have a bug.
>
>Anyone care to offer an opinion?
>

I am convinced that this is legal Ada and that the compilers that flagged it
as an error are wrong.  This opinion is based not so much on the information
in paragraph 8.7, or 8.3 (another logical place to look) but instead on the 
information in paragraph 8.4.  

Paragraph 8.4 (5) states:
"A potentially visible declaration is not made directly visible if the place
considered is within the immediate scope of a homograph of the declaration."

The LRM continues with 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."

By the way, a co-worker of mine who has a particular affinity for C is 
flabbergasted by a language where the legality of so few lines of code is
in question.  Of course, I am sure that it would not take any of us very
long to write a few lines of C that may be somewhat confusing. ;-)


-- 

Mark Dow      dow@pogo.den.mmc.com