Which compiler is right ?

Which compiler is right ?

[Strategies]

Hello
Is the following code legal ?
I have two compilers with two different answers

generic
   type Element_Type is limited private;
   type Index_Type is (<>);
   type Element_Array is array (Index_Type range <>) of Element_Type;
   with function Equal (Left, Right : Element_Type) 
	return Boolean is "=";   
function Generic_Indice (Left  :
Element_Type;                          			 Right : Element_Array) return
Index_Type;
-- 
------------------------------------------------------------------------
-- Jerome HAGUET, Strategies, Rungis, France 			      --
-- Tel : (33 1 | 01) 41 73 04 80  ;   Fax : (33 1 | 01) 41 73 04 99   --
-- Internet : strategies@magic.fr ;   Compuserve : 100747,2001        --
------------------------------------------------------------------------

Re: Which compiler is right ?

[Albert K. Lee]

On Thu, 24 Jul 1997 10:56:26 +0200, Strategies <strategies@magic.fr> wrote:
>Hello
>Is the following code legal ?
>I have two compilers with two different answers
>
>generic
>   type Element_Type is limited private;
>   type Index_Type is (<>);
>   type Element_Array is array (Index_Type range <>) of Element_Type;
>   with function Equal (Left, Right : Element_Type) 
>	return Boolean is "=";   
>function Generic_Indice (Left : Element_Type;
>			  Right : Element_Array) return Index_Type;

Personally, just by glancing at the code, it is difficult to figure
out why this code may be rejected; can you tell us the error you
encountered?

-Albert

Re: Which compiler is right ?

[Tucker Taft]

Strategies (strategies@magic.fr) wrote:

: Hello
: Is the following code legal ?

No.

: I have two compilers with two different answers

The one that rejects the program is correct.

: generic
:    type Element_Type is limited private;
:    type Index_Type is (<>);
:    type Element_Array is array (Index_Type range <>) of Element_Type;
:    with function Equal (Left, Right : Element_Type) 
: 	return Boolean is "=";   

When you give a default for a function like this (is "="), it is looked
up when the generic is compiled, as opposed to when it is instantiated.
And there is no "=" visible that matches the given parameter profile.

The only way to specify a default that is looked up when a generic
is instantiated is to use "is <>", and then the name of the formal
subprogram must match the name that you want looked up at the point
of instantiation.  Hence, you could do the following:

    with function "="(Left, Right : Element_Type) return Boolean is <>;

Now when you instantiate this generic, if the actual parameter is omitted
for this formal parameter, then the compiler will look for a directly
visible "=" that matches the given profile.

If you prefer to use the name "Equal" inside the generic, 
you could add a remame inside the generic body, such as:

    function Equal(Left, Right : Element_Type) return Boolean renames "=";

By the way, I agree with the other responder that when you have
a question like this, it sure makes it easier to help if you include
the error messages produced by the compiler(s) with your question.

: function Generic_Indice (Left  :
: Element_Type;                          			 Right : Element_Array) return
: Index_Type;
: -- 
: ------------------------------------------------------------------------
: -- Jerome HAGUET, Strategies, Rungis, France 			      --
: -- Tel : (33 1 | 01) 41 73 04 80  ;   Fax : (33 1 | 01) 41 73 04 99   --
: -- Internet : strategies@magic.fr ;   Compuserve : 100747,2001        --
: ------------------------------------------------------------------------

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

which compiler is right?

[Lionel.DRAGHI]

Could someone, please, tell me if this code compile with other compilers
than GNAT and ObjectAda?
Or even better, is ObjectAda right in rejecting it?

Thanks in advance

-- 
Lionel Draghi


-- ---------------------------------------------------------------
package Pkg1 is

   type T_Event is abstract tagged null record;

   function Priority (Event : T_Event) return Natural is abstract;

end Pkg1;

-- ---------------------------------------------------------------
with Pkg1;

generic
   type T_Event (<>) is new Pkg1.T_Event with private;

package Pkg2 is
   function Priority (Event : in T_Event) return Natural;
   
   -- OK for GNAT 3.16a (20030120)
   -- KO for ObjectAda (tm) Version 7.2.1 :
   --
   --      7    function Priority (Event : in T_Event) return Natural;
   --                    *
   --  *****Error: LRM:3.9.2(13) a primitive subprogram of a tagged type may
not be
   --  *****        declared after the type is frozen

end Pkg2;

Re: which compiler is right?

[Dmitry A. Kazakov]

On Tue, 16 Mar 2004 14:44:27 +0100, Lionel.DRAGHI@fr.thalesgroup.com
wrote:

>Could someone, please, tell me if this code compile with other compilers
>than GNAT and ObjectAda?
>Or even better, is ObjectAda right in rejecting it?
>
>Thanks in advance

package Pkg1 is
   type T_Event is abstract tagged null record;
   function Priority (Event : T_Event) return Natural is abstract;
end Pkg1;
-- ---------------------------------------------------------------
with Pkg1;
generic
   type T_Event (<>) is new Pkg1.T_Event with private;
package Pkg2 is
   function Priority (Event : in T_Event) return Natural;

Looks much like GNAT error. In any case the above makes little sense.
If you want to override Priority you should declare a new type in
Pkg2:

generic
   type T_Event (<>) is abstract new Pkg1.T_Event with private;
package Pkg2 is
   type New_T_Event is new T_Event with null record;
   function Priority (Event : in New_T_Event) return Natural;

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

RE: which compiler is right?

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Dmitry A.Kazakov [mailto:mailbox@dmitry-kazakov.de]
...
| with Pkg1;
| generic
|    type T_Event (<>) is new Pkg1.T_Event with private;
| package Pkg2 is
|    function Priority (Event : in T_Event) return Natural;
| 
| Looks much like GNAT error. In any case the above makes little sense.
| If you want to override Priority you should declare a new type in
| Pkg2:
...
It's not what I want to do.
Don't expect to get some sound design from this code, it's just the smallest
subset I could get causing the compilation difference.

-- 
Lionel Draghi

Re: which compiler is right?

[Randy Brukardt]

"Which compiler is right?"

Typically, that's irrelevant. You have to avoid any construct that doesn't
work with any of the compilers, because the turn-around time for a fix is
too long to wait for. (That's especially true for something like Claw.)
Anyway...

<Lionel.DRAGHI@fr.thalesgroup.com> wrote in message
news:mailman.97.1079444714.327.comp.lang.ada@ada-france.org...
> Could someone, please, tell me if this code compile with other compilers
> than GNAT and ObjectAda?
> Or even better, is ObjectAda right in rejecting it?

I think the program is illegal, but certainly not for the reasons that
ObjectAda is reporting. But perhaps this is one of the cases where something
completely unrelated is fixing a bug elsewhere in the language (because I
cannot figure out a reason for it to be illegal other than freezing - which
has nothing to do with this).

The inherited Priority routine is primitive by 3.2.3. 8.3 then says that the
new declaration overrides it. Of course, this is bogus, because the type is
not even declared in this scope, so any such overriding has to be illegal.
But I can't find any reason for that. OA says that the type is frozen, but
there really isn't any reason to assume that (and that may not be true in
Ada 2005 anyway). Even if the type was not frozen, we'd still want this to
be illegal.

Looks like Ada-Comment material to me.

                       Randy.

RE: which compiler is right?

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Randy Brukardt [mailto:randy@rrsoftware.com]
...
| 
| "Which compiler is right?"
| 
| Typically, that's irrelevant. You have to avoid any construct 
| that doesn't
| work with any of the compilers, because the turn-around time 
| for a fix is
| too long to wait for. (That's especially true for something 
| like Claw.)
| Anyway...
Typically, yes, but not in my case.
Because of projects roadmap, I have the possibility to wait for ObjectAda
fixes.  
But if GNAT is wrong accepting this code, then I must change it now.

And also (like for the other anectotical example I posted yesterday), even
if it's easy to avoid, I don't want the Ada compilers I am using disagreeing
on Ada semantics.


...
| I think the program is illegal, but certainly not for the reasons that
| ObjectAda is reporting. But perhaps this is one of the cases 
| where something
| completely unrelated is fixing a bug elsewhere in the 
| language (because I
| cannot figure out a reason for it to be illegal other than 
| freezing - which
| has nothing to do with this).
| 
| The inherited Priority routine is primitive by 3.2.3. 8.3 
| then says that the
| new declaration overrides it. Of course, this is bogus, 
| because the type is
| not even declared in this scope, so any such overriding has 
| to be illegal.
| But I can't find any reason for that. OA says that the type 
| is frozen, but
| there really isn't any reason to assume that (and that may 
| not be true in
| Ada 2005 anyway). Even if the type was not frozen, we'd still 
| want this to
| be illegal.
| 
Thank you Randy for your analysis. 

| Looks like Ada-Comment material to me.
Should I just send an informal mail, like the one I posted on cla?
Maybe with the underlying problem that lead to this code?

-- 
Lionel Draghi

Re: which compiler is right?

[Adam Beneschan]

Lionel.DRAGHI@fr.thalesgroup.com wrote in message news:<mailman.97.1079444714.327.comp.lang.ada@ada-france.org>...
> Could someone, please, tell me if this code compile with other compilers
> than GNAT and ObjectAda?
> Or even better, is ObjectAda right in rejecting it?
> 
> Thanks in advance
> 
> -- 
> Lionel Draghi
> 
> 
> -- ---------------------------------------------------------------
> package Pkg1 is
> 
>    type T_Event is abstract tagged null record;
> 
>    function Priority (Event : T_Event) return Natural is abstract;
> 
> end Pkg1;
> 
> -- ---------------------------------------------------------------
> with Pkg1;
> 
> generic
>    type T_Event (<>) is new Pkg1.T_Event with private;
> 
> package Pkg2 is
>    function Priority (Event : in T_Event) return Natural;
>    
>    -- OK for GNAT 3.16a (20030120)
>    -- KO for ObjectAda (tm) Version 7.2.1 :
>    --
>    --      7    function Priority (Event : in T_Event) return Natural;
>    --                    *
>    --  *****Error: LRM:3.9.2(13) a primitive subprogram of a tagged type may
> not be
>    --  *****        declared after the type is frozen
> 
> end Pkg2;

Since the score is currently 2-0 that the code should be illegal,
maybe I should point out that not everyone agrees with this analysis,
before you decide it's necessary to fix your code.  My belief is that
since the Priority routine declared in Pkg2 is declared in a different
scope than whatever type will be used to instantiate Pkg2, Priority is
neither a primitive subprogram nor is overriding.  I think GNAT is
correct to accept the code.

                                 -- Adam

Re: which compiler is right?

[Randy Brukardt]

<Lionel.DRAGHI@fr.thalesgroup.com> wrote in message
news:mailman.103.1079518605.327.comp.lang.ada@ada-france.org...
> | Looks like Ada-Comment material to me.
> Should I just send an informal mail, like the one I posted on cla?
> Maybe with the underlying problem that lead to this code?

I did post this on Ada-Comment. And I got three different answers. About all
that is agreed upon is that there is a hole in the language. But whether it
ought to be illegal or not is open to question. I presume that an AI will be
opened.

So I'd strongly recommend avoiding this construct completely, because there
is no agreement on what the language ought to say or compilers ought to
do -- and it may take years to sort it out. (And we may ultimately decide
that it is illegal.)

                          Randy.

RE: which compiler is right?

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: adam@irvine.com [mailto:adam@irvine.com]
...
| > -- ---------------------------------------------------------------
| > package Pkg1 is
| > 
| >    type T_Event is abstract tagged null record;
| > 
| >    function Priority (Event : T_Event) return Natural is abstract;
| > 
| > end Pkg1;
| > 
| > -- ---------------------------------------------------------------
| > with Pkg1;
| > 
| > generic
| >    type T_Event (<>) is new Pkg1.T_Event with private;
| > 
| > package Pkg2 is
| >    function Priority (Event : in T_Event) return Natural;
| >    
| >    -- OK for GNAT 3.16a (20030120)
| >    -- KO for ObjectAda (tm) Version 7.2.1 :
...
| > 
| > end Pkg2;
| 

| Since the score is currently 2-0 that the code should be illegal,
| maybe I should point out that not everyone agrees with this analysis,
| before you decide it's necessary to fix your code.  My belief is that
| since the Priority routine declared in Pkg2 is declared in a different
| scope than whatever type will be used to instantiate Pkg2, Priority is
| neither a primitive subprogram nor is overriding.  I think GNAT is
| correct to accept the code.
| 
Thank you Adam. 

I was feeling it this way. 
I was not considering the formal parameter like a real class, or like a
place older where the root abstract Priority should be visible. 
So there was no late overriding at this stage for me. 
And at instanciation time, the created Priority operation is in the
instanciated package scope, so there should be no problem.
But this is a user's view, not a layer's view. 


For the record, here is how I use those packages:
I provide the concrete realization of Priority by renaming 
the one in the generic instantiation.   

with Pkg1;
package Pkg3 is
   type T_Event is new Pkg1.T_Event with null record;
   function Priority (Event : in T_Event) return Natural;
end Pkg3;


with Pkg2;
package body Pkg3 is
   package Pkg2_Instanciation is new Pkg2 (T_Event); 
   function Priority (Event : in T_Event) return Natural
      renames Pkg2_Instanciation.Priority;
end Pkg3;

GNAT is behaving exactly like expected (by me, at least :-).


-- 
Lionel Draghi

RE: which compiler is right?

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Randy Brukardt [mailto:randy@rrsoftware.com]
...
| 
| I did post this on Ada-Comment. And I got three different 
| answers. About all
| that is agreed upon is that there is a hole in the language. 
| But whether it
| ought to be illegal or not is open to question. I presume 
| that an AI will be
| opened.
| 
Thank you.

| So I'd strongly recommend avoiding this construct completely, 
| because there
| is no agreement on what the language ought to say or 
| compilers ought to
| do -- and it may take years to sort it out. (And we may 
| ultimately decide
| that it is illegal.)
| 
That make sense, but  I will wait for both support answer before deciding to
change the code. 
In the mean time, I will explain on cla the context, just to be sure that
there is no simple solution to my problem.

-- 
Lionel Draghi

Re: which compiler is right?

[Randy Brukardt]

<Lionel.DRAGHI@fr.thalesgroup.com> wrote in message
news:mailman.104.1079549636.327.comp.lang.ada@ada-france.org...
...
> For the record, here is how I use those packages:
> I provide the concrete realization of Priority by renaming
> the one in the generic instantiation.
>
> with Pkg1;
> package Pkg3 is
>    type T_Event is new Pkg1.T_Event with null record;
>    function Priority (Event : in T_Event) return Natural;
> end Pkg3;
>
>
> with Pkg2;
> package body Pkg3 is
>    package Pkg2_Instanciation is new Pkg2 (T_Event);
>    function Priority (Event : in T_Event) return Natural
>       renames Pkg2_Instanciation.Priority;
> end Pkg3;

You don't need to have the same name of routine for this purpose, and it
probably would less confusing (both to language lawyers and to readers of
your code) if the name was different in the generic.

That is, if the generic looked like:

generic
    type T_Event (<>) is new Pkg1.T_Event with private;

package Pkg2 is
    function Priority_Implementation (Event : in T_Event) return Natural;
end Pkg2;

with Pkg2;
package body Pkg3 is
   package Pkg2_Instanciation is new Pkg2 (T_Event);
   function Priority (Event : in T_Event) return Natural
      renames Pkg2_Instanciation.Priority_Implementation;
end Pkg3;

gives you exactly what you want, without running into obscure language bugs.

               Randy.

Re: which compiler is right?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:b4682ab7.0403170927.cc800a5@posting.google.com...
...
> Since the score is currently 2-0 that the code should be illegal,
> maybe I should point out that not everyone agrees with this analysis,
> before you decide it's necessary to fix your code.  My belief is that
> since the Priority routine declared in Pkg2 is declared in a different
> scope than whatever type will be used to instantiate Pkg2, Priority is
> neither a primitive subprogram nor is overriding.  I think GNAT is
> correct to accept the code.

I thought that too, but that's not what the language says. Routines can be
overriding if they are inherited, anywhere. That's so that a type declared
in a body can have overriding routines, even though it can't have
primitives. Scopes have absolutely nothing to do with overriding (look at
8.3 again if you don't believe me). Similarly, primitiveness has nothing to
do with it.

It would be fine for that not to apply in a generic unit, but that is not
the current rule (because the
primitive routines are inherited in the generic). And this is not an area
into which I would likeIn any case, the OP doesn't have any grounds to get
Aonix to change ObjectAda. They may decide to do so because he's an
important customer or something, but otherwise they would be well advised to
wait for the ARG to shake this out.

I think it should be illegal simply because it is very confusing. This looks
like an overriding routine, but it is not. And if it is not overriding,
calls outside of the generic are almost certainly ambigious (for use clause
users, anyway). So it isn't very useful. I suppose the overridding keywords
will help reduce the confusion some, but only if they're widely used (this
routine ought to be tagged "not overriding", which would eliminate the
confusion if that was actually intended. But it would still be hard to call
the routine.)

                   Randy.

Re: which compiler is right?

[Adam Beneschan]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<105iblbigdett75@corp.supernews.com>...
> "Adam Beneschan" <adam@irvine.com> wrote in message
> news:b4682ab7.0403170927.cc800a5@posting.google.com...
> ...
> > Since the score is currently 2-0 that the code should be illegal,
> > maybe I should point out that not everyone agrees with this analysis,
> > before you decide it's necessary to fix your code.  My belief is that
> > since the Priority routine declared in Pkg2 is declared in a different
> > scope than whatever type will be used to instantiate Pkg2, Priority is
> > neither a primitive subprogram nor is overriding.  I think GNAT is
> > correct to accept the code.
> 
> I thought that too, but that's not what the language says. Routines can be
> overriding if they are inherited, anywhere.

I'm not sure how this is pertinent, since the routine causing the
error is not inherited.


> That's so that a type declared
> in a body can have overriding routines, even though it can't have
> primitives. Scopes have absolutely nothing to do with overriding (look at
> 8.3 again if you don't believe me).

Sorry, I looked at it and I still don't believe you.  8.3(9) says that
a declaration can override another homograph if the declaration
"occurs immediately within the same declarative region", etc.  The
term "immediately within a declarative region" is defined by 8.1(13)
and most definitely has to do with scopes.  If you declare a routine
in a nested inner package, it cannot override a routine declared
(implicitly or explicitly) in an outer package, because the routine in
the inner package is not *immediately* declared in the same
declarative region as the routine declared in the outer package.

If you are aware of this and still maintain that scopes have nothing
to do with overriding, then I'm afraid I'm not following you.


> Similarly, primitiveness has nothing to
> do with it.

Primitiveness has nothing to do with whether a routine is overriding;
but since the compiler in the original example reported an error
because it thought the declared routine was primtive, it's certainly
relevant to the problem.  Again, I'm probably just not understanding
you correctly.


> I think it should be illegal simply because it is very confusing. This looks
> like an overriding routine, but it is not.

Now I'm convinced that I'm lost.  I thought you were disagreeing with
me when I said the function (i.e. the Priority explicitly declared in
the generic) is not an overriding routine?


> And if it is not overriding,
> calls outside of the generic are almost certainly ambigious (for use clause
> users, anyway).

If you instantiate Pkg2 and then USE the instantiation, then calls to
Priority might be ambiguous (depending on whether the Priority
operation of the actual type is directly visible).

                                -- Adam

Re: which compiler is right?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:b4682ab7.0403181233.68d63fb5@posting.google.com...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<105iblbigdett75@corp.supernews.com>...
> > That's so that a type declared
> > in a body can have overriding routines, even though it can't have
> > primitives. Scopes have absolutely nothing to do with overriding (look
at
> > 8.3 again if you don't believe me).
>
> Sorry, I looked at it and I still don't believe you.  8.3(9) says that
> a declaration can override another homograph if the declaration
> "occurs immediately within the same declarative region", etc.  The
> term "immediately within a declarative region" is defined by 8.1(13)
> and most definitely has to do with scopes.  If you declare a routine
> in a nested inner package, it cannot override a routine declared
> (implicitly or explicitly) in an outer package, because the routine in
> the inner package is not *immediately* declared in the same
> declarative region as the routine declared in the outer package.

I'm going to reply to this on Ada-Comment, so that it gets on the permanent
record, and gets filed in the AI.

                 Randy.