Problem with instantiating generic procedure

Problem with instantiating generic procedure

[Markus Kuhn]

Sorry, but after searching through the RM for almost an hour, I still
haven't figured out what I do wrong here and how I should fix this.
I declare in a package spec a procedure A and I want to implement the
procedure body of A by instantiating a generic procedure G. The following
is the shortest possible program that reproduces my problem:

-- bug.ads --
package Bug is
   
   procedure A;
   
end Bug;
-- bug.adb --
package body Bug is
   
   generic
   procedure G;
   
   procedure G is
   begin
      null;
   end G;
   
   procedure A is new G;
   
end Bug;
-------------

GNAT 3.11p on Linux insists on the following error message:

bug.adb:1:14: missing body for "A" declared at bug.ads:3
bug.adb:11:14: "A" conflicts with declaration at bug.ads:3

What is wrong with simply implementing a procedure declared
in the spec file in the body file by instantiating it from
a generic procedure of the exact same signature? Both A and G
have no parameters, so how can there be a conflict?

It would be nice if GNAT wrote out explicitely the two conflicting
sides, each time it uses the word "conflict" in an error message.

Any idea what is wrong here?

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Problem with instantiating generic procedure

[Vladimir Olensky]

Here are two working examples that solves your problem.
Gnat 3.11p, WinNT.
Hope this will help.


As I understand it one  should first have  instantiation  of generic
procedure and only then bind it with the procedure name declared at spec.

--===============================
Example 1:
----------------------------------
package Bug is
   procedure A;
end Bug;
---------------------------------
with ada.text_io; use ada.text_io;
package body Bug is

   generic
   procedure G;

   procedure G is
   begin
      put_line("Body of A implemented as generic");
   end G;

   procedure AA is new G;
   procedure A renames AA;
end Bug;

--===============================
Example 2:
----------------------------------
generic
package G is
  procedure GP;
end G;
----------------------------------
with ada.text_IO; use ada.text_io;
package body G is

  procedure GP is
   begin
      put_line("Body of A implemented as generic");
   end GP;

end G;

-----------------------
package Bug is
   procedure A;
end Bug;
----------------
with G;
package body Bug is
  package AA is new G;
  procedure A renames AA.GP;
end Bug;
----------------------------

--==================================
-- test procedure for both examples
with Bug;
procedure Tst_Bug is
begin
   Bug.A;
end Tst_Bug;

----------------------------------------------

Regards,
Vladimir Olensky



Markus Kuhn wrote in message <7mqfcq$9og$1@pegasus.csx.cam.ac.uk>...
>Sorry, but after searching through the RM for almost an hour, I still
>haven't figured out what I do wrong here and how I should fix this.
>I declare in a package spec a procedure A and I want to implement the
>procedure body of A by instantiating a generic procedure G. The following
>is the shortest possible program that reproduces my problem:
>
>-- bug.ads --
>package Bug is
>
>   procedure A;
>
>end Bug;
>-- bug.adb --
>package body Bug is
>
>   generic
>   procedure G;
>
>   procedure G is
>   begin
>      null;
>   end G;
>
>   procedure A is new G;
>
>end Bug;
>-------------
>
>GNAT 3.11p on Linux insists on the following error message:
>
>bug.adb:1:14: missing body for "A" declared at bug.ads:3
>bug.adb:11:14: "A" conflicts with declaration at bug.ads:3
>
>What is wrong with simply implementing a procedure declared
>in the spec file in the body file by instantiating it from
>a generic procedure of the exact same signature? Both A and G
>have no parameters, so how can there be a conflict?
>
>It would be nice if GNAT wrote out explicitely the two conflicting
>sides, each time it uses the word "conflict" in an error message.
>
>Any idea what is wrong here?
>
>Markus
>
>--
>Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
>Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Problem with instantiating generic procedure

[Florian Weimer]

mgk25@cl.cam.ac.uk (Markus Kuhn) writes:

> Sorry, but after searching through the RM for almost an hour, I still
> haven't figured out what I do wrong here and how I should fix this.

ARM 6.1(20):

| A subprogram_declaration or a generic_subprogram_declaration requires
| a completion: a body, a renaming_declaration (see 8.5), or a pragma
| Import (see B.1). A completion is not allowed for an
| abstract_subprogram_declaration.

I guess this means that an instance of a generic subprogram isn't allowed
as a completion for a subprogram declaration.  The obvious workaround
is using a renaming declaration.  Of course, the GNAT error message
could be a bit more helpful.

BTW: I stumbled across this problem and the solution while a solving
the very first Ada exercise of my computer science course. ;)

Re: Problem with instantiating generic procedure

[Markus Kuhn]

Florian Weimer <fw@s.netic.de>:
|> ARM 6.1(20):
|> 
|> | A subprogram_declaration or a generic_subprogram_declaration requires
|> | a completion: a body, a renaming_declaration (see 8.5), or a pragma
|> | Import (see B.1). A completion is not allowed for an
|> | abstract_subprogram_declaration.

Thanks! But the RM also says in section 12.3:

  A generic_instantiation declares an instance; it is equivalent to the
  instance declaration (a package_declaration or subprogram_declaration)
  immediately followed by the instance body, both at the place of the
  instantiation. 

So if 6.1 says that a subprogram_declaration requires a body and 12.3 says that
a generic instantiation does provide the equivalent of a body, then I still
do not understand where the RM says that my program is illegal. In addition,
I see absolutely no good reason, why the language should forbid this. It just
requires an ugly workaround via renaming, which forces me to pollute the object
namespace and makes the code less readable by introducing yet another temporary
name for something. In my case, I make over 30 instantiations (I am writing a type-safe
binding for the linux ioctl() system calls), so I also have to add now over 30
renames, which looks really ugly.

I guess I'll submit it as a bug report to ACT and let them decide whether it is
just an unclear error message or a non-conformity to the RM. In any case, if someone
keeps an Ada 0X wish list, please put adding generic instantiations to 6.1(20) onto
it.

|> I guess this means that an instance of a generic subprogram isn't allowed
|> as a completion for a subprogram declaration.  The obvious workaround
|> is using a renaming declaration.  Of course, the GNAT error message
|> could be a bit more helpful.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Problem with instantiating generic procedure

[Florian Weimer]

mgk25@cl.cam.ac.uk (Markus Kuhn) writes:

> Florian Weimer <fw@s.netic.de>:
> |> ARM 6.1(20):
> |> 
> |> | A subprogram_declaration or a generic_subprogram_declaration requires
> |> | a completion: a body, a renaming_declaration (see 8.5), or a pragma
> |> | Import (see B.1). A completion is not allowed for an
> |> | abstract_subprogram_declaration.
> 
> Thanks! But the RM also says in section 12.3:
> 
>   A generic_instantiation declares an instance; it is equivalent to the
>   instance declaration (a package_declaration or subprogram_declaration)
>   immediately followed by the instance body, both at the place of the
>   instantiation. 
> 
> So if 6.1 says that a subprogram_declaration requires a body and
> 12.3 says that a generic instantiation does provide the equivalent
> of a body, then I still do not understand where the RM says that my
> program is illegal.

You have two subprogram declarations, one in the package specification
and one implicitly created by the instantiation in the package body.
I suppose this isn't allowed (ARM 6.1(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. [...]

> In addition, I see absolutely no good reason, why the language
> should forbid this.

From my limited point of view, I don't see it either.

There's a related thing I'd like to see improved in a future Ada
revision: pragma Import requires the use of renaming declarations as
well if the Ada functions in question are overloaded.  The effects are
quite similar here (namespace pollution).

Re: Problem with instantiating generic procedure

[Robert Dewar]

In article <m3so6mdw05.fsf@deneb.cygnus.stuttgart.netsurf.de>,
  Florian Weimer <fw@s.netic.de> wrote:
> From my limited point of view, I don't see it either.
>
> There's a related thing I'd like to see improved in a future
Ada
> revision: pragma Import requires the use of renaming
declarations as
> well if the Ada functions in question are overloaded.  The
effects are
> quite similar here (namespace pollution).

But the name space pollution is a minimal problem, because it
occurs only in private parts or in package bodies, not in
package specs.

We did discuss the possibility of completing subprogram
declarations with generic instantiations, but it was considered
too much machinery for too little gain.

Remember this is just syntactic sugar for defining a body which
does the instantiation internally and then calls the procedure.
In practice, this is the way it would be implemented in any
case.

I would guess this is in practice of minimal importance. In all
the use of GNAT so far, this issue has never come up, so it is
certainly not something that many people expect to be there!

As for pragma Import, the renaminings can all be done in the
private part, so this is not really a burden:

package p is
   procedure q;
   procedure q (x : integer);
private
   procedure q_no_args renames q;
   procedure q_int_arg (x : integer) renames q;

   pragma Import (C, q_no_args);
   pragma Import (C, q_int_arg);

end p;

Indeed, since you need separate names for the routines that
implement these two cases, forcing names to be used in this
way can actually make things clearer!

>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Problem with instantiating generic procedure

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> But the name space pollution is a minimal problem, because it
> occurs only in private parts or in package bodies, not in
> package specs.

Thanks, I wasn't aware of this.

> I would guess this is in practice of minimal importance. In all
> the use of GNAT so far, this issue has never come up, so it is
> certainly not something that many people expect to be there!

This seems to be case for this specific use of pragma Import as well,
because GNAT 3.11p generates bad code for your example. ;) (A call to
procedure q (with or without an integer argument) results in a `call q'
instruction in both cases, which is certainly wrong.)

> package p is
>    procedure q;
>    procedure q (x : integer);
> private
>    procedure q_no_args renames q;
>    procedure q_int_arg (x : integer) renames q;
> 
>    pragma Import (C, q_no_args);
>    pragma Import (C, q_int_arg);
> 
> end p;

The renaming declaration are `in the wrong direction', I guess.
Something like this is required instead:

package p is
   procedure q;
   procedure q (x : integer);
private
   procedure q_no_args;
   procedure q_int_arg (x : integer);

   pragma Import (C, q_no_args);
   pragma Import (C, q_int_arg);

   procedure q renames q_no_args;
   procedure q (x : integer) renames q_int_arg;
end p;

Re: Problem with instantiating generic procedure

[Chad R. Meiners]

Perhaps the follow solution is an acceptable alterative to renaming generic
instantiations:

Package Generics is

generic
    Type Parameter is private;
procedure G(Item : Parameter);

end Generics;

Package body Generics is

    Procedure G(Item : Parameter) is
    begin
        null;
    end G;

end Generics;

with Generics;
Package Instantiations is

    Procedure A is new Generics.G(Integer);
    --Procedure A(Item : Integer);

end Instantiations;

The only problem with this solution is that Generics is not a private
package, but I don't think that would
be a problem in your case.

-Chad R. Meiners

Markus Kuhn <mgk25@cl.cam.ac.uk> wrote in message
news:7ms4en$kl8$1@pegasus.csx.cam.ac.uk...
> Florian Weimer <fw@s.netic.de>:
> |> ARM 6.1(20):
> |>
> |> | A subprogram_declaration or a generic_subprogram_declaration requires
> |> | a completion: a body, a renaming_declaration (see 8.5), or a pragma
> |> | Import (see B.1). A completion is not allowed for an
> |> | abstract_subprogram_declaration.
>
> Thanks! But the RM also says in section 12.3:
>
>   A generic_instantiation declares an instance; it is equivalent to the
>   instance declaration (a package_declaration or subprogram_declaration)
>   immediately followed by the instance body, both at the place of the
>   instantiation.
>
> So if 6.1 says that a subprogram_declaration requires a body and 12.3 says
that
> a generic instantiation does provide the equivalent of a body, then I
still
> do not understand where the RM says that my program is illegal. In
addition,
> I see absolutely no good reason, why the language should forbid this. It
just
> requires an ugly workaround via renaming, which forces me to pollute the
object
> namespace and makes the code less readable by introducing yet another
temporary
> name for something. In my case, I make over 30 instantiations (I am
writing a type-safe
> binding for the linux ioctl() system calls), so I also have to add now
over 30
> renames, which looks really ugly.
>
> I guess I'll submit it as a bug report to ACT and let them decide whether
it is
> just an unclear error message or a non-conformity to the RM. In any case,
if someone
> keeps an Ada 0X wish list, please put adding generic instantiations to
6.1(20) onto
> it.
>
> |> I guess this means that an instance of a generic subprogram isn't
allowed
> |> as a completion for a subprogram declaration.  The obvious workaround
> |> is using a renaming declaration.  Of course, the GNAT error message
> |> could be a bit more helpful.
>
> Markus
>
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Problem with instantiating generic procedure

[David C. Hoos, Sr.]

Markus Kuhn <mgk25@cl.cam.ac.uk> wrote in message
news:7mqfcq$9og$1@pegasus.csx.cam.ac.uk...
> Sorry, but after searching through the RM for almost an hour, I still
> haven't figured out what I do wrong here and how I should fix this.
> I declare in a package spec a procedure A and I want to implement the
> procedure body of A by instantiating a generic procedure G. The following
> is the shortest possible program that reproduces my problem:
>
> -- bug.ads --
> package Bug is
>
>    procedure A;
>
> end Bug;
> -- bug.adb --
> package body Bug is
>
>    generic
>    procedure G;
>
>    procedure G is
>    begin
>       null;
>    end G;
>
>    procedure A is new G;
>
> end Bug;
> -------------
>
> GNAT 3.11p on Linux insists on the following error message:
>
> bug.adb:1:14: missing body for "A" declared at bug.ads:3
> bug.adb:11:14: "A" conflicts with declaration at bug.ads:3
>
> What is wrong with simply implementing a procedure declared
> in the spec file in the body file by instantiating it from
> a generic procedure of the exact same signature? Both A and G
> have no parameters, so how can there be a conflict?
>
> It would be nice if GNAT wrote out explicitely the two conflicting
> sides, each time it uses the word "conflict" in an error message.
>
> Any idea what is wrong here?

What you have in the instantiation is the declaration of a spec for
procedure A which is a homograph of the declaration in bug.ads --
and, therefore, illegal, conflicting.

Re: Problem with instantiating generic procedure

[Tucker Taft]

Markus Kuhn wrote:
> ...
> 
> What is wrong with simply implementing a procedure declared
> in the spec file in the body file by instantiating it from
> a generic procedure of the exact same signature? Both A and G
> have no parameters, so how can there be a conflict?

We considered allowing a subprogram spec to be completed by
a generic instantiation during the 9X design process.  Ultimately
we chose to only allow renaming-as-body.  So if you want to do
this, you must first do the instantiation using a different name,
and then define the body by renaming this generic.

The rationale behind disallowing a generic instance to be used
directly was as follows:

   A generic instantiation does not include any parameter profile
   for the subprogram being defined.  Hence, matching it up with
   a spec in the presence of overloading could be difficult for the
   reader.  On the other hand, a renaming includes a parameter profile.
   Hence, matching a spec with a renaming-as-body did not impose any
   extra burden on the reader.  Therefore, given the general preference
   for readability over writability, renaming-as-body was proposed as
   the general solution to problems like this, and instantiation-as-body
   was not allowed.

That's the rationale.  I will admit we had a fair amount of discussion
before we came to consensus.  It is always tricky to negotiate these
readability versus writability issues.  In the long run the emphasis
on readability always seems wise, but in the short term, the emphasis
sometimes comes across as just being arbitrarily picky.

> ...
> 
> Any idea what is wrong here?

You need to use renaming-as-body instead.
> 
> Markus
> 
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
-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

Re: Problem with instantiating generic procedure

[Markus Kuhn]

Tucker Taft <stt@averstar.com> writes:
|> The rationale behind disallowing a generic instance to be used
|> directly was as follows:
|> 
|>    A generic instantiation does not include any parameter profile
|>    for the subprogram being defined.  Hence, matching it up with
|>    a spec in the presence of overloading could be difficult for the
|>    reader.  On the other hand, a renaming includes a parameter profile.
|>    Hence, matching a spec with a renaming-as-body did not impose any
|>    extra burden on the reader.  Therefore, given the general preference
|>    for readability over writability, renaming-as-body was proposed as
|>    the general solution to problems like this, and instantiation-as-body
|>    was not allowed.
|> 
|> That's the rationale.  I will admit we had a fair amount of discussion
|> before we came to consensus.  It is always tricky to negotiate these
|> readability versus writability issues.  In the long run the emphasis
|> on readability always seems wise, but in the short term, the emphasis
|> sometimes comes across as just being arbitrarily picky.

Thanks for your reply.

In my particular case, I have around 3 generic procedures, from
which I create over 30 instances, which are then made publically visible.
None of thes procedures is overloaded, they do already have different
names. The over 30 "renames" that I have to add now really decrease
the readability of the code. They add unneeded notational complexity
and destroy much of the codes originally intended notational elegance.
Sure, I can live with it, it is just an example where the intension of
restricting the flexibility of the language to support the reader fired
in the wrong direction.

The concern about supporting the reader versus the writer is a noble one,
but it can be wrong to enforce a bit too much here. Really readable
programs can only be achieved with the active cooperation of the writer.
I think it is not wrong to leave many aspects of what is more readable or
not at the discretion of the writer. It is difficult to forsee all possible
situations at language design time. Indirections and the introduction of
new names can also make code significantly less readable. Our brains have
fixed neurophyisiological limits as to how many objects we can
simultaneously handle in our short-term memory (in the range of 6-8 for
healthy adults), and a blowup in notation will consume some of this very
limited capacity. Sometimes a compact (even if semantically more complex)
notation can help readers to process and perceive the overall situation
hierarchically, while a more lengthy but semantically simpler form does
not support this. Ada unfortunatelly choses sometimes a bit too much
of the latter alternative and I think we have seen an example here.

One of the more important things I learned the hard way over the time was,
that some things are difficult to reason about in a theoretical manner.
They have to be tried and measured instead to get meaningful results.
The performance and efficiency of machine code on modern branch-predicting
superscalar CPUs is one good example. The readability of some
language syntax and semantic for experienced readers is another one.
Both can very easily be misestimated if they are just discussed at an
abstract level without good experimental verification.

Where there ever any controlled readability experiments done during the
Ada design process? I frequently hear that the Pascal syntax style was
considered to be more readable than the C syntax, but is this just
folklore or is there a scientifically quotable foundation for this?

Is for example

  a[i*4+j-32*k+56] += f(4);

really more difficult to read than

  a(i*4+j-32*k+56) := a(i*4-j+32*k+56) + f(4);

and are these two statements equivalent?

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Problem with instantiating generic procedure

[Tucker Taft]

Markus Kuhn wrote:
> The concern about supporting the reader versus the writer is a noble one,
> but it can be wrong to enforce a bit too much here. 

I agree.  It is a tradeoff.  You could argue we erred on
this one.  On the other hand, a systematic naming
convention could make it relatively easy to deal with.

E.g.:

    procedure X_Inst is new G(...);
    procedure X(A, B : Integer) renames X_Inst;

> ...Really readable
> programs can only be achieved with the active cooperation of the writer.

That's certainly true.  On the other hand, I strongly believe that
the design of a language does have a significant effect on the
average readability of code, even when looking at the exact
same pool of programmers.  Languages with a lot of short-hands
to some degree encourage the use of short-hands, which (on the average)
make code harder to read, in my experience.

The goal of Ada is that once the writer succeeded in producing a compilable
program, the meaning is (on the average) quite obvious to the reader.
It does take longer to produce a compilable program, but the clarity
to the subsequent readers makes up for that quickly, in my experience.

> ...
> Where there ever any controlled readability experiments done during the
> Ada design process? I frequently hear that the Pascal syntax style was
> considered to be more readable than the C syntax, but is this just
> folklore or is there a scientifically quotable foundation for this?

The experiments in general involved coding up examples using the competing
proposals, and/or creating "gedanken" experiments relating to maintenance
activities, etc.  Robustness during maintenance activities was also
considered an important criteria.  By forcing the renaming, you get
somewhat better protection if the profile of a generic subprogram changes
(e.g. by the addition of a defaulted parameter), or at least you get
better error messages.  If a generic instantiation were allowed to complete
a subprogram spec, then if the profile of the generic changed, the generic
instantiation would "morph" into a legal stand-alone instantiation, and you
would get a potentially mysterious message that there was no body found
for the subprogram spec.

> Is for example
> 
>   a[i*4+j-32*k+56] += f(4);
> 
> really more difficult to read than
> 
>   a(i*4+j-32*k+56) := a(i*4-j+32*k+56) + f(4);
> 
> and are these two statements equivalent?

I would agree that "+=" is a nice operation, and I often miss
it when coding in Ada.  However, when you start having things like
"X *= A + B" or "Y /= Z-3" the readability of these shortcuts begins to
drop in my view (due to confusions about precedence, etc.).
In the presence of user-defined operators, it is also unclear whether
things like "+=" should be automatically defined by the compiler in terms
of user-defined assignment and user-defined "+", or require its own
explicit user definition.

From my perspective, the most important thing is to have at least
a *goal* of creating a readable, maintainable, safe language.  Of course
you will miss sometimes, but if you don't even try, you will probably
miss most of the time.

> Markus
> 
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
-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

Re: Problem with instantiating generic procedure

[Robert A Duff]

mgk25@cl.cam.ac.uk (Markus Kuhn) writes:

> What is wrong with simply implementing a procedure declared
> in the spec file in the body file by instantiating it from
> a generic procedure of the exact same signature? ...

Nothing, except that it's illegal.  ;-)

The Ada 9X design team proposed to allow this, but it was not considered
important enough -- any language change has some cost, and the benefit
of allowing this is not huge.

Note that in Ada 83, the renaming-as-body didn't exist, so you had to
write a whole wrapper body.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.