When/Why can a compiler reject an operator but accept a name?

When/Why can a compiler reject an operator but accept a name?

[Wes Groleau]

In package G I have:

    type List_Type is array (Natural range <>) of Item;

    type Order is access function (Left, Right : in Item) return
Boolean;

    procedure Sort (List : in out List_Type; Sequence : in Order);
    

In procedure P I had:

    package I is new G (Item);

    function "<" (Left, Right : in Item) return Boolean is

    .....
    
    I.Sort (List => List, Sequence => "<"'Access);

    
Compiler rejected it, saying:

   "<" has no definition that matches function (Left, Right : in Item)
return Boolean [RM_95 3.10.2(32)]
   
I replaced "<" with Ord_Check (no other changes), and
the compiler accepted it.

Does using an operator instead of a name make the
function Intrinsic?

If not, there is no support for rejection in 3.10.2(32)
Is there any reason elsewhere in the RM to justify this
odd behavior?

(Certainly either way, the message could be improved!)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: When/Why can a compiler reject an operator but accept a name?

[Robert A Duff]

Wes Groleau <wesgroleau@despammed.com> writes:

> In package G I have:
> 
>     type List_Type is array (Natural range <>) of Item;
> 
>     type Order is access function (Left, Right : in Item) return
> Boolean;
> 
>     procedure Sort (List : in out List_Type; Sequence : in Order);
>     
> 
> In procedure P I had:
> 
>     package I is new G (Item);
> 
>     function "<" (Left, Right : in Item) return Boolean is
> 
>     .....
>     
>     I.Sort (List => List, Sequence => "<"'Access);
> 
>     
> Compiler rejected it, saying:
> 
>    "<" has no definition that matches function (Left, Right : in Item)
> return Boolean [RM_95 3.10.2(32)]
>    
> I replaced "<" with Ord_Check (no other changes), and
> the compiler accepted it.

Sounds like a compiler bug, although I can't be sure without seeing all
the code (e.g., you didn't show the code for Ord_Check).

> Does using an operator instead of a name make the
> function Intrinsic?

No.

> If not, there is no support for rejection in 3.10.2(32)
> Is there any reason elsewhere in the RM to justify this
> odd behavior?
> 
> (Certainly either way, the message could be improved!)

True.  Show us a complete example.

- Bob

Re: When/Why can a compiler reject an operator but accept a name?

[Antonio Duran]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D25D271.ACE6DAC8@despammed.com>...
> In package G I have:
> 
>     type List_Type is array (Natural range <>) of Item;
> 
>     type Order is access function (Left, Right : in Item) return
> Boolean;
> 
>     procedure Sort (List : in out List_Type; Sequence : in Order);
>     
> 
> In procedure P I had:
> 
>     package I is new G (Item);
> 
>     function "<" (Left, Right : in Item) return Boolean is
> 
>     .....
>     
>     I.Sort (List => List, Sequence => "<"'Access);
> 
>     
> Compiler rejected it, saying:
> 
>    "<" has no definition that matches function (Left, Right : in Item)
> return Boolean [RM_95 3.10.2(32)]
>    
> I replaced "<" with Ord_Check (no other changes), and
> the compiler accepted it.
> 
> Does using an operator instead of a name make the
> function Intrinsic?
> 
> If not, there is no support for rejection in 3.10.2(32)
> Is there any reason elsewhere in the RM to justify this
> odd behavior?
> 
> (Certainly either way, the message could be improved!)

ARM 3.10.2 1 says:

"The attribute Access is used to create access values designating
aliased objects and non-intrinsic subprograms. The
&#8220;accessibility&#8221; rules prevent dangling references (in the
absence of uses of certain unchecked features &#8212; see Section
13)."

So what I think is happening is that you're instanciating G with a
type that has an intrinsic "<" operator. For example, if you use
Integer, in your P procedure you must write a customized "<" operator
like:

with G;

procedure P is
   package I is new G(Integer);

   function "<"(Left, Right: in Integer) return Boolean
   is
   begin
      return Standard."<"(Left, Right);
   end "<";

   -- More stuff here.

begin
   -- More stuff here.
end P;

Regards,
    Antonio Duran.

Re: When/Why can a compiler reject an operator but accept a name?

[Wes Groleau]

> > Compiler rejected it, saying:
> >
> >    "<" has no definition that matches function (Left, Right : in Item)
> > return Boolean [RM_95 3.10.2(32)]
> >
> > I replaced "<" with Ord_Check (no other changes), and
> > the compiler accepted it.
> 
> Sounds like a compiler bug, although I can't be sure without seeing all
> the code (e.g., you didn't show the code for Ord_Check).

Sorry for being a little vague.  ">" was/is a somewhat
complicated function, and all I did to make it compile
was change the designator to "Ord_Check" in both the
declaration and all references.

I would normally compare the GNAT behavior, but
our admins had a bit of trouble replacing 3.14
with the integrated GCC 3.1 suite.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: When/Why can a compiler reject an operator but accept a name?

[Wes Groleau]

> So what I think is happening is that you're instanciating G with a
> type that has an intrinsic "<" operator. For example, if you use
> Integer, in your P procedure you must write a customized "<" operator
> like:

I hadn't thought of that--good point.
However, the generic never uses ">"
nor has it as a parameter.  And the
type "Item" is an access type.  So
I don't think that's it in this case.

I reported it as a bug to the vendor,
but I'm still not 100% certain.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau