Renaming entries?

Renaming entries?

[dennison]

I don't really understand the error I'm getting, but I'm getting pretty much
the same error message from 2 different compilers.

What I'm trying to do is rename a task entry to be a procedure. The procedure
is declared in the package spec, but the renaming is done in the body. I'm
wondering if that's my problem. Does a renaming have to be a procedure
*declaration*, or can it be the completion of a declaration?

Here's a smallish code sample if you need to see it to answer my question.

procedure Rename_Test is

   procedure Fred;

   task Foo is
      entry Jim;
   end Foo;

   procedure Fred renames Foo.Jim;

   task body Foo is
   begin
      accept Jim;
   end Foo;

begin
   Fred;
end Rename_Test;

When compiled with gnat, I get
rename_test.adb:15:19: not subtype conformant with declaration at line 8
rename_test.adb:15:19: prior declaration for "Fred" has convention "Ada"

The same example compiles OK w/ GreenHills, but not if the declarations are
moved to a package spec and body. In that case I also get an error referring
to Fred having convention "Ada".

Removing the "procedure Fred;" line cause gnat to compile it ok.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Renaming entries?

[Nick Roberts]

Right, [what is the 'T' of T.E.D. btw?], I've got this one pinned, I reckon.
RM95 8.5.4 (5) says that "the profile of a renaming-as-body shall be subtype
conformant with that of the renamed callable entity." RM 6.3.1 (2, 13) says
that the default calling convention for an entry is 'Entry'. Paragraph (17)
says that for subtype conformance the conventions must be the same.

So, the solution to your problem is to use

   pragma Convention(Entry,Fred);

in the package specification, and all will be well.

Now all I need is a spiral-bound RM that doesn't keep ON CLOSING ITSELF
ARGHHHHH! Sorry, calmed down now. I'm gonna break the spine of this damn
thing. Feeling lucky, book? Go on, make my day.

-------------------------------------
Nick Roberts

'The time has come,' the Walrus said,
  'To talk of many things:
Of shoes--of ships--and sealing wax--
  Of cabbages--and kings--
And why the sea is boiling hot--
  And whether pigs have wings.'
                        Lewis Carroll
          "Through the Looking Glass"
-------------------------------------

Re: Renaming entries?

[David Brown]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:


> So, the solution to your problem is to use
> 
>    pragma Convention(Entry,Fred);

RM95 6.3.1(14):
Of these four conventions, only Ada and Intrinsic are allowed as a
convention_identifier in a pragma Convention, Import, or Export.

My suggestion would be to wrap it in a procedure and then use a pragma
Inline if you care about the call overhead.  You won't be able to use
select with this, however.

David Brown

Re: Renaming entries?

[Nick Roberts]

Well, who designed this stupid language anyway?

;-)

Just to illustrate what David suggests, although you probably are fully
aware, you put

   procedure Fred;

in the package specification, and then

   procedure Fred is
   begin
      Foo.Jim;
   end;

in the package body. This is effectively a kind of 'trampoline' (I think!).
Actually, it might be better termed a 'thunk' (I think!!), especially if it
involves parameters.

David Brown wrote in message ...
|"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
|
|
|> So, the solution to your problem is to use
|>
|>    pragma Convention(Entry,Fred);
|
|RM95 6.3.1(14):
|Of these four conventions, only Ada and Intrinsic are allowed as a
|convention_identifier in a pragma Convention, Import, or Export.
|
|My suggestion would be to wrap it in a procedure and then use a pragma
|Inline if you care about the call overhead.  You won't be able to use
|select with this, however.

Embarrassed,

Nick Roberts

Re: Renaming entries?

[robert_dewar]

In article <7afc1p$3mi$3@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> So, the solution to your problem is to use
>
>    pragma Convention(Entry,Fred);
>
> in the package specification, and all will be well.

Well this is yet another example that you can't trust
everything you see on CLA, and readers are well cautioned
not to assume any published solutions here are correct.

Nick, I strongly suggest that you quickly compile things
you suggest. If they don't compile, perhaps you should
keep staring at the RM longer (the same RM that everyone
things is such a revealing source of information
on errors :-)

If you had compiled this suggestion with GNAT you would
have got something like:

  3.   pragma Convention (entry, q);
                          |
     >>> reserved word "entry" cannot be used as identifier

This is a correct message from GNAT, since your
suggestion is definitely illegal.

> Now all I need is a spiral-bound RM that doesn't keep ON
> CLOSING ITSELF

Well you will have to open it again to figure out
why GNAT is correct here. If you need an RM reference, the
appropriate one is RM 2.3(4):

    4   An identifier shall not be a reserved word.

This is a rather nice example of why RM references are not
always helpful :-)

Robert Dewar


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Renaming entries?

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<7aelgt$2hr$1@nnrp1.dejanews.com>...
>I don't really understand the error I'm getting, but I'm getting
pretty much
>the same error message from 2 different compilers.
>
>What I'm trying to do is rename a task entry to be a procedure. The
procedure
>is declared in the package spec, but the renaming is done in the
body. I'm
>wondering if that's my problem. Does a renaming have to be a
procedure
>*declaration*, or can it be the completion of a declaration?
>[example snipped]
Renaming-as-body needs to be subtype conformant, and this implies
having the same calling conventions. A procedure has calling
convention "Ada", but a task entry has calling convention "intrinsic".
Therefore, it is not allowed. Take off lawyer's hat.

Now, you can imagine that for the compiler, calling a "true"
subprogram is not the same thing as calling a task entry. If this were
allowed, you could put a procedure declaration in a package spec, and
rename-it-as-body-as-entry-call in the package body.
But since you are supposed to be able to call the procedure when you
have seen the specification only, the poor compiler would be in a very
bad shape...
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Renaming entries?

[Tucker Taft]

dennison@telepath.com wrote:
> 
> I don't really understand the error I'm getting, but I'm getting pretty much
> the same error message from 2 different compilers.
> 
> What I'm trying to do is rename a task entry to be a procedure. The procedure
> is declared in the package spec, but the renaming is done in the body. I'm
> wondering if that's my problem. Does a renaming have to be a procedure
> *declaration*, or can it be the completion of a declaration?
> 
> Here's a smallish code sample if you need to see it to answer my question.
> 
> procedure Rename_Test is
> 
>    procedure Fred;
> 
>    task Foo is
>       entry Jim;
>    end Foo;
> 
>    procedure Fred renames Foo.Jim;
> 
>    task body Foo is
>    begin
>       accept Jim;
>    end Foo;
> 
> begin
>    Fred;
> end Rename_Test;
> 
> When compiled with gnat, I get
> rename_test.adb:15:19: not subtype conformant with declaration at line 8
> rename_test.adb:15:19: prior declaration for "Fred" has convention "Ada"

GNAT is wrong in this complaint, because a renaming as body
is always OK so long as the prior subprogram declaration
has not yet been "frozen."  See RM95-8.5.4(5), last sentence.

> The same example compiles OK w/ GreenHills, but not if the declarations are
> moved to a package spec and body. In that case I also get an error referring
> to Fred having convention "Ada".

The Green Hills compiler is correct here.  As written above, the
prior subprogram declaration takes its convention from the renamed
thing (in this case a task entry).  However, if you separate
the subprogram declaration from the renaming-as-body by a freezing
point (like the end of a library package spec), then the
subprogram declaration takes the default convention "Ada" which
doesn't match the "entry" convention of the renaming-as-body.

> Removing the "procedure Fred;" line cause gnat to compile it ok.

That simply makes it a renaming-as-declaration, which is always OK.

In any case, as others have pointed out, creating your own "wrapper"
subprogram, which you then declare "inline," should work in all
circumstances.  Renaming-as-body is a short-hand which works
only when the conventions match up, or when the renaming-as-body
happens before the subprogram declaration is frozen.

> T.E.D.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA