Re: pragma/aspect Import, Convention parameters

[Shark8 <onewingedshark@gmail.com>]

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.])