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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.55.19.152 with SMTP id 24mr7950290qkt.2.1516921624565; Thu, 25 Jan 2018 15:07:04 -0800 (PST) X-Received: by 10.157.112.213 with SMTP id w21mr134668otj.2.1516921624371; Thu, 25 Jan 2018 15:07:04 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!s47no1004707qta.0!news-out.google.com!g8ni107qtk.0!nntp.google.com!w142no687767ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 25 Jan 2018 15:07:03 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:7466:f44c:da21:40b1; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:7466:f44c:da21:40b1 References: <942235344.537649945.074508.laguest-archeia.com@nntp.aioe.org> <292710c7-3520-406f-9e6b-1fb030ada211@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <348aafc6-2777-4dfe-90af-7ffd094b399a@googlegroups.com> Subject: Re: Five Years After From: Robert Eachus Injection-Date: Thu, 25 Jan 2018 23:07:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 2137081262 X-Received-Bytes: 5833 Xref: reader02.eternal-september.org comp.lang.ada:50153 Date: 2018-01-25T15:07:03-08:00 List-Id: On Thursday, January 25, 2018 at 4:09:28 PM UTC-5, Maciej Sobczak wrote: > > Everyone agrees that the ACATS test suite offers a lot of value to both= =20 > > implementers and users (implementers because an independently sourced a= nd=20 > > trustworthy set of tests is very helpful to creating and maintaining an= Ada=20 > > compiler -- it is especially good IMHO in preventing errors of omission= ,=20 > > which are often the hardest to find; >=20 > Sorry, but I cannot agree here. There is nothing that saves ACATS authors= from errors of omission. The language is itself so complex that creating a= complete (and I really mean formally complete) set of requirements is impr= actical and without such a set it is not possible to create a complete (aga= in, I mean it) set of tests... Almost every compiler developer is aware of the Halting Problem andG=C3=B6d= el's incompleteness theorems. However many programmers and software engine= ers, even if they are aware of them, do not 'get' the fact that you are up = against them in a practical way whenever you use a compiler. (Translating:= There are legal Ada programs such that your compiler will either incorrect= ly reject or fail to halt when asked to compile one of those programs. All= compilers have bugs, at least one of which cannot be eliminated.) In othe= r words, no matter how much testing you do, you cannot eliminate all the bu= gs in a compiler. Note that organizations which develop compilers tend to have an informal hi= erarchy of bugs. The worst is usually assigned to programs that compile wi= th no error messages but produce incorrect output or behavior. Cases where= the compiler crashes or rejects legal Ada programs tend to come next. Near= the bottom of the list are incorrect or misleading error messages. There = is no requirement that some of those exist, but since there are a (countabl= e) infinity of legal Ada programs, and also of illegal Ada programs, there = will always be some cases where the compiler can't guess what the programme= r had in mind. > Unfortunately, no. Every single version of whatever compiler accepts a=20 > different language than its previous version. This is how the bugs are fi= xed > (or introduced), among others. This is true in theory, but much less true in practice. The Unix/Linux pra= ctice for distributing applications, including compilers is a case in point= . Often you will compile tens of thousands of lines of code with no error = messages. If you do get errors, they are much more likely to be from impro= per path arguments or directory locations for the tarball. I used to say that there were two ways I could program (in Ada, Algol, Lisp= , Pascal, PL/I and a few other languages): In one I would produce tens of = thousands of clean code with no compiler bugs found. In the other I felt I= was failing if I had less than one compiler bug discovered per 20 source l= ines. (I don't include C and C++ because even with lint, I have a long way = to go from a clean compile to a working program. In the languages listed, = I almost never read the debugger documentation, and often never used the de= bugger.) What is the difference? In one case I would use only vanilla code. I have= more important things to do than debugging or sending in compiler bug repo= rts. In the other case I would use extreme corners of the language which o= ften went untested by normal test suites. An example: with System; use Ascii; procedure Foo; Many Ada programmers don't know that you can have more than one use clause = following any with clause in a context clause. Or that the use clauses don= 't have to relate to the with clause in any (semantic) way. And Ascii is s= uper special, it is a package that can appear in a use clause without being= in any preceding with clause. So should you use corner cases (with sharp corners)? Only if you are tryin= g to find compiler bugs. Don't let this prevent you from using most, if no= t all of Ada. But if you do need some tricky tasking code, try to keep any= generics that interact with the tasking relatively simple. Using multiple= corner cases in one compilation unit is asking for trouble.