comp.lang.ada
 help / color / mirror / Atom feed
* Adacore Blog - Going Beyond Ada 2022
@ 2021-06-08 13:28 Stephen Davies
  2021-06-09  5:11 ` J-P. Rosen
  0 siblings, 1 reply; 9+ messages in thread
From: Stephen Davies @ 2021-06-08 13:28 UTC (permalink / raw)


The following may be of interest (I was pleased to see fixed lower bounds being considered):

https://blog.adacore.com/going-beyond-ada-2022



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-08 13:28 Adacore Blog - Going Beyond Ada 2022 Stephen Davies
@ 2021-06-09  5:11 ` J-P. Rosen
  2021-06-09 15:10   ` AdaMagica
  0 siblings, 1 reply; 9+ messages in thread
From: J-P. Rosen @ 2021-06-09  5:11 UTC (permalink / raw)


Le 08/06/2021 à 15:28, Stephen Davies a écrit :
> The following may be of interest (I was pleased to see fixed lower bounds being considered):
> 
> https://blog.adacore.com/going-beyond-ada-2022
> 

Of course, everyone is welcome with helping the evolution of Ada. But I 
remind the community that there is the Ada-Comment list 
(http://www.ada-auth.org/comment.html) which is open to the public.

I'm afraid that this initiative of AdaCore is another step in trying to 
control the language.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-09  5:11 ` J-P. Rosen
@ 2021-06-09 15:10   ` AdaMagica
  2021-06-09 16:33     ` Paul Rubin
  0 siblings, 1 reply; 9+ messages in thread
From: AdaMagica @ 2021-06-09 15:10 UTC (permalink / raw)


What troubles me is this statement:

<quote>What happens afterwards
...
Finally, a member of the AdaCore team will give a final decision about the RFC’s inclusion in GNAT, and potential submission to the ARG if necessary.</quote>

Sounds like creating dialects. RFCs implemented in GNAT, but not submitted to ARG. What a mess!

Ada is not owned by AdaCore!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-09 15:10   ` AdaMagica
@ 2021-06-09 16:33     ` Paul Rubin
  2021-06-09 20:53       ` AdaMagica
  0 siblings, 1 reply; 9+ messages in thread
From: Paul Rubin @ 2021-06-09 16:33 UTC (permalink / raw)


AdaMagica <christ-usch.grein@t-online.de> writes:
> Sounds like creating dialects. RFCs implemented in GNAT, but not
> submitted to ARG. What a mess!

It sounded like the RFCs platform is intended to experimentally test
proposed new features, which sounds better than standardizing them
without testing them first.  And hasn't GNAT always has had extensions
beyond the ARM?  Is this anything new?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-09 16:33     ` Paul Rubin
@ 2021-06-09 20:53       ` AdaMagica
  2021-06-10 11:13         ` Emmanuel Briot
  0 siblings, 1 reply; 9+ messages in thread
From: AdaMagica @ 2021-06-09 20:53 UTC (permalink / raw)


Paul Rubin schrieb am Mittwoch, 9. Juni 2021 um 18:33:12 UTC+2:
> And hasn't GNAT always has had extensions 
> beyond the ARM? Is this anything new?

Yes, extensions as allowed in the RM - impl-defined pragmas, attributes...

But not extensions with new syntax.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-09 20:53       ` AdaMagica
@ 2021-06-10 11:13         ` Emmanuel Briot
  2021-06-13 20:29           ` Andreas ZEURCHER
  0 siblings, 1 reply; 9+ messages in thread
From: Emmanuel Briot @ 2021-06-10 11:13 UTC (permalink / raw)


I must admit I do not see the grudge here.
As I understand it, the goal is indeed to test proposals in practice, before 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, 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. 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).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-10 11:13         ` Emmanuel Briot
@ 2021-06-13 20:29           ` Andreas ZEURCHER
  2021-06-14 10:35             ` John McCabe
  0 siblings, 1 reply; 9+ messages in thread
From: Andreas ZEURCHER @ 2021-06-13 20:29 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-13 20:29           ` Andreas ZEURCHER
@ 2021-06-14 10:35             ` John McCabe
  2021-06-14 22:50               ` Randy Brukardt
  0 siblings, 1 reply; 9+ messages in thread
From: John McCabe @ 2021-06-14 10:35 UTC (permalink / raw)


On Sun, 13 Jun 2021 13:29:44 -0700, Andreas ZEURCHER wrote:

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

FWIW, though, the C++ committee appear to think it's acceptable to 
strangle the specification of certain features based on whether or not it 
makes it hard for a specific compiler to implement.

A few weeks ago I had reason to look into the justification for something 
in C++ that appeared, to me, to be stupid and illogical, and the 
reasoning was because "clang does something this way and, if we took the 
sensible approach for this feature, it would mean clang would have to 
massively change".

So now the C++ world is saddled with a specification that's compromised 
by specific implementations.

I've been trying to find the discussion I had about this with some of my 
colleagues at work; if I do, I'll let you know what it is!

However, this is, basically, a potential risk with the AdaCore RFC 
approach; if they forward the feature to the ARG and the ARG comes back 
with "well, nice, but it would be better if it did this", and AdaCore say 
"but that would be too hard for us now", then what happens?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Adacore Blog - Going Beyond Ada 2022
  2021-06-14 10:35             ` John McCabe
@ 2021-06-14 22:50               ` Randy Brukardt
  0 siblings, 0 replies; 9+ messages in thread
From: Randy Brukardt @ 2021-06-14 22:50 UTC (permalink / raw)


"John McCabe" <john@nospam.mccabe.org.uk> wrote in message 
news:sa7bcn$5vn$1@dont-email.me...
> On Sun, 13 Jun 2021 13:29:44 -0700, Andreas ZEURCHER wrote:
...
> However, this is, basically, a potential risk with the AdaCore RFC
> approach; if they forward the feature to the ARG and the ARG comes back
> with "well, nice, but it would be better if it did this", and AdaCore say
> "but that would be too hard for us now", then what happens?

This is a double-edged sword, of course; if something is hard to implement 
(even if better), it might never get adopted at all (look at Algol 68 for a 
historical example of a committee ignoring practical considerations).

And this sort of thing has occurred as far back as Ada 9x: various Ada 9x 
proposals were withdrawn because of opposition from implementers (especially 
DEC, which never actually built an Ada 95 compiler). Perhaps it would have 
been better if those proposals had gone forward, but that's hard to say. 
It's also possible that those proposals would have prevented construction of 
some Ada 95 compilers.

My point is that there needs to be a balance; one should not let one 
implementer or one group dictate everything, but one cannot ignore 
implementers either. (A correlary to that: the implementers should not 
ignore the ARG, either! That happened to some degree with Ada 202x.)

                                  Randy. 


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-06-14 22:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-08 13:28 Adacore Blog - Going Beyond Ada 2022 Stephen Davies
2021-06-09  5:11 ` J-P. Rosen
2021-06-09 15:10   ` AdaMagica
2021-06-09 16:33     ` Paul Rubin
2021-06-09 20:53       ` AdaMagica
2021-06-10 11:13         ` Emmanuel Briot
2021-06-13 20:29           ` Andreas ZEURCHER
2021-06-14 10:35             ` John McCabe
2021-06-14 22:50               ` Randy Brukardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox