From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.5-pre1
X-Received: by 2002:a37:503:: with SMTP id 3mr3967465qkf.417.1623323606569;
        Thu, 10 Jun 2021 04:13:26 -0700 (PDT)
X-Received: by 2002:a25:cb48:: with SMTP id b69mr6732668ybg.173.1623323606337;
 Thu, 10 Jun 2021 04:13:26 -0700 (PDT)
Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 10 Jun 2021 04:13:26 -0700 (PDT)
In-Reply-To: <b7d8c60c-807e-4cd6-9069-4ec1597e0227n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=87.88.29.208; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 87.88.29.208
References: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>
 <s9piig$1bn$1@dont-email.me> <b05ea19f-aa65-4f94-97a5-0356e4e2a693n@googlegroups.com>
 <87v96n2e2h.fsf@nightsong.com> <b7d8c60c-807e-4cd6-9069-4ec1597e0227n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com>
Subject: Re: Adacore Blog - Going Beyond Ada 2022
From: Emmanuel Briot <briot.emmanuel@gmail.com>
Injection-Date: Thu, 10 Jun 2021 11:13:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org comp.lang.ada:62161
List-Id: <comp.lang.ada>

I must admit I do not see the grudge here.
As I understand it, the goal is indeed to test proposals in practice, befor=
e they make it to the standard. There has been a number of evolution to the=
 language that are not so convenient to use, for instance, or not flexible =
enough. Having a prototype implementation for people to play with is a nice=
 idea (and what most other languages do in practice).
AdaCore does not propose to control the language. As far as I can tell, the=
se prototypes (like early implementation of what is already in Ada 2020) ar=
e generally controlled via the -gnatX switch. If you do not use that, then =
you do not have access to those new proposals either.

This is akin to implementing some pre-processing tool (for instance using A=
SIS or libadalang) to test those prototypes, except it might be easier to d=
o directly in the compiler for AdaCore. But nothing prevents anyone from wr=
iting such a preprocess to test their own proposals.

The language remains controlled by the standard, and although there is a la=
rge number of AdaCore employees in the ARG, that's not all of it. The ada-c=
omment list has another purpose that discussing tentative evolution to the =
language (and email doesn't lend itself too well to that purpose anyway).