Renaming an abstract function

Renaming an abstract function

[Nick Roberts]

When given the program:

   package Test1 is
      type T is abstract tagged limited private;
      function P (X, Y: in T) return T is abstract;
      function "*" (A, B: in T) return T renames P; -- error line
   private
      type T is abstract tagged limited null record;
   end;

GNAT 3.12p on Windows 95 returns the error message:

   function that returns abstract type must be abstract

Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain?

Full detailed explanation welcome (if applicable).

--
Best wishes,
Nick Roberts

Re: Renaming an abstract function

[Stephen Leake]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> When given the program:
> 
>    package Test1 is
>       type T is abstract tagged limited private;
>       function P (X, Y: in T) return T is abstract;
>       function "*" (A, B: in T) return T renames P; -- error line
>    private
>       type T is abstract tagged limited null record;
>    end;
> 
> GNAT 3.12p on Windows 95 returns the error message:
> 
>    function that returns abstract type must be abstract
> 
> Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain?

Same error in gnat 3.14 (you should at least upgrade to 3.13p).

RM 8.5.4 (2) says:

  2.      subprogram_renaming_declaration ::=
             subprogram_specification renames callable_entity_name;

The term "callable_entity_name" is not mentioned elsewhere in the
reference manual, which I find odd.

However, just taking the literal English meaning, an abstract function
is _not_ callable, so it appears that you cannot rename an abstract
function. Too bad; it would be nice here (assuming "P" is a
multiplication operator :). 

On the other hand, it could be confusing. Is the renamed function also
inherited (which is what you would want)?

RM 3.2.3 says:

  2. The primitive subprograms of a specific type are defined as
     follows:

       3. The predefined operators of the type, see *Note 4.5::,

       4. For a derived type, the inherited, see *Note 3.4::,
          user-defined subprograms;

       5. For an enumeration type, the enumeration literals (which are
          considered parameterless functions -  see *Note 3.5.1::.);

       6. For a specific type declared immediately within a
          package_specification, any subprograms (in addition to the
          enumeration literals) that are explicitly declared
          immediately within the same package_specification and that
          operate on the type;


I don't think a renaming declaration meets this definition, so they
are not inherited.

So you have to choose either "P" or "*" for the primitive operation,
and provide the other name via renaming as needed for each derived
type. It depends on which name is more likely to be needed.

I guess my answer to your question is (c) :).

-- 
-- Stephe

Re: Renaming an abstract function

[Adam Beneschan]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
> 
> > When given the program:
> > 
> >    package Test1 is
> >       type T is abstract tagged limited private;
> >       function P (X, Y: in T) return T is abstract;
> >       function "*" (A, B: in T) return T renames P; -- error line
> >    private
> >       type T is abstract tagged limited null record;
> >    end;
> > 
> > GNAT 3.12p on Windows 95 returns the error message:
> > 
> >    function that returns abstract type must be abstract
> > 
> > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain?
> 
> Same error in gnat 3.14 (you should at least upgrade to 3.13p).
> 
> RM 8.5.4 (2) says:
> 
>   2.      subprogram_renaming_declaration ::=
>              subprogram_specification renames callable_entity_name;
> 
> The term "callable_entity_name" is not mentioned elsewhere in the
> reference manual, which I find odd.

Note that "callable_entity" is in italics, while "name" is not.  In RM
notation, that means that the language expects the syntax of a "name"
(defined in 4.1), while "callable_entity" is a description that tells
you what the name has to represent.  I guess if you're searching a
text file version of the RM, there's probably no indication that part
of it is in italics.  "callable entity" is easily found in the index.
 
A "callable entity" is defined (in 6(2)) to be a subprogram or entry. 
Thus an abstract subprogram is a callable entity even though you can't
really call it.

I don't see any prohibition on renaming an abstract subprogram. 
However, renaming subprograms don't quite take on all the
characteristics of the subprograms they rename; see 8.5.4(12) for
instance.  I suspect that has something to do with why renaming an
abstract subprogram could lead to an error, but I don't have time
right this minute to look into it further.

				-- Adam

Re: Renaming an abstract function

[Egil Harald Hoevik]

Adam Beneschan wrote:
> 
<snip> 
> A "callable entity" is defined (in 6(2)) to be a subprogram or entry.
> Thus an abstract subprogram is a callable entity even though you can't
> really call it.
> 

RM 6 (1): 
"...The definition of a subprogram can be given in two parts: 
a subprogram declaration defining its interface, and a subprogram_body
defining its execution..."

So, a subprogram (callable entity) requires a body (callable construct),
while an abstract subprogram does not, 
and the RM distinguishes between the two:

RM 6.1 (2-3):
   subprogram_declaration ::= subprogram_specification;
   abstract_subprogram_declaration ::= 
     subprogram_specification is abstract;



> I don't see any prohibition on renaming an abstract subprogram.
> However, renaming subprograms don't quite take on all the
> characteristics of the subprograms they rename; see 8.5.4(12) for
> instance.  I suspect that has something to do with why renaming an
> abstract subprogram could lead to an error, but I don't have time
> right this minute to look into it further.
> 
>                                 -- Adam


Well,

RM 8.5.4 (2):
  subprogram_renaming_declaration ::= 
    subprogram_specification renames callable_entity_name;

If renaming an abstract subprogram were allowed, I, 
at least, would think that the language would explicitly 
require the keyword 'abstract' in the renaming declaration 
(which it does not).



~egilhh
-- 
"What I seek is to serve, with my feeble capacity, 
truth and justice at the risk of pleasing no-one."
Albert Einstein.

Re: Renaming an abstract function

[Stephen Leake]

adam@irvine.com (Adam Beneschan) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>...
> > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
> > 
> > > When given the program:
> > > 
> > >    package Test1 is
> > >       type T is abstract tagged limited private;
> > >       function P (X, Y: in T) return T is abstract;
> > >       function "*" (A, B: in T) return T renames P; -- error line
> > >    private
> > >       type T is abstract tagged limited null record;
> > >    end;
> > > 
> > > GNAT 3.12p on Windows 95 returns the error message:
> > > 
> > >    function that returns abstract type must be abstract
> > > 
> > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain?
> > 
> > Same error in gnat 3.14 (you should at least upgrade to 3.13p).
> > 
> > RM 8.5.4 (2) says:
> > 
> >   2.      subprogram_renaming_declaration ::=
> >              subprogram_specification renames callable_entity_name;
> > 
> > The term "callable_entity_name" is not mentioned elsewhere in the
> > reference manual, which I find odd.
> 
> Note that "callable_entity" is in italics, while "name" is not.  

Well, not in the info version :). Guess there's a use for html, after
all :).

> In RM notation, that means that the language expects the syntax of a
> "name" (defined in 4.1), while "callable_entity" is a description
> that tells you what the name has to represent. I guess if you're
> searching a text file version of the RM, there's probably no
> indication that part of it is in italics. 

Yes; "info format" is ASCII with hyperlinks. Nice for reading from
Emacs. But it does lose the italics. Hmm, Emacs 21.1 can probably do a
better job of displaying the html version; I'll try that. 

> "callable entity" is easily found in the index.

Ah. I didn't think of that.

> A "callable entity" is defined (in 6(2)) to be a subprogram or
> entry. Thus an abstract subprogram is a callable entity even though
> you can't really call it.

Ok.

> I don't see any prohibition on renaming an abstract subprogram.
> However, renaming subprograms don't quite take on all the
> characteristics of the subprograms they rename; see 8.5.4(12) for
> instance. I suspect that has something to do with why renaming an
> abstract subprogram could lead to an error, but I don't have time
> right this minute to look into it further.
> 
> 				-- Adam

-- 
-- Stephe

Re: Renaming an abstract function

[Mark Biggar]

Adam Beneschan wrote:
> 
> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uvggau5ro.fsf@gsfc.nasa.gov>...
> > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:
> >
> > > When given the program:
> > >
> > >    package Test1 is
> > >       type T is abstract tagged limited private;
> > >       function P (X, Y: in T) return T is abstract;
> > >       function "*" (A, B: in T) return T renames P; -- error line
> > >    private
> > >       type T is abstract tagged limited null record;
> > >    end;
> > >
> > > GNAT 3.12p on Windows 95 returns the error message:
> > >
> > >    function that returns abstract type must be abstract
> > >
> > > Is this a bug in: (a) GNAT; (b) the RM95; or (c) my brain?
> >
> > Same error in gnat 3.14 (you should at least upgrade to 3.13p).
> >
> > RM 8.5.4 (2) says:
> >
> >   2.      subprogram_renaming_declaration ::=
> >              subprogram_specification renames callable_entity_name;
> >
> > The term "callable_entity_name" is not mentioned elsewhere in the
> > reference manual, which I find odd.
> 
> Note that "callable_entity" is in italics, while "name" is not.  In RM
> notation, that means that the language expects the syntax of a "name"
> (defined in 4.1), while "callable_entity" is a description that tells
> you what the name has to represent.  I guess if you're searching a
> text file version of the RM, there's probably no indication that part
> of it is in italics.  "callable entity" is easily found in the index.
> 
> A "callable entity" is defined (in 6(2)) to be a subprogram or entry.
> Thus an abstract subprogram is a callable entity even though you can't
> really call it.
> 
> I don't see any prohibition on renaming an abstract subprogram.
> However, renaming subprograms don't quite take on all the
> characteristics of the subprograms they rename; see 8.5.4(12) for
> instance.  I suspect that has something to do with why renaming an
> abstract subprogram could lead to an error, but I don't have time
> right this minute to look into it further.

There is an AI that addresses this problem:

>!standard 8.5.4     (7)                             00-07-12  >AI95-00211/06
>!class ramification 98-11-18
>!status Response 2000 00-01-24
>!status WG9 approved 99-06-12
>!status ARG Approved (with changes) 8-0-1  99-03-24
>!status work item 98-11-18
>!priority Medium
>!difficulty Easy
>!qualifier Clarification
>!subject Can an abstract subprogram be renamed?
>
>!summary
>
>An abstract subprogram can be renamed, and the renamed view is also
>abstract. Such a renaming must appear in a place where the declaration
>of an abstract subprogram would be legal. Similarly, the "shall be >overridden"
>property of 3.9.3(6) applies to a renamed view. Thus, any renaming of an
>inherited subprogram that must be overridden is illegal.

This explains the compilation error as the renaming "*" is a must be
overridden function as it has an abstract return type and thus is
illegal.

--
Mark Biggar
mark.a.biggar@home.com

Re: Renaming an abstract function

[Nick Roberts]

"Mark Biggar" <mark.a.biggar@home.com> wrote in message
news:3BF6DE1F.6C31A357@home.com...
> ...
> There is an AI that addresses this problem:
[AI95-211]
> ...
> >An abstract subprogram can be renamed, and the renamed view is also
> >abstract. Such a renaming must appear in a place where the declaration
> >of an abstract subprogram would be legal. Similarly, the "shall be
>overridden"
> >property of 3.9.3(6) applies to a renamed view. Thus, any renaming of an
> >inherited subprogram that must be overridden is illegal.

Many thanks for pointing out this AI, Mark.

> This explains the compilation error as the renaming "*" is a must be
> overridden function as it has an abstract return type and thus is
> illegal.

I don't think the AI explains it at all, in fact. The renaming of "*" in my
example is not attempting to rename an inherited subprogram. The type T is a
root abstract type (not derived from anything), so the functions P and "*"
are not inherited.

--
Best wishes,
Nick Roberts

Re: Renaming an abstract function

[Stephen Leake]

Mark Biggar <mark.a.biggar@home.com> writes:

> <snip example of renaming an abstract function returning an abstract
> type>

> > >    package Test1 is
> > >       type T is abstract tagged limited private;
> > >       function P (X, Y: in T) return T is abstract;
> > >       function "*" (A, B: in T) return T renames P; -- error line
> > >    private
> > >       type T is abstract tagged limited null record;
> > >    end;

> There is an AI that addresses this problem:
> 
> >!standard 8.5.4     (7)                             00-07-12  >AI95-00211/06
> >!class ramification 98-11-18
> >!status Response 2000 00-01-24
> >!status WG9 approved 99-06-12
> >!status ARG Approved (with changes) 8-0-1  99-03-24
> >!status work item 98-11-18
> >!priority Medium
> >!difficulty Easy
> >!qualifier Clarification
> >!subject Can an abstract subprogram be renamed?
> >
> >!summary
> >
> >An abstract subprogram can be renamed, and the renamed view is also
> >abstract. Such a renaming must appear in a place where the declaration
> >of an abstract subprogram would be legal. Similarly, the "shall be >overridden"
> >property of 3.9.3(6) applies to a renamed view. Thus, any renaming of an
> >inherited subprogram that must be overridden is illegal.
> 
> This explains the compilation error as the renaming "*" is a must be
> overridden function as it has an abstract return type and thus is
> illegal.
> 

Well, the full text of the AI talks about renaming an _inherited_
subprogram, not the abstract subprogram itself. It does not discuss
exactly what should happen for this case.

Simply following the rules for inheriting abstract subprograms, you
are required to give an overriding subprogram for any derived type.
Thus, if the renaming is valid, you'd have to override both P and "*",
which is surely not the intent. So it seems reasonable to conclude
that the renaming itself is invalid.

We could propose a "renaming inheritance" rule that says an equivalent
renaming is applied to the overriding subprogram; that is the intent
of this renaming.

-- 
-- Stephe

Re: Renaming an abstract function

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> ...
> Well, the full text of the AI talks about renaming an _inherited_
> subprogram, not the abstract subprogram itself. It does not discuss
> exactly what should happen for this case.

Precisely my point (in parallel post).

> Simply following the rules for inheriting abstract subprograms, you
> are required to give an overriding subprogram for any derived type.
> Thus, if the renaming is valid, you'd have to override both P and "*",

This is correct.

> which is surely not the intent.

Yes it is the intent. The Rationale (8.3) makes this clear.

> So it seems reasonable to conclude
> that the renaming itself is invalid.

No, I don't think so.

> We could propose a "renaming inheritance" rule that says an equivalent
> renaming is applied to the overriding subprogram; that is the intent
> of this renaming.

Intriguing idea, but it is already laid down: the renaming creates a new
'slot', thus both (the original and renamed) subprograms can be (and, in the
case of an asbtract subprogram, would need to be) overridden separately.

>
> --
> -- Stephe

--
Best wishes,
Nick Roberts

Re: Renaming an abstract function

[Stephen Leake]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> > ...
> > Well, the full text of the AI talks about renaming an _inherited_
> > subprogram, not the abstract subprogram itself. It does not discuss
> > exactly what should happen for this case.
> 
> Precisely my point (in parallel post).
> 
> > Simply following the rules for inheriting abstract subprograms, you
> > are required to give an overriding subprogram for any derived type.
> > Thus, if the renaming is valid, you'd have to override both P and "*",
> 
> This is correct.
> 
> > which is surely not the intent.
> 
> Yes it is the intent. The Rationale (8.3) makes this clear.

Well, I meant the "intent of the programmer". If I rename a function,
I "intend" to have two names for one function. If, when deriving the
type, I must provide _two_ functions, that is not two names for _one_
function. Of course, I can provide the same function, but I'd prefer
the language to enforce it.

Rationale 8.3 does say the behavior of renamed primitive operations
"may be considered surprising". I guess that's all I'm saying; I find
the behavior of inherited renamed primitive operations surprising. But
having read the Rationale (something I should do more often), I can
see why it has to be this way.

> > So it seems reasonable to conclude that the renaming itself is
> > invalid.
> 
> No, I don't think so.

Right, this is pretty close to the example in the rationale.

> > We could propose a "renaming inheritance" rule that says an
> > equivalent renaming is applied to the overriding subprogram; that
> > is the intent of this renaming.
> 
> Intriguing idea, but it is already laid down: the renaming creates a new
> 'slot', thus both (the original and renamed) subprograms can be (and, in the
> case of an asbtract subprogram, would need to be) overridden separately.

Yes, but the Rationale doesn't specifically address inheriting a
renamed function. It would be good if it did.

-- 
-- Stephe

Re: Renaming an abstract function

[Nick Roberts]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uwv0hlcml.fsf@gsfc.nasa.gov...
> ...
Acknowledged,
Nick