Re: Why are Ada compilers difficult to write ?

["Dan'l Miller" <optikos@verizon.net>]

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:
> > 
> > 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 challenges ? Where can I find documentation about that ?
> 
> Compared to single-file, sequential languages like Pascal or C, Ada has
> 
> * Packages
> * Tasks

So does C++17.

> * Protected types and objects

So does C++98.

> * Generics

So does C++ (in the GNAT sense of not reusing object code among the various formal type parameters), but this line item should be focused on the true complexity:  generics with elaborate constraints on formal-arguments and renaming, which C++ calls concepts and concept-maps, respectively, which are the perennial rejected feature in the standardization committee, 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++ as 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
> 
> and no doubt others I haven't thought of, so hardly any difference at all.

* Optionally-controlled types

So does C++, although historically this optionality was crude.  In C++11, C++14, and C++17, C++ finally seems to match Ada's ability to overtly fine-tune which types have constructors and destructors.

* Exceptions, 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.

* Record representation specification

* Moderately generous reflection via 'Tags

So does Java and Objective-C runtime-based object models, much more generous amount of reflection, in fact.

* Numerous aspects (historically standardized as pragmas)

So does C++11, C++14, and C++17.

* Far fewer topics (than other languages) dismissed as undefined behaviors or illicit program

* Far more topics (than other languages) that a compiler must divulge as well-known limitations

* Case insensitivity in a predominantly case-sensitive Unix/Linux world

* A section of the Ada _LRM_ standard commonly called the "heart of darkness" 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 majority of the people on the standards committee were almost 100% clueless about.  Stroustrup is claiming that more ghosts in the machine are lurking that only a few people partially understand at all:  https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus

* An _LRM_ standards document both that is quite complex/precise in intent but that is written in prose (instead of formal methods or instead of even system-engineering "shall" requirements) that by ARG's own admission lacks a sufficiently exhaustive ISO-required glossary of jargon terms that are overtly inventoried as not utilizing the evoked English dictionary commonfolk definitions

* Immense amounts of exceptionalism-based lack of orthogonality:  you can do this in the context of that, but you cannot do this in the context of whosiewhatisit, but conversely still you can do a restricted subset of this 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 course.  GNAT's internal documentation even discusses this briefly as "numerous passes" that are "in [ascending] chapter order of the _LRM_" to counteract the scattered hither and yon state of affairs.  These numerous passes transform the raw syntactic AST into an evermore semantically adorned Ada IR in the GNAT frontend, prior to GIGI.)

* (Over-)reliance on the optimizing stages to drastically improve performance based on logical deductions and context analysis, but often not overtly specifying in the _LRM_ the 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 that every language feature must tip-toe extraordinarily gently around, that I am actually surprised that multithreading and move-semantics and futures and ... and ... and ... new features aren't crashing & burning quite often 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 one is more complex of a compiler to implement from scratch.  The real difference is that Apple's deep pockets funded the development of Clang from scratch.  Since the disappearance of the AJPO, Ada has no such deep-pockets funder.  I am pretty sure that "lack of deep pockets" is actually the best answer to OP's question, not something technical or theoretical.