Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Were there no women, men might live like gods." -- Thomas Dekker


devel / comp.lang.ada / Adacore Blog - Going Beyond Ada 2022

SubjectAuthor
* Adacore Blog - Going Beyond Ada 2022Stephen Davies
`* Re: Adacore Blog - Going Beyond Ada 2022J-P. Rosen
 `* Re: Adacore Blog - Going Beyond Ada 2022AdaMagica
  `* Re: Adacore Blog - Going Beyond Ada 2022Paul Rubin
   `* Re: Adacore Blog - Going Beyond Ada 2022AdaMagica
    `* Re: Adacore Blog - Going Beyond Ada 2022Emmanuel Briot
     `* Re: Adacore Blog - Going Beyond Ada 2022Andreas ZEURCHER
      `* Re: Adacore Blog - Going Beyond Ada 2022John McCabe
       `- Re: Adacore Blog - Going Beyond Ada 2022Randy Brukardt

1
Adacore Blog - Going Beyond Ada 2022

<a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5322&group=comp.lang.ada#5322

 copy link   Newsgroups: comp.lang.ada
X-Received: by 2002:a05:620a:1003:: with SMTP id z3mr21859190qkj.490.1623158915882;
Tue, 08 Jun 2021 06:28:35 -0700 (PDT)
X-Received: by 2002:a25:2b05:: with SMTP id r5mr31717487ybr.465.1623158915669;
Tue, 08 Jun 2021 06:28:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.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: Tue, 8 Jun 2021 06:28:35 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=20.133.40.13; posting-account=YRfoYAoAAADhSEO2nLYx10QUUvp8akYl
NNTP-Posting-Host: 20.133.40.13
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>
Subject: Adacore Blog - Going Beyond Ada 2022
From: jovia...@gmail.com (Stephen Davies)
Injection-Date: Tue, 08 Jun 2021 13:28:35 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Stephen Davies - Tue, 8 Jun 2021 13:28 UTC

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

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

Re: Adacore Blog - Going Beyond Ada 2022

<s9piig$1bn$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5337&group=comp.lang.ada#5337

 copy link   Newsgroups: comp.lang.ada
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ros...@adalog.fr (J-P. Rosen)
Newsgroups: comp.lang.ada
Subject: Re: Adacore Blog - Going Beyond Ada 2022
Date: Wed, 9 Jun 2021 07:11:43 +0200
Organization: Adalog
Lines: 19
Message-ID: <s9piig$1bn$1@dont-email.me>
References: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 05:11:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="417af52da06f95167042d9b7eadb9ef6";
logging-data="1399"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JTTOl+RUAtZoNKJsY8rf3"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:BviSBWByxc0BWTG9hXL0Qi3Id4c=
In-Reply-To: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>
Content-Language: fr
 by: J-P. Rosen - Wed, 9 Jun 2021 05:11 UTC

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

Re: Adacore Blog - Going Beyond Ada 2022

<b05ea19f-aa65-4f94-97a5-0356e4e2a693n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5338&group=comp.lang.ada#5338

 copy link   Newsgroups: comp.lang.ada
X-Received: by 2002:ac8:4e86:: with SMTP id 6mr407445qtp.196.1623251450163;
Wed, 09 Jun 2021 08:10:50 -0700 (PDT)
X-Received: by 2002:a25:cfc3:: with SMTP id f186mr688333ybg.161.1623251450003;
Wed, 09 Jun 2021 08:10:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 9 Jun 2021 08:10:49 -0700 (PDT)
In-Reply-To: <s9piig$1bn$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=94.31.98.170; posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 94.31.98.170
References: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com> <s9piig$1bn$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b05ea19f-aa65-4f94-97a5-0356e4e2a693n@googlegroups.com>
Subject: Re: Adacore Blog - Going Beyond Ada 2022
From: christ-u...@t-online.de (AdaMagica)
Injection-Date: Wed, 09 Jun 2021 15:10:50 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 1545
 by: AdaMagica - Wed, 9 Jun 2021 15:10 UTC

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!

Re: Adacore Blog - Going Beyond Ada 2022

<87v96n2e2h.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5339&group=comp.lang.ada#5339

 copy link   Newsgroups: comp.lang.ada
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.ada
Subject: Re: Adacore Blog - Going Beyond Ada 2022
Date: Wed, 09 Jun 2021 09:33:10 -0700
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <87v96n2e2h.fsf@nightsong.com>
References: <a2188489-c571-40ac-9a07-61417b46d8f1n@googlegroups.com>
<s9piig$1bn$1@dont-email.me>
<b05ea19f-aa65-4f94-97a5-0356e4e2a693n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8a612fa17c2e7dd40cbaf9074acabd0e";
logging-data="18310"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/S8ehaK2bplyL9RevOmYo0"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:1fpZBwICH/V79s457KtAQyLKTXk=
sha1:7h1eRHLWNiiTE8i6QVUPp1sTN1A=
 by: Paul Rubin - Wed, 9 Jun 2021 16:33 UTC

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?

Re: Adacore Blog - Going Beyond Ada 2022

<b7d8c60c-807e-4cd6-9069-4ec1597e0227n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5340&group=comp.lang.ada#5340

 copy link   Newsgroups: comp.lang.ada
X-Received: by 2002:ac8:45da:: with SMTP id e26mr1900109qto.193.1623271991131;
Wed, 09 Jun 2021 13:53:11 -0700 (PDT)
X-Received: by 2002:a25:6d82:: with SMTP id i124mr2689577ybc.165.1623271990949;
Wed, 09 Jun 2021 13:53:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.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: Wed, 9 Jun 2021 13:53:10 -0700 (PDT)
In-Reply-To: <87v96n2e2h.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=94.31.98.170; posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 94.31.98.170
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b7d8c60c-807e-4cd6-9069-4ec1597e0227n@googlegroups.com>
Subject: Re: Adacore Blog - Going Beyond Ada 2022
From: christ-u...@t-online.de (AdaMagica)
Injection-Date: Wed, 09 Jun 2021 20:53:11 +0000
Content-Type: text/plain; charset="UTF-8"
 by: AdaMagica - Wed, 9 Jun 2021 20:53 UTC

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.

Re: Adacore Blog - Going Beyond Ada 2022

<54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5347&group=comp.lang.ada#5347

 copy link   Newsgroups: comp.lang.ada
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: i2pn2.org!i2pn.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: briot.em...@gmail.com (Emmanuel Briot)
Injection-Date: Thu, 10 Jun 2021 11:13:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Emmanuel Briot - Thu, 10 Jun 2021 11:13 UTC

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

Re: Adacore Blog - Going Beyond Ada 2022

<12a77501-1187-4f83-a1ad-8bf7e95b1040n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5408&group=comp.lang.ada#5408

 copy link   Newsgroups: comp.lang.ada
X-Received: by 2002:ac8:5248:: with SMTP id y8mr13646148qtn.346.1623616185487; Sun, 13 Jun 2021 13:29:45 -0700 (PDT)
X-Received: by 2002:a25:4009:: with SMTP id n9mr19536071yba.73.1623616185179; Sun, 13 Jun 2021 13:29:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 13 Jun 2021 13:29:44 -0700 (PDT)
In-Reply-To: <54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=47.185.200.73; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo
NNTP-Posting-Host: 47.185.200.73
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> <54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <12a77501-1187-4f83-a1ad-8bf7e95b1040n@googlegroups.com>
Subject: Re: Adacore Blog - Going Beyond Ada 2022
From: ZUERCHER...@outlook.com (Andreas ZEURCHER)
Injection-Date: Sun, 13 Jun 2021 20:29:45 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 120
 by: Andreas ZEURCHER - Sun, 13 Jun 2021 20:29 UTC

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.

Re: Adacore Blog - Going Beyond Ada 2022

<sa7bcn$5vn$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5411&group=comp.lang.ada#5411

 copy link   Newsgroups: comp.lang.ada
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: joh...@nospam.mccabe.org.uk (John McCabe)
Newsgroups: comp.lang.ada
Subject: Re: Adacore Blog - Going Beyond Ada 2022
Date: Mon, 14 Jun 2021 10:35:03 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <sa7bcn$5vn$1@dont-email.me>
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>
<54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com>
<12a77501-1187-4f83-a1ad-8bf7e95b1040n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 14 Jun 2021 10:35:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0e3b73105d446a5bfdc0e0a76ad73cc4";
logging-data="6135"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19zfnJIeEyVSSsyJYnL/fR0tga1Yfv3pog="
User-Agent: Pan/0.147 (Sweet Solitude; 97d1711 github.com/GNOME/pan.git)
Cancel-Lock: sha1:+5TVfT9WRyjZfukDcqnwW4y8hek=
 by: John McCabe - Mon, 14 Jun 2021 10:35 UTC

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?

Re: Adacore Blog - Going Beyond Ada 2022

<sa8mfj$84q$1@franka.jacob-sparre.dk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=5414&group=comp.lang.ada#5414

 copy link   Newsgroups: comp.lang.ada
Path: i2pn2.org!i2pn.org!paganini.bofh.team!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: ran...@rrsoftware.com (Randy Brukardt)
Newsgroups: comp.lang.ada
Subject: Re: Adacore Blog - Going Beyond Ada 2022
Date: Mon, 14 Jun 2021 17:50:26 -0500
Organization: JSA Research & Innovation
Lines: 28
Message-ID: <sa8mfj$84q$1@franka.jacob-sparre.dk>
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><54c3041a-b68f-4719-88bc-d2a1587a2d2cn@googlegroups.com><12a77501-1187-4f83-a1ad-8bf7e95b1040n@googlegroups.com> <sa7bcn$5vn$1@dont-email.me>
Injection-Date: Mon, 14 Jun 2021 22:50:27 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226";
logging-data="8346"; mail-complaints-to="news@jacob-sparre.dk"
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.7246
 by: Randy Brukardt - Mon, 14 Jun 2021 22:50 UTC

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

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor