pragma/aspect Import, Convention parameters

pragma/aspect Import, Convention parameters

[Dmitry A. Kazakov]

Why is it an identifier?

For writing portable code it should be a static expression. The problem is
that much too often the exported functions of the same library have
different conventions on different platforms, e.g.

   procedure Foo ...
   pragma Import (C, Foo, "Foo");  -- Linux

   procedure Foo ...
   pragma Import (StdCall, Foo, "_Foo");  -- Windows

The external name is an expression. Thus you could write something like

   pragma Import (..., Foo, Target.External_Name_Prefix & "Foo");

With External_Name_Prefix defined in a single configuration packet Target
to change. But the convention is not an expression.

There certainly are ways to keep it backward compatible, e.g.

   procedure Foo ...
   pragma Import (User, Foo, "Foo", "Stdcall");

   procedure Foo ... with Convention_Name => "StdCall", ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: pragma/aspect Import, Convention parameters

[G.B.]

On 13.08.15 10:27, Dmitry A. Kazakov wrote:
> But the convention is not an expression.

Maybe reflecting the approaches taken by a compiler
(code generation) vs that of the component that handles
names and locations of external routines (later)?

Re: pragma/aspect Import, Convention parameters

[Dmitry A. Kazakov]

On Thu, 13 Aug 2015 12:24:22 +0200, G.B. wrote:

> On 13.08.15 10:27, Dmitry A. Kazakov wrote:
>> But the convention is not an expression.
> 
> Maybe reflecting the approaches taken by a compiler
> (code generation) vs that of the component that handles
> names and locations of external routines (later)?

It does not matter since both are static anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: pragma/aspect Import, Convention parameters

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
> Why is it an identifier?

Dunno. That's what Ada 95 defined, and we've never had a request to change 
it.

In my experience (which is mostly with rather low-level stuff), there is a 
lot more different than just the convention when changing between Linux and 
Windows (subprogram names, parameter values, etc.) So it's not much of a 
hardship to use separate thin bindings for each -- the differences are 
reconciled in the thick binding anyway.

The problem with such an approach is that conventional version control 
doesn't work very well with it; one needs to control individual blocks with 
some different and many being shared. Ideally, changes in shared parts would 
be reflected in all of the related versions of each package, while changes 
in the unshared parts would not.

We never found a solution to this for Janus/Ada (which has this problem in 
many modules); we extracted some host and target dependencies into dedicated 
packages, but many of them are not so simple and need to be described in 
code. We ended up with a version control overlay which manages the 
relationships between the different versions, so that a change in one 
version would trigger a request to check if the other versions needed 
similar updates (they usually do). But that checking had to be done 
manually.

We side-stepped the problem for Claw by not supporting any other targets 
than Windows. :-) It would have been a lot worse had we wanted to support 
(say) GTK on Linux.

                                     Randy.

Re: pragma/aspect Import, Convention parameters

[Dmitry A. Kazakov]

On Thu, 13 Aug 2015 15:32:23 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
>> Why is it an identifier?
> 
> Dunno. That's what Ada 95 defined, and we've never had a request to change 
> it.

Maybe now? It is not a big change and as much as I hate if-then-else
expressions they could be handy here.

> In my experience (which is mostly with rather low-level stuff), there is a 
> lot more different than just the convention when changing between Linux and 
> Windows (subprogram names, parameter values, etc.)

In these days most upper level libraries are more or less compatible
regarding their API. The main problem is actually names and conventions
because most of them have them build with Visual C for the Windows part and
mimic Windows API, which are StdCall.

> So it's not much of a 
> hardship to use separate thin bindings for each -- the differences are 
> reconciled in the thick binding anyway.

Keeping two versions of *.ads is excessive and a hell of maintenance.
Independently of whether you have thick bindings or not, you have to have
thin bindings first.

> The problem with such an approach is that conventional version control 
> doesn't work very well with it; one needs to control individual blocks with 
> some different and many being shared. Ideally, changes in shared parts would 
> be reflected in all of the related versions of each package, while changes 
> in the unshared parts would not.

Yes, that is the problem. The Ada bindings sources are practically same up
to the pragma Import part.

> We side-stepped the problem for Claw by not supporting any other targets 
> than Windows. :-) It would have been a lot worse had we wanted to support 
> (say) GTK on Linux.

Yes.

However GTK is not a big problem because it has same external names under
Windows and Linux. For really few exceptions GTK's GIO had I used GCC
linker weak references to avoid contamination of *.ads files.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: pragma/aspect Import, Convention parameters

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1xhfjepw437zd.137i8eiplc5lt.dlg@40tude.net...
> On Thu, 13 Aug 2015 15:32:23 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
>>> Why is it an identifier?
>>
>> Dunno. That's what Ada 95 defined, and we've never had a request to 
>> change
>> it.
>
> Maybe now? It is not a big change and as much as I hate if-then-else
> expressions they could be handy here.

As always, send a description of the problem and proposed solution (not just 
the solution, 'cause that will just get put in the dusty drawer never to be 
seen again) to Ada-Comment and it most likely will get considered.

>> In my experience (which is mostly with rather low-level stuff), there is 
>> a
>> lot more different than just the convention when changing between Linux 
>> and
>> Windows (subprogram names, parameter values, etc.)
>
> In these days most upper level libraries are more or less compatible
> regarding their API. The main problem is actually names and conventions
> because most of them have them build with Visual C for the Windows part 
> and
> mimic Windows API, which are StdCall.

That's of course the difference in our experience. I'd almost never use 
"upper-level libraries" for anything; I want as much code as possible that I 
can fix (which means it has to be Ada code at least nominally in our 
control). That's why Claw is the sort of binding that it is, directly to 
Win32.

>> So it's not much of a
>> hardship to use separate thin bindings for each -- the differences are
>> reconciled in the thick binding anyway.
>
> Keeping two versions of *.ads is excessive and a hell of maintenance.
> Independently of whether you have thick bindings or not, you have to have
> thin bindings first.

Right. It *is* a hell of a lot of maintenance -- that goes with the 
territory -- and no one wants to build tools that help. (Conventional 
version control is actively harmful in this, and the C "solution" of a 
preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of 
course, it's possible that one *cannot* write a usable tool that would help 
(I wasn't able to solve the problem adequately for our own use, and I have 
tried).

...
>> We side-stepped the problem for Claw by not supporting any other targets
>> than Windows. :-) It would have been a lot worse had we wanted to support
>> (say) GTK on Linux.
>
> Yes.
>
> However GTK is not a big problem because it has same external names under
> Windows and Linux. For really few exceptions GTK's GIO had I used GCC
> linker weak references to avoid contamination of *.ads files.

There is no way we would have used GTK on Windows. The entire purpose of 
Claw was to give applications the Windows native look-and-feel. I've yet to 
see any GTK application that comes remotely close.

A Linux version of Claw would have existed to emulate as much of that 
Windows look-and-feel as possible on Linux. I probably would have based it 
on GTK as X11 is a nightmare, but it would have been insane to run a program 
that *emulated* the Windows look-and-feel on Windows when a simple 
recompile/relink would have given one the actual look-and-feel.

But I've actually been leaning toward the "portable" version of Claw being 
based in some way on HTML -- essentially what David Botton has been doing 
with Gnoga. (So it probably will never happen, as there doesn't seem like 
there would be any reason.)

                                              Randy.

Re: pragma/aspect Import, Convention parameters

[Shark8]

On Friday, August 14, 2015 at 2:30:29 PM UTC-6, Randy Brukardt wrote:
> 
> Right. It *is* a hell of a lot of maintenance -- that goes with the 
> territory -- and no one wants to build tools that help. (Conventional 
> version control is actively harmful in this, and the C "solution" of a 
> preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of 
> course, it's possible that one *cannot* write a usable tool that would help 
> (I wasn't able to solve the problem adequately for our own use, and I have 
> tried).

I don't know, it sounds kind of like (tangentially, albeit) something that Wulf's IDL would address?  I'm actually starting work on something that could address this issue... but I would love to get your opinion/input.

Re: pragma/aspect Import, Convention parameters

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:9c4e3390-6fcd-4130-a001-76d459cf460c@googlegroups.com...
> On Friday, August 14, 2015 at 2:30:29 PM UTC-6, Randy Brukardt wrote:
>>
>> Right. It *is* a hell of a lot of maintenance -- that goes with the
>> territory -- and no one wants to build tools that help. (Conventional
>> version control is actively harmful in this, and the C "solution" of a
>> preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of
>> course, it's possible that one *cannot* write a usable tool that would 
>> help
>> (I wasn't able to solve the problem adequately for our own use, and I 
>> have
>> tried).
>
> I don't know, it sounds kind of like (tangentially, albeit) something that 
> Wulf's IDL would address?  I'm actually starting work on something that 
> could address this issue... but I would love to get your opinion/input.

Dunno. Do you have a reference to "Wulf's IDL"?

                      Randy.

Re: pragma/aspect Import, Convention parameters

[Bob Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Dunno. Do you have a reference to "Wulf's IDL"?

Google "Wulf IDL" seems to give some info.  This is the IDL that was
used to define the original DIANA.  Not to be confused with CORBA IDL,
which has a similar purpose, but is completely different.

- Bob

Re: pragma/aspect Import, Convention parameters

[Shark8]

On Monday, August 17, 2015 at 3:40:38 PM UTC-6, Randy Brukardt wrote:
> 
> Dunno. Do you have a reference to "Wulf's IDL"?


Yes... but it's paper.
ISBN: 0-7167-8198-0

The original paper is here: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3445&context=compsci (should be reachable by this page: http://repository.cmu.edu/compsci/2412/) -- the document's own page 8 [PDF page 14] lists 'precision' and 'maintainability' as goals.

(The book is for a later development of IDL.)

Re: pragma/aspect Import, Convention parameters

[David Botton]

In GWindows I used expressions based on the Win32 API that one chose to support. Windows has a duplicate Ansi and UNICODE set of APIs. It worked out well. If one wanted to go beyond that use the same approach used for any multi language (English / Chinese / etc) support, string tables.

David Botton

Re: pragma/aspect Import, Convention parameters

[gautier_niouzes]

Le vendredi 14 août 2015 01:42:30 UTC+2, David Botton a écrit :
> In GWindows I used expressions based on the Win32 API that one chose to support. Windows has a duplicate Ansi and UNICODE set of APIs. It worked out well.

It work*s*, and to the full satisfaction of its users :-) !
To be more concrete, GWindows spec. has this (the file gwindows.ads depends on whether ANSI or UNICODE is used):

   Character_Mode_Identifier : constant String := "W";

and there are at hundreds of places in children packages:

   procedure GetTextMetrics
     (HDC : in  GWindows.Types.Handle;
      M   : out Font_Metrics_W);
   pragma Import (StdCall, GetTextMetrics,
                    "GetTextMetrics" & Character_Mode_Identifier);

So, having the convention as a string could be helpful if one needs to switch between C and StdCall as well.
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: pragma/aspect Import, Convention parameters

[Randy Brukardt]

<gautier_niouzes@hotmail.com> wrote in message 
news:2d5be9db-145c-4f96-ba94-18b73b82d532@googlegroups.com...
...
> So, having the convention as a string could be helpful if one needs to 
> switch between C and StdCall as well.

Obviously, it would work (I don't think anyone would doubt that), and it 
would solve the postulated problem. But would it cause more problems that it 
fixed??

Specifically, the problem would be doing that without introducing a 
compatibility problem.

Right now, a convention is an "identifier specific to an aspect" (or 
pragma). It is *not* resolved.

To make it a string expression would require having it resolved. Depending 
upon the mechanism used, that could be a significant compatibility problem 
with existing code.

For instance, one possibility would be for the existing constants to be 
declared somewhere as string constants:

    C : constant String := "C";
    StdCall : constant String := "StdCall";
    ...

Standard is the obvious place, but that has serious implications beyond 
these constants. Even so, let's assume it is there and ignore the effect on 
other visibility for the moment. Even ignoring the problems raised by 
visibility of things in Standard, it still would cause incompatibilities:

    package Foo is
         C : constant Integer := 10;
         A : array (1 .. C) of Integer with Convention => C; -- (1)
         procedure B (N : in Integer) with Convention => C; -- (2)
         ...
    end Foo;

If Convention is a string expression resolved in the normal way, 
declarations (1) and (2) are illegal (the local C is visible rather than the 
ones in Standard). But they're currently legal Ada.

And of course, there would be the ever-popular:

    package Ugh is
         Stdcall : constant String := "C";
         procedure P (N : in Integer) with Convention => Stdcall;
    end Ugh;

Where the meaning would be different in Ada 95-2012 and a hypothetical new 
Ada where convention would be a String.

There may be a way around these issues (one obvious one would be to have a 
new aspect for this purpose, rather than trying to reuse the existing one), 
but this is not an open-and-shut improvement. (Breaking existing Ada code is 
a non-starter for obvious reasons.)

                                       Randy.

Re: pragma/aspect Import, Convention parameters

[Shark8]

On Monday, August 17, 2015 at 3:54:31 PM UTC-6, Randy Brukardt wrote:
> <gautier_niouzes> wrote in message 
> ...
> > So, having the convention as a string could be helpful if one needs to 
> > switch between C and StdCall as well.
> 
> Obviously, it would work (I don't think anyone would doubt that), and it 
> would solve the postulated problem. But would it cause more problems that it 
> fixed??
> 
> Specifically, the problem would be doing that without introducing a 
> compatibility problem.
> 
> Right now, a convention is an "identifier specific to an aspect" (or 
> pragma). It is *not* resolved.
> 
> To make it a string expression would require having it resolved. Depending 
> upon the mechanism used, that could be a significant compatibility problem 
> with existing code.
> 
> For instance, one possibility would be for the existing constants to be 
> declared somewhere as string constants:
> 
>     C : constant String := "C";
>     StdCall : constant String := "StdCall";
>     ...
> 
> Standard is the obvious place, but that has serious implications beyond 
> these constants. Even so, let's assume it is there and ignore the effect on 
> other visibility for the moment. Even ignoring the problems raised by 
> visibility of things in Standard, it still would cause incompatibilities:
> 
>     package Foo is
>          C : constant Integer := 10;
>          A : array (1 .. C) of Integer with Convention => C; -- (1)
>          procedure B (N : in Integer) with Convention => C; -- (2)
>          ...
>     end Foo;
> 
> If Convention is a string expression resolved in the normal way, 
> declarations (1) and (2) are illegal (the local C is visible rather than the 
> ones in Standard). But they're currently legal Ada.
> 
> And of course, there would be the ever-popular:
> 
>     package Ugh is
>          Stdcall : constant String := "C";
>          procedure P (N : in Integer) with Convention => Stdcall;
>     end Ugh;
> 
> Where the meaning would be different in Ada 95-2012 and a hypothetical new 
> Ada where convention would be a String.
> 
> There may be a way around these issues (one obvious one would be to have a 
> new aspect for this purpose, rather than trying to reuse the existing one), 
> but this is not an open-and-shut improvement. (Breaking existing Ada code is 
> a non-starter for obvious reasons.)
> 
>                                        Randy.

One problem is that as a string now you have an explosion of possible conventions, most of which are invalid. (There's also the issue of whether the string's statically known, which it ought to be for the compiler to work properly at compile-time... but something about strings rubs me the wrong way here. [I suppose it's because I consider some enumeration to be a far better modeling of the problem.])