Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
bindings with Ada 2012 aspects
145 views
Skip to first unread message
Jerrid Kimball
Apr 24, 2012, 7:54:50 PM4/24/12
to
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
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
Martin
Apr 25, 2012, 3:43:07 AM4/25/12
to
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
Stephen Leake
Apr 25, 2012, 8:09:26 AM4/25/12
to
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
> 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!
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
Jerrid Kimball
Apr 25, 2012, 10:25:47 AM4/25/12
to
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
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
Randy Brukardt
Apr 25, 2012, 9:47:14 PM4/25/12
to
"Jerrid Kimball" <jer...@kimball.co> wrote in message
news:jn7egd$scs$1...@munin.nbi.dk...
...
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. :-)
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:
> 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?
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. :-)
Jerrid Kimball
Apr 27, 2012, 4:23:13 PM4/27/12
to
On 04/25/2012 08:47 PM, Randy Brukardt wrote:
> "Jerrid Kimball"<jer...@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.
>> 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).
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.
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.
Natasha Kerensikova
May 2, 2012, 8:38:05 AM5/2/12
to
Hello,
On 2012-04-26, Randy Brukardt <ra...@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
On 2012-04-26, Randy Brukardt <ra...@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.
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
Randy Brukardt
May 2, 2012, 8:10:15 PM5/2/12
to
"Natasha Kerensikova" <lithi...@gmail.com> wrote in message
news:slrnjq2ake.1l...@sigil.instinctive.eu...
...
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.
news:slrnjq2ake.1l...@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
> be achieved by the more direct code below?
>
> procedure Bar is new Generic_Bar (Type_1, Do_Real_Stuff);
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.
0 new messages