Re: Adacore Blog - Going Beyond Ada 2022

[Andreas ZEURCHER <ZUERCHER_Andreas@outlook.com>]

On Thursday, June 10, 2021 at 6:13:27 AM UTC-5, briot wrote:
> I must admit I do not see the grudge here.

Complaint or concern (for the welfare of Ada) should be the word there.  Grudge is a loaded term of long-term hatred, which by definition is absent in this •newly•-arisen topic of 2 competing RFC-esque nonemail commentary/planning/consensus-building forums (ARG's versus AdaCore's).  By having 2 competing consensus-building forums, clearly not all the wood can ever truly be behind one arrow in the consensus building, to paraphrase Scott McNealy.
 
> As I understand it, the goal is indeed to test proposals in practice, before they make it to the standard.

Your wording implies the fundamental danger:  If AdaCore productizes a particular design & implementation prior to even submitting an AI to ARG (as “making it to the standard”s body), then the ARG is implicitly compelled to accept or veto, at the wholesale level, the •entirety• of AdaCore's work on this proposed feature
1) when a quite-different alternative might have been wiser and better for Ada or
2) when course-correction at a key point of departure where AdaCore went off-course might have been wiser.

> 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

“Having a prototype implementation for people to play with is a nice idea” ••only as long as it remains playing nice & fairly•• at the ARG.  As soon as ARG effectively/practically cannot veto & reject some prototype from AdaCore as a partially- or fully-misguided rotten-egg brain-fart, then AdaCore could utilize this technique to try to occlude & preclude all dissenting views in ARG.

> (and what most other languages do in practice).

C++ for example rarely if ever has cases where some core-language feature appeared in GCC or Clang prior to having at least one N-series proposal submitted to the ISO14889 committee (and indeed, not only submitted, but achieving some degree of partial consensus, at least factionally).  For example, Clang has automated reference counting (ARC) only in Objective-C-based modes of operation (including in only certain Objective-C-centric situations of Objective-C++), not in C++ proper.  Likewise with Microsoft's C++/CLI and C++/CX keeping evolution to the core language separate from the committee-draft-proposal-centric main language—a few nonstandard pragma-esque attributes here & there notwithstanding.

Comparing an ISO/IEC-standardized language's process to, say, Python's is disingenuous, because Python is a language historically with a benevolent dictator-individual and a normative reference-implementation interpreter as 1st-class citizen from which all other Python interpreters or compilers are expected to conform meticulously as 2nd-class citizens.  Scala (versus Scala Native) operates much the same way as Python, in this reference-implementation-as-1st-class-citizen-all-others-2nd-class-citizens regard.  Certainly what Ada community might fear is a situation where AdaCore's GNAT is the 1st-class citizen reference-implementation to which all other Ada compilers must conform downstream as mere 2nd-class citizens, where Ada would become the Python model and the Scala-ScalaNative model.

> AdaCore does not *propose* to control the language.
(emphasis added) 

Not all control schemes in the history of humankind have been publicly announced a priori ahead of time, even by slip-of-the-tongue leaks, let alone full-fledged well-crafted well-publicized proposals.  Indeed, some firm control schemes really are pure innocence (not even control schemes at all) at their early stages, only to occur by happenstance as time marches onward (to be realized in historical analysis in retrospect) as quite pernicious after the fact.

> As far as I can tell, these prototypes (like early implementation of what is already in
> Ada 2020) are 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 ASIS or
> libadalang) to test those prototypes, except it might be easier to do directly in the
> compiler for AdaCore.

The problem is not implementing industrial-practice prototypes ••of ARG's proposed AIs•• in the GNAT compiler (or any other vendor's compiler).  The problem is implementing •nonAIs• (other than pragmas and pragma-esque constructs) in the compiler that then are later harshly utilized as established industrial practice to standardize as close to verbatim from the GNAT implementation as possible, given that no other compiler's design of that feature is as mature.  Indeed, ISO/IEC rules strongly favor homologizing •existing• industrial practice over a standards body pontificating any fresh creativity not yet seen in industrial practice.  Homologize is the actual term-of-art there, as utilized throughout ISO, IEC, EU, UN, and other let's-just-get-along international bodies.  Any fresh creativity by ARG competing with AdaCore's establish industrial practice goes against the entire concept of homologizing unless ARG (or whichever let's-all-just-get-along homologizing body) can demonstrate that fresh creativity is absolutely necessary, due to insurmountable impracticalities of endorsement of (one of) the existing industrial practice(s) or blending the multiple industrial practices (of which there likely would be none from the other Ada vendors at the time of debate & standardization of the AI).

> But nothing prevents anyone from writing such a preprocess to test their own proposals. 
> 
> The language remains controlled by the standard, and although there is a large number
> of AdaCore employees in the ARG, that's not all of it. The ada-comment list has another
> purpose that discussing tentative evolution to the language (and email doesn't lend
> itself too well to that purpose anyway).

Then why doesn't AdaCore simply utilize ARG's existing forum of discussion instead of having their own competing forum?  It seems that only 2 are needed:  ①ARG's comment forum and ②email.  It seems that 3 are not needed; it seems that 3's a crowd:  🄰AdaCore's comment forum and 🄱ARG's comment forum and 🄲email.