bindings with Ada 2012 aspects

bindings with Ada 2012 aspects

[Jerrid Kimball]

Hello!  Long time reader, first time poster.

Before I get started, remember that there is a friendly channel on 
Freenode IRC network dedicated to dicussing Ada and creating a general 
sense of community around the language.  The channel population (around 
60) would profit by any additional great conversation or insights that 
can be brought about.  Thanks!

In my spare time I've been tinkering with Ada 2012 and just happened to 
be working on making a C main play nicely with Ada tasking.  Anyway, 
long story short, I came to wanting to export some Ada subprograms for 
the C main to use, but I'm finding that either the appropriate aspects 
are broken in GNAT Pro 7.1w or my understanding of the new syntax is flawed.

As I see it, a pragma Export should be directly replaceable by 
interfacing aspects' aspect marks and definitions:

procedure Wait renames PO.Wait;
pragma Export (C, Wait, "wait");

becomes:

procedure Wait renames PO.Wait
    with Export => True, Convention => C, Link_Name => "wait";

Am I looking at what should be submitted to ACT as a bug?

Jerrid Kimball

Re: bindings with Ada 2012 aspects

[Martin]

On Wednesday, April 25, 2012 12:54:50 AM UTC+1, Jerrid Kimball wrote:
> Hello!  Long time reader, first time poster.
> 
> Before I get started, remember that there is a friendly channel on 
> Freenode IRC network dedicated to dicussing Ada and creating a general 
> sense of community around the language.  The channel population (around 
> 60) would profit by any additional great conversation or insights that 
> can be brought about.  Thanks!
> 
> In my spare time I've been tinkering with Ada 2012 and just happened to 
> be working on making a C main play nicely with Ada tasking.  Anyway, 
> long story short, I came to wanting to export some Ada subprograms for 
> the C main to use, but I'm finding that either the appropriate aspects 
> are broken in GNAT Pro 7.1w or my understanding of the new syntax is flawed.
> 
> As I see it, a pragma Export should be directly replaceable by 
> interfacing aspects' aspect marks and definitions:
> 
> procedure Wait renames PO.Wait;
> pragma Export (C, Wait, "wait");
> 
> becomes:
> 
> procedure Wait renames PO.Wait
>     with Export => True, Convention => C, Link_Name => "wait";
> 
> Am I looking at what should be submitted to ACT as a bug?
> 
> Jerrid Kimball

I've run into 1 'feature' with aspects in GNAT 7.1, which is you can't currently mix them with expression functions.

Ada2012 support is still 'in progress'...but still very useable as is for the most part.

I'm loving the new "for .. of" iterator support - much cleaner code!

Also, expression functions are useful in that I can now leave the package body for subprograms that manipulate state, i.e. actually *do* stuff! Keeps them smaller and should therefore help in understanding as you can see more on one screen at a time.

I've adopted a certain style with expression functions though which is to place them right at the end of the private section of the package spec - after everything else. This keeps the public view free from implementation detail as possible.

-- Martin

Re: bindings with Ada 2012 aspects

[Stephen Leake]

Jerrid Kimball <jerrid@kimball.co> writes:

> Hello!  Long time reader, first time poster.

Welcome!

> Before I get started, remember that there is a friendly channel on
> Freenode IRC network dedicated to dicussing Ada and creating a general
> sense of community around the language.  The channel population
> (around 60) would profit by any additional great conversation or
> insights that can be brought about.  Thanks!

Can you take a moment to explain why you find IRC better than a mailing
list/newsgroup?

I've tried them a few times, and just get frustrated with people not
thinking things thru. 

With a newsgroup, people have time to think before they post.

I guess IRC feels more like being present; maybe I'm just too
anti-social. 

Sorry, can't help with Ada aspects.

-- 
-- Stephe

Re: bindings with Ada 2012 aspects

[Jerrid Kimball]

Hi Stephen

I don't suggest that it is anything more than *another* useful avenue. 
Responses can certainly be less well-formed and conflated with 
non-germaine conversation.  Recognizing the latter, the channel 
ameliorates by decreeing that on-topic conversation should take priority.

There are benefits of both forums.  Clearly for some, the disadvantages 
of one can prevent them from using it.

I want the Ada community to flourish and if that means trying to drag it 
from one out-dated technology to another I will!

Cheers

On 04/25/2012 07:09 AM, Stephen Leake wrote:
> Jerrid Kimball<jerrid@kimball.co>  writes:
>
>> Hello!  Long time reader, first time poster.
>
> Welcome!
>
>> Before I get started, remember that there is a friendly channel on
>> Freenode IRC network dedicated to dicussing Ada and creating a general
>> sense of community around the language.  The channel population
>> (around 60) would profit by any additional great conversation or
>> insights that can be brought about.  Thanks!
>
> Can you take a moment to explain why you find IRC better than a mailing
> list/newsgroup?
>
> I've tried them a few times, and just get frustrated with people not
> thinking things thru.
>
> With a newsgroup, people have time to think before they post.
>
> I guess IRC feels more like being present; maybe I'm just too
> anti-social.
>
> Sorry, can't help with Ada aspects.
>

Re: bindings with Ada 2012 aspects

[Randy Brukardt]

"Jerrid Kimball" <jerrid@kimball.co> wrote in message 
news:jn7egd$scs$1@munin.nbi.dk...
...
> As I see it, a pragma Export should be directly replaceable by interfacing 
> aspects' aspect marks and definitions:
>
> procedure Wait renames PO.Wait;
> pragma Export (C, Wait, "wait");
>
> becomes:
>
> procedure Wait renames PO.Wait
>    with Export => True, Convention => C, Link_Name => "wait";
>
> Am I looking at what should be submitted to ACT as a bug?

I believe this replacement is correct, except for one tiny detail:

No language-defined aspects are allowed on renames, and the above is a 
renames.

The reason is that almost all language-defined aspects are the same for all 
views of an entity, and a rename just introduces another view. Moreover, 
this renames "trick" exists for pragmas simply to get around the limitations 
of pragmas for overloaded entities, something that is totally unnecessary 
for aspects.

I think in this particular case, you are trying to create a wrapper with 
this renames (as opposed to "just" another view of the original subprogram). 
I think that allowing the original pragma is dubious (although an 
implementation is allowed to support Import and Export on anything they 
like -- but it certainly is *not* portable).

So, I think you need to replace this subprogram renames by a real subprogram 
(one that calls PO.Wait in it's body), and I suspect if you do that you'll 
have no problems with the aspects.

                             Randy Brukardt, Editor, ISO/IEC 8652:tdb. :-)

Re: bindings with Ada 2012 aspects

[Jerrid Kimball]

On 04/25/2012 08:47 PM, Randy Brukardt wrote:
> "Jerrid Kimball"<jerrid@kimball.co>  wrote in message
> news:jn7egd$scs$1@munin.nbi.dk...
> ....
>> As I see it, a pragma Export should be directly replaceable by interfacing
>> aspects' aspect marks and definitions:
>>
>> procedure Wait renames PO.Wait;
>> pragma Export (C, Wait, "wait");
>>
>> becomes:
>>
>> procedure Wait renames PO.Wait
>>     with Export =>  True, Convention =>  C, Link_Name =>  "wait";
>>
>> Am I looking at what should be submitted to ACT as a bug?
>
> I believe this replacement is correct, except for one tiny detail:
>
> No language-defined aspects are allowed on renames, and the above is a
> renames.
>
> The reason is that almost all language-defined aspects are the same for all
> views of an entity, and a rename just introduces another view. Moreover,
> this renames "trick" exists for pragmas simply to get around the limitations
> of pragmas for overloaded entities, something that is totally unnecessary
> for aspects.
>
> I think in this particular case, you are trying to create a wrapper with
> this renames (as opposed to "just" another view of the original subprogram).
> I think that allowing the original pragma is dubious (although an
> implementation is allowed to support Import and Export on anything they
> like -- but it certainly is *not* portable).

Thanks for that.  I hadn't considered that it would be unportable. 
Frankly, I haven't read where pragma Export is actually valid, but shall 
do so now.

>
> So, I think you need to replace this subprogram renames by a real subprogram
> (one that calls PO.Wait in it's body), and I suspect if you do that you'll
> have no problems with the aspects.

You may expect this, but the problem remains.  I failed to include my 
other testing in my original post; it fails no matter what.  I'll 
attempt on a newer wavefront as I can and update if I remember.

>
>                               Randy Brukardt, Editor, ISO/IEC 8652:tdb. :-)
>
>
>
>
>

Re: bindings with Ada 2012 aspects

[Natasha Kerensikova]

Hello,

On 2012-04-26, Randy Brukardt <randy@rrsoftware.com> wrote:
> No language-defined aspects are allowed on renames, and the above is a 
> renames.
>
> The reason is that almost all language-defined aspects are the same for all 
> views of an entity, and a rename just introduces another view. Moreover, 
> this renames "trick" exists for pragmas simply to get around the limitations 
> of pragmas for overloaded entities, something that is totally unnecessary 
> for aspects.

I'm sorry to derail this thread a bit, but this interesting description
of renames makes we wonder even more why they are needed for public
subprograms implemented by generic instantiation. Like the following:

package Foo;

   procedure Bar (Arg_1 : in out Type_1; Arg_2 : in Type_2);

end Foo;

package body Foo

   generic
      type Formal_Type;
      with procedure Do_Stuff (Arg_2 : in Type_2);
   procedure Generic_Bar (Arg_1 : in out Formal_Type; Arg_2 : in Type_2);

   procedure Bar_Instance is new Generic_Bar (Type_1, Do_Real_Stuff);

   procedure Bar (Arg_1 : in out Type_1; Arg_2 : in Type_2)
      renames Bar_Instance;

end Foo;


What is so special about "just [introducing] another view" that cannot
be achieved by the more direct code below?

   procedure Bar is new Generic_Bar (Type_1, Do_Real_Stuff);



Thanks for your insights,
Natasha

Re: bindings with Ada 2012 aspects

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@gmail.com> wrote in message 
news:slrnjq2ake.1lme.lithiumcat@sigil.instinctive.eu...
...
> What is so special about "just [introducing] another view" that cannot
> be achieved by the more direct code below?
>
>   procedure Bar is new Generic_Bar (Type_1, Do_Real_Stuff);

This is a "renames-as-body", and it causes problems because you might have 
conflicts between the aspects that are defined (explicitly or implicity) for 
the specification, and those that are defined for the instance by the 
generic definition. Other kinds of renames-as-body have fewer problems with 
this.

You're *never* allowed to specify language-defined aspects on a body (of any 
kind) [which is more about the original topic than your question].

In this specific case of Janus/Ada, the actual call profile of a generic 
instantiation is different than the call profile of a non-generic subprogram 
with the same set of parameters. So to make this work, there has to be a 
wrapper or some other "connector" generated. Other implementations also have 
various issues with this.

This is a lots of work, and it was never felt that this was common enough 
that allowing it would make any real difference. That's because the vast 
majority of generic units are packages, and this would do nothing to help 
for a generic package instantiation. Maybe that judgement was wrong; but 
even if the language was changed this would be low priority to change in 
Janus/Ada simply because it would be a lot of work, and there are many other 
projects which would have more benefit to our customers than this one.

It should be noted that this was decided during Ada 95, and it never has 
been revisited since (to my knowledge), so perhaps it would make some sense 
to revisit this for Ada 2020.

                                     Randy.