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:fc13:: with SMTP id r19-v6mr4911720ioh.7.1527860136008; Fri, 01 Jun 2018 06:35:36 -0700 (PDT) X-Received: by 2002:a9d:738f:: with SMTP id j15-v6mr470103otk.6.1527860135787; Fri, 01 Jun 2018 06:35:35 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!newsreader5.netcologne.de!news.netcologne.de!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-v6no2008124itc.0!news-out.google.com!f20-v6ni1255itd.0!nntp.google.com!u74-v6no2019793itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 1 Jun 2018 06:35:35 -0700 (PDT) In-Reply-To: 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: <55ce14eb-6b83-4ea0-a550-f9e1410d0b06@googlegroups.com> <51dfb377-1b3e-45ca-a211-158101efe557@googlegroups.com> <090d6eb2-9f52-4471-a22e-ce1bdf457188@googlegroups.com> <90f0f8da-dadd-4341-bc0f-dbda94b0516c@googlegroups.com> <137bcc76-2489-4557-979b-5efeecbd9289@googlegroups.com> <02ca60ab-0cf6-45d6-bed5-0358d4f5763d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Strings with discriminated records From: "Dan'l Miller" Injection-Date: Fri, 01 Jun 2018 13:35:35 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5270 X-Received-Body-CRC: 1923154966 Xref: reader02.eternal-september.org comp.lang.ada:52839 Date: 2018-06-01T06:35:35-07:00 List-Id: On Thursday, May 31, 2018 at 5:18:51 PM UTC-5, Randy Brukardt wrote: > Whenever large amounts of code depend on some package, causing unusual=20 > illegalities in working code just because of the addition of a new=20 > object/exception is a major problem. Consider something like Claw: we hav= e=20 > to avoid making changes to the specs -- even ones that are clearly good= =20 > ideas -- in order to avoid breaking user code. In that hypothetical Ada++ for the 21st century, every externally-visible p= ortion of the interface of a package would be required to be versioned, so = that laggards can stay with the old clunky version-x interface unmodified a= nd trendy people can run with the Cool Kids by using the next-gen version-x= +1 interface. (I word that with a bit of humor there, but I mean it seriously as the key = remaining largely-untouched obstacle to writing software-in-the-large in an= y programming language that purports to support programming software-in-the= -large at the millions or tens-of-millions of lines of code level. We have= succeeded in almost all other aspects of writing software-in-the-large but= have failed miserably on this one that you bring up above=E2=80=94mainly b= ecause no one ever tried to tackle it in a programming language. Btw, for = distributed systems communicating via packets, we solved that versioned-int= erface problem via TLVs: don't recognize the new tag?; then you already kn= ow from Day One to ignore any unrecognized next-gen subTLV including this o= ne, you uncouth laggard old long-in-the-tooth software, but use the backwar= ds-compatibility mode of the containing TLV instead.) > Similarly, I have to document=20 > *every single* change in a language-defined package as an incompatibility= -- =20 > even though only people overusing use clauses have a possibility of such = an=20 > incompatibility. An Ada compiler seeing a combination of 1) a pragma/aspect on that specification and 2) the overuse of use-clause for that package could automate that, obviating the need for such documentation to human-bei= ngs; human beings are not trustworthy to read anything. Again, Ada++ for t= he 21st century would have that feature because it is obviously needed for = programming software-in-the-large. Indeed, Ada++ for the 21st century would just entirely remove the syntax fo= r overusing use-clauses, forcing the more-piecemeal alternative*. * or indeed forcing my own personal style in all programming languages that= support it: (almost) never use a use-clause, but always declare 1-, 2-, o= r 3-character abbreviations for packagename-paths, and then prefix every si= ngle identifier in app-domain source-code with that abbreviation (the =E2= =80=9Calmost=E2=80=9D there: use use-clauses to obtain operators and non-i= nheritance type-extensions in the languages that have those, only because t= here seems to be no alternative). These abbrevs actually drastically impro= ve the readability of the code, because a human being can see at a glance t= he various packages interacting with each other, such as to transliterate o= ne package's (or app-domain's) worldview/contract/terms into another packag= e's different worldview/contract/terms.