Disagreement between GNAT and Cohen?

Disagreement between GNAT and Cohen?

[Andrew Hoddinott]

With the declaration

package Test is
   type Set_Type is array (1 .. 3) of Boolean; -- for example
   function Union (Set_1, Set_2 : Set_Type) return Set_Type;
end Test;

the following code

package body Test is
   function Union (Set_1, Set_2 : Set_Type) return Set_Type is
   begin
      return Set_1 or Set_2;
   end Union;
end Test;

compiles without problem, but for

package body Test is
   function Union (Set_1, Set_2 : Set_Type) return Set_Type
      renames "or";
end Test;

GNAT (3.14p) gives an error:

test.adb:2:04: not subtype conformant with declaration in package Standard
test.adb:2:04: return type does not match
test.adb:3:15: subprogram used in renaming_as_body cannot be intrinsic

This kind of renaming is explicitly used by Cohen in a generics example
in section 15.2.3.2 of "Ada as a second language". (Cohen's full example
doesn't compile either, although only the first 2 lines of the error
message are generated).

Am I missing something obvious here? Or is Cohen wrong? Or GNAT? Is
there something in the RM that supports GNAT's claim that "subprogram
used in renaming_as_body cannot be intrinsic"?

Re: Disagreement between GNAT and Cohen?

[Robert A Duff]

Andrew Hoddinott <andrew@golter.demon.co.uk> writes:

> Am I missing something obvious here? Or is Cohen wrong? Or GNAT? Is
> there something in the RM that supports GNAT's claim that "subprogram
> used in renaming_as_body cannot be intrinsic"?

See 8.5.4(5/1).

The AARM explains the reason for the rule: basically to make (efficient)
implementation easier.

- Bob

Re: Disagreement between GNAT and Cohen?

[Preben Randhol]

Andrew Hoddinott <andrew@golter.demon.co.uk> wrote on 11/06/2002 (02:38) :
> This kind of renaming is explicitly used by Cohen in a generics example
> in section 15.2.3.2 of "Ada as a second language". (Cohen's full example
> doesn't compile either, although only the first 2 lines of the error
> message are generated).
> 
> Am I missing something obvious here? Or is Cohen wrong? Or GNAT? Is
> there something in the RM that supports GNAT's claim that "subprogram
> used in renaming_as_body cannot be intrinsic"?

Have you checked:

   http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Disagreement between GNAT and Cohen?

[Andrew Hoddinott]

Robert A Duff wrote:


> See 8.5.4(5/1).
> 
> The AARM explains the reason for the rule: basically to make (efficient)
> implementation easier.


Thanks for that. I had somehow managed to read straight through that
paragraph without spotting the word Intrinsic :-S

I'm still puzzled though. Cohen's actual example (p. 696-7) is:

generic
   type Element_Type is (<>);
package Generic_Discrete_Sets is
   type Set_Type is private;
   function Union (Set_1, Set_2  : Set_Type ) return Set_Type;
   --  ... more functions and types
private
   type Set_Type is array (Element_Type) of Boolean;
end Generic_Discrete_Sets;

package body Generic_Discrete_Sets is
   function Union (Set_1, Set_2 : Set_Type) return Set_Type
      renames "or";
   --  ... more function bodies
end Generic_Discrete_Sets;

generating the errors:
generic_discrete_sets.adb:2:04: not subtype conformant with declaration
in package Standard
generic_discrete_sets.adb:2:04: return type does not match

He specifically draws attention to the package body using "the versions
of the logical operators 'and', 'or', and 'not' that apply component by
component to one-dimensional arrays of Boolean values", and bases an
exercise (15.3) around the example too.

Is he just making this up? Or is there some way that the frozen-ness of
the intrinsic logical operators can vary between compilers so that this
example sometimes works? And the intrinsic not getting an explicit
mention in the error message in this slightly more complex case is
because ... ?

Sorry. Since I know how to work around the problem, I should probably
just shut up and go on to the next exercise, but ... ;-)

Re: Disagreement between GNAT and Cohen?

[Robert A Duff]

Andrew Hoddinott <andrew@golter.demon.co.uk> writes:

> I'm still puzzled though. Cohen's actual example (p. 696-7) is:
> 
> generic
>    type Element_Type is (<>);
> package Generic_Discrete_Sets is
>    type Set_Type is private;
>    function Union (Set_1, Set_2  : Set_Type ) return Set_Type;
>    --  ... more functions and types
> private
>    type Set_Type is array (Element_Type) of Boolean;
> end Generic_Discrete_Sets;
> 
> package body Generic_Discrete_Sets is
>    function Union (Set_1, Set_2 : Set_Type) return Set_Type
>       renames "or";
>    --  ... more function bodies
> end Generic_Discrete_Sets;

This code looks wrong to me.  I don't understand the GNAT error message,
though.

> generating the errors:
> generic_discrete_sets.adb:2:04: not subtype conformant with declaration
> in package Standard
> generic_discrete_sets.adb:2:04: return type does not match
> 
> He specifically draws attention to the package body using "the versions
> of the logical operators 'and', 'or', and 'not' that apply component by
> component to one-dimensional arrays of Boolean values", and bases an
> exercise (15.3) around the example too.
> 
> Is he just making this up?

Perhaps Norm Cohen compiled the code with an early version of GNAT that
didn't check the rule.  I believe the GNAT implementation generates a
dummy body for a renaming-as-body, so it would work just fine.

What Cohen is trying to do is perfectly reasonable -- the rule is not
there for semantic reasons, but to ease a certain implementation
technique.  In hindsight, I think the rule is misguided.

>... Or is there some way that the frozen-ness of
> the intrinsic logical operators can vary between compilers so that this
> example sometimes works?

No, all compilers should agree on this.

>... And the intrinsic not getting an explicit
> mention in the error message in this slightly more complex case is
> because ... ?

Beats me.

> Sorry. Since I know how to work around the problem, I should probably
> just shut up and go on to the next exercise, but ... ;-)

Nothing wrong with trying to understand the language.  ;-)

- Bob