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 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:5803:: with SMTP id m3-v6mr9035082iob.22.1528079233031; Sun, 03 Jun 2018 19:27:13 -0700 (PDT) X-Received: by 2002:aca:5208:: with SMTP id g8-v6mr524410oib.1.1528079232926; Sun, 03 Jun 2018 19:27:12 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!news.redatomik.org!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v8-v6no4715788itc.0!news-out.google.com!f20-v6ni3357itd.0!nntp.google.com!v8-v6no4715784itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 3 Jun 2018 19:27:12 -0700 (PDT) In-Reply-To: <99265780.549610525.231930.laguest-archeia.com@nntp.aioe.org> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <99265780.549610525.231930.laguest-archeia.com@nntp.aioe.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <68fd2874-e8ba-49a0-b913-f8c8a0c54954@googlegroups.com> Subject: Re: Ada Successor Language From: "Dan'l Miller" Injection-Date: Mon, 04 Jun 2018 02:27:13 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3119 X-Received-Body-CRC: 3240861932 Xref: reader02.eternal-september.org comp.lang.ada:52901 Date: 2018-06-03T19:27:12-07:00 List-Id: On Saturday, June 2, 2018 at 1:52:13 AM UTC-5, Luke A. Guest wrote: > We should adopt the common C shorthand operators, -=3D, +=3D, etc. Which = means > picking a different /=3D operator, may as well use !=3D here too. If hardwiring C-symbol syntax into next-generation replaces hardwiring Pasc= al/Wirth-esque syntax into Ada8652, then next-generation Ada had better hav= e a hundred or a thousand better reasons to exist than such cosmetic battle= s. The only way that C-symbol syntax should be allowed into next-generatio= n Ada is as per-site policy. Ada already is the A#1 language on the planet* where per-site policies hars= hly restrict which language features are forbidden (e.g., don't use any Ada= 95-or-later features; don't use tagged-record-based features; don't use any= post-Ada95 features whatsoever; don't use anything that begins with unchec= ked_). And this is in addition to Ada's much vaunted profiles of adding fo= cused areas of functionality and/or assurance. * and that is an extraordinarily difficult competition to win versus C++, w= hose coding standards read like a long list of all the dozens to low hundre= ds of undefined-behaviors/gotchas/code-smells to not do. Perhaps Ada should take the hint that its main claim to future fame is to b= e the ultimate language for per-site policy-set custom-tailorization. In t= his view, Ada could have various correctness checks/philosophies turned on = or off. To Luke's C-symbol point, a per-site (or even per-developer) policy could b= e: at check-out, give me the C-symbol alternate syntax, or give me the old= pragma-based syntax, or give me the new aspect-based syntax, or any other = syntactic variant for the same underlying semantic meaning.