From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: pragma/aspect Import, Convention parameters
Date: Mon, 17 Aug 2015 16:54:29 -0500
Organization: JSA Research & Innovation
Message-ID: <mqtl6m$sbi$1@loke.gir.dk>
References: <1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net>
 <14f6844a-0950-4157-80af-d6a962a56246@googlegroups.com>
 <2d5be9db-145c-4f96-ba94-18b73b82d532@googlegroups.com>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1439848471 29042 24.196.82.226 (17 Aug 2015 21:54:31 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Mon, 17 Aug 2015 21:54:31 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:27480
Date: 2015-08-17T16:54:29-05:00
List-Id: <comp.lang.ada>

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