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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.182.49.233 with SMTP id x9mr2930807obn.0.1440086876013;
        Thu, 20 Aug 2015 09:07:56 -0700 (PDT)
X-Received: by 10.182.130.164 with SMTP id of4mr48759obb.42.1440086875981;
 Thu, 20 Aug 2015 09:07:55 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!se8no7094619igc.0!news-out.google.com!nt1ni10076igb.0!nntp.google.com!x6no2500095igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 20 Aug 2015 09:07:55 -0700 (PDT)
In-Reply-To: <mqtl6m$sbi$1@loke.gir.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=75.161.23.130;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 75.161.23.130
References: <1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net>
 <14f6844a-0950-4157-80af-d6a962a56246@googlegroups.com>
 <2d5be9db-145c-4f96-ba94-18b73b82d532@googlegroups.com>
 <mqtl6m$sbi$1@loke.gir.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <21a750b6-9fec-4775-ad18-5c5253564abb@googlegroups.com>
Subject: Re: pragma/aspect Import, Convention parameters
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Thu, 20 Aug 2015 16:07:56 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:27528
Date: 2015-08-20T09:07:55-07:00
List-Id: <comp.lang.ada>

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

One problem is that as a string now you have an explosion of possible conve=
ntions, most of which are invalid. (There's also the issue of whether the s=
tring's statically known, which it ought to be for the compiler to work pro=
perly 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 bette=
r modeling of the problem.])