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:
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:
> 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.
Jerrid Kimball <jer...@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.
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!
>> 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.
> 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.
> "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:
>> 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.
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);
> 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.
