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:a24:2f05:: with SMTP id j5-v6mr1186322itj.37.1529517301016; Wed, 20 Jun 2018 10:55:01 -0700 (PDT) X-Received: by 2002:a9d:296a:: with SMTP id d97-v6mr235440otb.1.1529517299916; Wed, 20 Jun 2018 10:54:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no1311478itj.0!news-out.google.com!c20-v6ni704itc.0!nntp.google.com!u78-v6no1339963itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 20 Jun 2018 10:54:59 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <584564c2-9f64-4965-b045-535cdaf899c0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7cb22c58-3009-47f0-8fe7-62f3cd61785d@googlegroups.com> Subject: Re: Why are Ada compilers difficult to write ? From: "Dan'l Miller" Injection-Date: Wed, 20 Jun 2018 17:55:01 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53209 Date: 2018-06-20T10:54:59-07:00 List-Id: On Wednesday, June 20, 2018 at 10:54:22 AM UTC-5, Jeffrey R. Carter wrote: > On 06/19/2018 11:33 PM, Vincent wrote: > >=20 > > I have often heard that Ada compilers where expensive because they are = very difficult to write, compared to Pascal or C ones. So my question is : = what in the Ada language poses problem to a compiler ? What are the challen= ges ? Where can I find documentation about that ? >=20 > Compared to single-file, sequential languages like Pascal or C, Ada has >=20 > * Packages > * Tasks So does C++17. > * Protected types and objects So does C++98. > * Generics So does C++ (in the GNAT=C2=A0sense of not reusing object code among the va= rious formal type parameters), but this line item should be focused on the = true complexity:=C2=A0=C2=A0generics with elaborate constraints on formal-a= rguments and renaming, which C++ calls concepts and concept-maps, respectiv= ely, which are the perennial rejected feature in the standardization commit= tee, which keeps finding blocking problems in Stroustrup's concept/concept-= map proposals in all of {C++11, C++14, C++17, perhaps C++20 too}. > * Tagged types So does C++ since the early 1980s when it was named C-with-Classes. > * Interfaces So does C++=C2=A0as Taligent-style mixin multiple inheritance, although to = be fair, this is one of the trouble areas for adding concepts/concept-maps = to C++, AIUI. > * Discriminants > * Elaboration > * Finalization So does C++ since the early 1980s back when it was named C-with-Classes. > * Overloading So does C++ since the 1980s. > * Separate compilation with cross-unit checking > * Indefinite types >=20 > and no doubt others I haven't thought of, so hardly any difference at all= . *=C2=A0Optionally-controlled types So does C++, although historically this optionality was crude. In C++11, C= ++14, and C++17, C++=C2=A0finally seems to match Ada's ability to overtly f= ine-tune which types have constructors and destructors. *=C2=A0Exceptions, especially exceptions for finalizing controlled types by= unwinding the call-stack across multiple threads-of-execution. So does C++. C++'s exceptions are even more difficult to implement because= they are arbitrary user-code data structures. Ada's exceptions are fixed = records without any user-domain arbitrary addition of fields or properties = or aspects. *=C2=A0Record representation specification *=C2=A0Moderately generous reflection via 'Tags So does Java and Objective-C runtime-based object models, much more generou= s amount of reflection, in fact. * Numerous aspects (historically standardized as pragmas) So does C++11, C++14, and C++17. *=C2=A0Far fewer topics (than other languages) dismissed as undefined behav= iors or illicit program *=C2=A0Far more topics (than other languages) that a compiler must divulge = as well-known limitations *=C2=A0Case insensitivity in a predominantly case-sensitive Unix/Linux worl= d *=C2=A0A section of the Ada _LRM_ standard commonly called the "heart of da= rkness" which supposedly only a handful of people on the planet grok C++ has had a few a these (e.g., Koenig lookup) where even the vast majorit= y of the people on the standards committee were almost 100% clueless about.= Stroustrup is claiming that more ghosts in the machine are lurking that o= nly a few people partially understand at all: https://www.theregister.co.u= k/2018/06/18/bjarne_stroustrup_c_plus_plus *=C2=A0An _LRM_ standards document both that is quite complex/precise in in= tent but that is written in prose (instead of formal methods or instead of = even system-engineering "shall" requirements)=C2=A0that by ARG's own admiss= ion lacks a sufficiently exhaustive ISO-required glossary of jargon terms t= hat are overtly inventoried as not utilizing the evoked English dictionary = commonfolk definitions *=C2=A0Immense amounts of exceptionalism-based lack of orthogonality: you = can do this in the context of that, but you cannot do this in the context o= f whosiewhatisit, but conversely still you can do a restricted subset of th= is in the context of thingamajig. (Restricted/prohibited in a little prose= here and a little prose there, scattered hither and yon in the _LRM_, of c= ourse. GNAT's internal documentation=C2=A0even discusses this briefly as "= numerous passes" that are "in [ascending] chapter order of the _LRM_" to co= unteract the scattered hither and yon state of affairs. These numerous pas= ses transform the raw syntactic AST into an evermore semantically adorned A= da IR in the GNAT=C2=A0frontend, prior to GIGI.) * (Over-)reliance on the optimizing stages to drastically improve performan= ce based on logical deductions and context analysis, but often not overtly = specifying in the _LRM_=C2=A0the precise set of contextual inputs and steps= of logical deduction to discover that opportunity for optimization So does C++, perhaps ever more so nowadays. Conversely, C++ has so much house-of-cards undefined behavior shakiness tha= t every language feature must tip-toe extraordinarily gently around, that I= am actually surprised that multithreading and move-semantics and futures a= nd ... and ... and ... new features aren't crashing &=C2=A0burning quite of= ten in realworld programs, as this is in the context of that. So when comparing modern Ada to modern C++, it is not clear at all which on= e is more complex of a compiler to implement from scratch. The real differ= ence is that Apple's deep pockets funded the development of Clang from scra= tch. Since the disappearance of the AJPO, Ada has no such deep-pockets fun= der. I am pretty sure that "lack of deep pockets" is actually the best ans= wer to OP's question, not something technical or theoretical.