Why are Ada compilers difficult to write ?

[Vincent]

Dear Ada programers,

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 ?

Regards,

Vincent

[Paul Rubin]

Vincent <vincent....@gmail.com> writes:
> I have often heard that Ada compilers where expensive because they are
> very difficult to write, compared to Pascal or C ones.

Meh, I'd say it's more of a niche market whose customers tend to have
extreme requirements and large budgets. Ada might be harder to compile
than C or Pascal, but not by *that* much, and it's almost certainly
easier to compile than C++. There is simply less demand, so the
development costs are spread across fewer people.

[Jacob Sparre Andersen]

Vincent <vincent....@gmail.com> writes:

> 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 ?

Supposedly (I have never written an Ada compiler), one of the hard parts
is to get overload resolution correct.

I can imagine that handling of accessibility of anonymous access types
(3.10.2?) can be a challenge as well.

There is also some work in handling explicitly specified record layouts
correctly, but I don't think it can be much worse than a special case of
packed records.

And finally, I suspect the fact that there is an actual validation test
suite makes it hard to get away with claiming that something is an Ada
compiler, if it doesn't implement the whole language.

Greetings,

Jacob
--
"Three can keep a secret if two of them are dead."

[Lucretia]

On Tuesday, 19 June 2018 22:43:11 UTC+1, Paul Rubin wrote:

> Vincent <com> writes:

> Meh, I'd say it's more of a niche market whose customers tend to have
> extreme requirements and large budgets. Ada might be harder to compile
> than C or Pascal, but not by *that* much, and it's almost certainly

You are living in a dream world I f you think that.

[Lucretia]

On Tuesday, 19 June 2018 22:33:38 UTC+1, Vincent wrote:
> Dear Ada programers,
>
> 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 ?

Here are the issues I see:

1) Getting the grammar from the AARM correct, because it's highly ambiguous, doesn't include the pragmas (still!!!!) in the correct places and that it includes semantic info, especially for ID's.

2) There are many many many rules that have to be observed *and* documented for each implementation.

3) Overload resolution, as Jacob mentioned, it apparently a bitch.

4) It's a big language, including abstracted threaded via tasks, protected objects, so it's not as simple as just writing a Pascal subset.

Pascal as originally designed is tiny and can be implemented within a few days to a week. TBH I think I could knock up a Pascal scanner and parser in an afternoon, that's half of it done, stick it onto LLVM and it yer done.

C is a massive bag of shit and would take ages to write a *decent* compiler for, it has soooooooooooooooooooooooo many edge cases because it's such a mess. Even though, all it is, is a simple list of declarations (variable, constant, functions "prototypes"), function "bodies" and "types," but it's everything else that's the problem with C.

[Lucretia]

On Tuesday, 19 June 2018 23:01:02 UTC+1, Jacob Sparre Andersen wrote:

> And finally, I suspect the fact that there is an actual validation test
> suite makes it hard to get away with claiming that something is an Ada
> compiler, if it doesn't implement the whole language.

Subsets are allowed now via pragma Restrictions and pragma Profile, so that's no longer true.

[Dan'l Miller]

The ARG mailing list (and extracts thereof, as appearing as appendix to each AI) is filled with descriptions of how over-the-top difficult some proposal is until the complexity of the proposal is whittled down. That is the forum where the luminaries & experts of Ada-world come together to discuss that complexity-of-the-compiler topic, as represented by each Ada compiler vendor.

Also, there is this ominous house-of-cards complexity warning in C++world from the progenitor of C++ himself:

https://www.TheRegister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus

[gautier...@hotmail.com]

The challenges are roughly the features that make the programmer's life easier: the burden is moved to the compiler writers.
You can begin with unconstrained types whose sizes are not known at compile-time. Then variables of unconstrained types which are sized on initialization. Then add exceptions. Add packages. Then generics (not just macros).

For the fun of it, you find a full Pascal-in-Pascal here:
http://www.moorecad.com/standardpascal/pascals.pas

...and a remote descendant here (HAC, +/- a Pascal with Ada syntax):
https://sourceforge.net/projects/hacadacompiler/
- none of the mentioned goodies like unconstrained types are present in HAC so far...

[Jeffrey R. Carter]

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
* Protected types and objects
* Generics
* Tagged types
* Interfaces
* Discriminants
* Elaboration
* Finalization
* Overloading
* Separate compilation with cross-unit checking
* Indefinite types

and no doubt others I haven't thought of, so hardly any difference at all.

--
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

[Dan'l Miller]

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.

[Dan'l Miller]

On Wednesday, June 20, 2018 at 12:55:02 PM UTC-5, Dan'l Miller wrote:
> 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

Oh, I forgot:
Separate compilation of templates has been attempted twice in C++:

1) template export:  only one compiler (Edison Design Group) ever got it working, then fairly immediately deprecated it. https://stackoverflow.com/questions/5416872/using-export-keyword-with-templates

2) template modules: still a work-in-progress. The jury is still out.

Apparently this is truly an outstanding engineering-achievement accomplishment of mastery of difficulty for Ada compilers, because C++ has been trying for over a decade to replicate Ada's accomplishment. Template export failed miserably. Template modules are still not stable enough to be in a C++ programmer's everyday repertoire.

[Luke A. Guest]

Dan'l Miller <et> wrote:

>> * Tasks
>
> So does C++17.
>
>> * Protected types and objects
>
> So does C++98.
>

Hardly. You can’t compare Ada’s high level tasking to the thin veneer over
threading that’s in C++. Come on.


>> * Discriminants
>> * Elaboration

Oh I forgot that doctors and stir sections are equivalent to Ada’s
elaboration. Those sections just call the constructors and destructors.m,
it’s very primitive. You also can’t do complex initialisations in C++ like
in Ada.

> * Moderately generous reflection via 'Tags

Pick any C++ lib which hasn’t reimplemented this!

> * Numerous aspects (historically standardized as pragmas)
>
> So does C++11, C++14, and C++17.

Really? Which?

[Dan'l Miller]

On Wednesday, June 20, 2018 at 1:58:54 PM UTC-5, Luke A. Guest wrote:
> Dan'l Miller <et> wrote:
>
> >> * Tasks
> >
> > So does C++17.
> >
> >> * Protected types and objects
> >
> > So does C++98.
> >
>
> Hardly. You can’t compare Ada’s high level tasking to the thin veneer over
> threading that’s in C++. Come on.

Ummmm, apparently you are stuck in 1992 or something. C++ ain't your father's Oldsmobile anymore, to paraphrase the old television commercials. Time marched onward in C++, as shown in the timeline at the URL below. Threads-of-execution, sequence points, thread-local storage, condition variables, multireader-uniwriter locks, threadsafe STL, atomic smart pointers, futures, latches & barriers, coroutines, transactional memory, task blocks (i.e., rendezvous), plus inheriting C99's and C11's work on multithreading and lack-of-aliasing.
http://www.modernescpp.com/index.php/multithreading-in-c-17-and-c-20

Your point would be well taken if you were to shift to stability. Ada pays especial attention to making sure that everything works together, whereas C++ plays the "undefined behavior" card too often, especially regarding multithreading interacting with other language features, most especially multithreading interacting with other undefined-behavior-swiss-cheese language features. C++ having a language feature and C++ having a language feature that isn't like stepping gingerly through a land-mine field are 2 entirely different things.

> >> * Discriminants
> >> * Elaboration
>
> Oh I forgot that doctors and stir sections are equivalent to Ada’s
> elaboration. Those sections just call the constructors and destructors.m,
> it’s very primitive. You also can’t do complex initialisations in C++ like
> in Ada.

I did amend Jeffrey Carter's claim that Ada has a quite deluxe elaboration feature-set that very few if any other languages attempt to provide. Perhaps you intended this reply to be inserted after some other topic instead.

> > * Moderately generous reflection via 'Tags
>
> Pick any C++ lib which hasn’t reimplemented this!

An arbitrary C++ lib in the C++ user community is not ISO14488 standard C++ in the compiler. The OP is talking about compilers implementing language standards, not some arbitrary library out in the user community.

> > * Numerous aspects (historically standardized as pragmas)
> >
> > So does C++11, C++14, and C++17.
>
> Really? Which?

http://en.cppreference.com/w/cpp/language/attributes

12 of them standardized so far up to C++17, more likely coming in C++20:
alignas, noreturn, carries_dependency, deprecated, deprecated("reason"), fallthrough, nodiscard, maybe_unused, likely, unlikely, no_unique_address, optimize_for_synchronized

... plus many more proprietary ones in GNU, IBM, and Microsoft C++ compilers.

Btw, with the exception of alignas and deprecated, C++'s attributes that have been standardized so far seem more hackerish than Ada's more pure-essence-of-reality aspects/pragmas. But to the OP's question (and refuting Carter's claim), both C++ and Ada have aspects/attributes that need rather similar difficulty of implementation as popping up sporadically in the grammar, complicating what was a pristine much-simpler grammar decades ago.

[Dan'l Miller]

On Wednesday, June 20, 2018 at 2:37:31 PM UTC-5, Dan'l Miller wrote:
> On Wednesday, June 20, 2018 at 1:58:54 PM UTC-5, Luke A. Guest wrote:
> > Dan'l Miller <et> wrote:
> >
> > >> * Tasks
> > >
> > > So does C++17.
> > >
> > >> * Protected types and objects
> > >
> > > So does C++98.
> > >
> >
> > Hardly. You can’t compare Ada’s high level tasking to the thin veneer over
> > threading that’s in C++. Come on.
>
> Ummmm, apparently you are stuck in 1992 or something. C++ ain't your father's Oldsmobile anymore, to paraphrase the old television commercials. Time marched onward in C++, as shown in the timeline at the URL below. Threads-of-execution, sequence points, thread-local storage, condition variables, multireader-uniwriter locks, threadsafe STL, atomic smart pointers, futures, latches & barriers, coroutines, transactional memory, task blocks (i.e., rendezvous), plus inheriting C99's and C11's work on multithreading and lack-of-aliasing.
> http://www.modernescpp.com/index.php/multithreading-in-c-17-and-c-20
>
> Your point would be well taken if you were to shift to stability. Ada pays especial attention to making sure that everything works together, whereas C++ plays the "undefined behavior" card too often, especially regarding multithreading interacting with other language features, most especially multithreading interacting with other undefined-behavior-swiss-cheese language features. C++ having a language feature and C++ having a language feature that isn't like stepping gingerly through a land-mine field are 2 entirely different things.
>
> > >> * Discriminants
> > >> * Elaboration
> >
> > Oh I forgot that doctors and stir sections are equivalent to Ada’s
> > elaboration. Those sections just call the constructors and destructors.m,
> > it’s very primitive. You also can’t do complex initialisations in C++ like
> > in Ada.
>
> I did amend Jeffrey Carter's claim that Ada has a quite deluxe elaboration feature-set that very few if any other languages attempt to provide. Perhaps you intended this reply to be inserted after some other topic instead.

I did *not* amend Jeffrey Carter's claim that Ada has a quite deluxe elaboration feature-set ...

[Dan'l Miller]

On Wednesday, June 20, 2018 at 2:37:31 PM UTC-5, Dan'l Miller wrote:

> ISO14488 standard C++

ISO14882 standard C++

[Luke A. Guest]

Dan'l Miller <> wrote:

>> Oh I forgot that doctors and stir sections

Fucking autocorrect!!!!!! 🤩

[Marius Amado-Alves]

The stated opposites to Ada were C and Pascal, not C++. I suspect a C++ compiler is as hard to make as an Ada one. Or even harder, because of the much higher grade of kludginess.

[Dan'l Miller]

On Thursday, June 21, 2018 at 5:44:41 AM UTC-5, Marius Amado-Alves wrote:
> The stated opposites to Ada were C and Pascal, not C++. I suspect a C++ compiler is as hard to make as an
> Ada one. Or even harder, because of the much higher grade of kludginess.

I am pretty sure that the OP was saying by implication Pascal-family or C-family compiler. (And I would categorize Java, J++, and C# as all C-esque in syntax, but decisively outside the C family philosophically & semantically.) Has any new (not-coursework) commercial or FOSS C-proper compiler been written from scratch since, say, 1993 onward? Not to my knowledge.

The only commercial or FOSS C-family compiler to be written from scratch since, say, 1993 (a quarter-century ago!) was Clang, in recent years no less. Clang is first & foremost a C++ compiler written in C++ source code, whereas its C and Objective-C support are after-thought alternative modes of operation for Clang. Clang isn't just any old C++ compiler; Clang is the premier C++ compiler (other than perhaps Edison Design Group, whose C++/C compiler shows up mainly in embedded world) that tries to achieve full compliance with any forthcoming C++ standards work. Clang even goes so far as to design, implement, and release the majority of •proposed• C++-standardization working papers as much as years prior to the release of, say, C++20, so that ‘existing industry practice’ is achieved right about now as tantamount-to-required by ISO14882 process prior to, say, C++20's official release. Even better if GCC implements that proposal as well for comparison by the committee.

http://en.cppReference.com/w/cpp/compiler_support
The only major (at least historically major) C++ compiler missing from this table is Watcom, now OpenWatcom 2.0 nowadays. Does there even exist a major (either commercial or FOSS) well-maintained-all-the-way-to-C11 •C-only• compiler anymore that is not also a C++ complier?

So rather than discuss via sophistry some •hypothetical-since-say-1993• C-proper compiler written from scratch, I figured OP would rather empirically discuss an ••actually extant•• C-family compiler that was in fact written from scratch in recent years.

[Jacob Sparre Andersen]

But you would still have to document what it implements. The Ada
community seems to be slightly more critical consumers, when it comes to
compiler quality.

Greetings,

Jacob
--
Beware of people with Gnus, they may Hurd you.

[Lucretia]

On Thursday, 21 June 2018 15:02:18 UTC+1, Jacob Sparre Andersen wrote:

> But you would still have to document what it implements. The Ada
> community seems to be slightly more critical consumers, when it comes to
> compiler quality.

I didn't say you wouldn't have to, you were implying you cannot call a compiler an Ada compiler if it doesn't support the whole language, which is no longer true, that was what I was pointing out.

[Pascal Obry]

Freezing rules come to mind.

--
Pascal Obry / Magny Les Hameaux (78)

The best way to travel is by means of imagination

http://www.obry.net

gpg --keyserver keys.gnupg.net --recv-key F949BD3B

[Dan'l Miller]

On Thursday, June 21, 2018 at 12:42:44 PM UTC-5, Pascal Obry wrote:
> Freezing rules come to mind.

C++ has an analogous compiler-writing difficulty: entities may be utilized in bodies of member functions prior to being declared later on in the same class declaration. This requires effective postponement of compilation of member-function bodies until after the closing } of the class.

That said, Ada's freezing rules seem to be less uniform that C++'s, and thus more complex by some measure. (It is remotely imaginable that Ada in some alternate universe could have had one simple freezing rule: keep all the clay soft until the absolutely very last token (i.e., the semicolon) of the private part of the package declaration, and then freeze only there at the •closing/terminating end• of the private section of the package declaration.)

Pascal, what makes freezing rules difficult when writing Ada compilers?
1) Is it that the freezing occurs later than what the compiler writer would find convenient, forcing the compiler writer to keep clay soft when it already seems to be in the kiln?
2) Is it that freezing occurs prematurely, requiring the compiler writer to expend effort enforcing the freezing too early for no good reason?
3) Is it that freezing rules are non-uniform/arbitrary/capricious across language constructs?
4) Something else?
5) All of the above?

[Paul Rubin]

"Dan'l Miller" <opt...@verizon.net> writes:
> Does there even exist a major (either commercial or FOSS)
> well-maintained-all-the-way-to-C11 •C-only• compiler anymore that is
> not also a C++ complier?

I don't know what counts as "major" and I'm not sure if the entirety of
C11 is present, but I use SDCC sometimes (sdcc.sourceforge.net) and it
supports at least some of C11. It has a substantial user base in the
embedded dev community.

[Dan'l Miller]

On Thursday, June 21, 2018 at 4:08:48 PM UTC-5, Paul Rubin wrote:

Yeah, I suppose that SDCC would count, and it was likely started after 1993. (I picked 1993 only because that is the year that Ada/Ed-interpreter development switched over to GNAT-compiler development at NYU, assuming that GNAT was 100% from scratch without borrowing any prior 1980s-era Ada/Ed code.)

Now that I think of it, there likely have been some closed-source C-proper compilers for DSPs and NPs that were written from scratch since 1993 too. But the moral of the story remains the same: microcontrollers and DSPs and NPs are all severely resource-constrained to the point of making any Ada or C++ or Java support impractical therein. Certainly the OP was not focusing on the difficulty of force-fitting Ada into microcontroller, DSP, or NP development.

[Simon Wright]

"Dan'l Miller" <opt...@verizon.net> writes:

> microcontrollers and DSPs and NPs are all severely
> resource-constrained to the point of making any Ada or C++ or Java
> support impractical therein

Not true (for MCUs, Ada & C++ anyway).

[Dan'l Miller]

On Thursday, June 21, 2018 at 5:01:19 PM UTC-5, Simon Wright wrote:

> "Dan'l Miller" writes:
>
> > microcontrollers and DSPs and NPs are all severely
> > resource-constrained to the point of making any Ada or C++ or Java
> > support impractical therein
>
> Not true (for MCUs, Ada & C++ anyway).

My reply and Paul Rubin's reply were both in the context of the 8-bit microcontrollers supported by sdcc. Which Ada complier(s) support any of sdcc's following 8-bit microcontrollers (many of which are vintage 1970s-era 8-bit ISAs)?
1) Intel's MSC51 (8031, 8032, 8051, 8052), [even wimpier ISA than an 8080/Z80, 64KiB DRAM]
2) Freescale HC08, S08 [derived from the 6808 as utilized in the Radio Shack Color Computer, 64KiB DRAM]
3) Zilog's Z80 [as utilized in the Sinclair ZX80, 64KiB DRAM]
4) STMicro's STM8 [which is arguably a 16-bit processor with 32-bit DRAM addressing and 24-bit program counter, not even remotely in the same class as resource-constrained 8-bit microcontrollers]

And the Atmel AVR RISC-processor (!) "microcontroller" doesn't count because it isn't limited to 64 KiB DRAM and single-digit or tens of megahertz like those listed above in SDCC's repertoire. Does anyone actually use GNAT to target tinyAVR, which is the only one of the AVR line that is comparable to the MCS51, HC08, and Z80 listed above in SDCC's repertoire.

[Dan'l Miller]

On Thursday, June 21, 2018 at 6:04:44 PM UTC-5, Dan'l Miller wrote:
> 2) Freescale HC08, S08 [derived from the 6808 as utilized in the Radio Shack Color Computer, 64KiB
> DRAM]

6809

[Paul Rubin]

"Dan'l Miller" <opt...@verizon.net> writes:

> microcontrollers and DSPs and NPs are all severely
> resource-constrained to the point of making any Ada or C++ or Java
> support impractical therein.

All of the above run fine on microcontrollers, though each has features
that you'd want to avoid using under severe enough constraints.

C itself is retro these days which is probably why there aren't
"serious" new compilers for it being written.
http://recc.robertelder.org/ is fairly recent but it's a hobby project
and it's c89.

But, I think lots of C users don't care much about C11. I haven't
checked but it wouldn't surprise me if most or all of the commercial
embedded compilers donn't support it.

[Paul Rubin]

"Dan'l Miller" <opt...@verizon.net> writes:

>> > resource-constrained to the point of making any Ada or C++ or Java

>> > support impractical therein...

> Which Ada complier(s) support any
> of sdcc's following 8-bit microcontrollers (many of which are vintage

> 1970s-era 8-bit ISAs)? 1) Intel's MSC51 (8031, 8032, 8051, 8052), ...

That nobody bothered to develop such a compiler doesn't mean it's
impractical to do so.

GCC targets the AVR and people use it all the time to compile C and C++
for the Arduino (that might be why SDCC doesn't bother with an AVR
target). Regarding GNAT for the AVR, I think some work was done toward
it but I don't know if it got any traction.

The usual AVR configuration has much less than 64k of ram. E.g. the
ATMega328 (probably the most popular arduino processor) has 32k of flash
and 2k of ram. Even the humonbous(?) ATMega2560 has 256k of flash and
8k of ram. They are generally picked for their electrical and i/o
characteristics but otherwise are getting squeezed out by small ARM parts.

[Paul Rubin]

"Dan'l Miller" <opt...@verizon.net> writes:

> Which Ada complier(s) support any of... Zilog's Z80

http://www.z80.eu/ADA.html mentions a few. Found in 2 sec by typing
"z80 ada" into web search. You could try the same with the other cpus
you mentioned. I'm guessing it's Ada-83 or some subset, but that's a
start.

[J-P. Rosen]

Le 21/06/2018 à 22:18, Dan'l Miller a écrit :
> Pascal, what makes freezing rules difficult when writing Ada compilers?
> 1) Is it that the freezing occurs later than what the compiler writer
> would find convenient, forcing the compiler writer to keep clay soft
> when it already seems to be in the kiln?> 2) Is it that freezing occurs prematurely, requiring the compiler
> writer to expend effort enforcing the freezing too early for no good
> reason?> 3) Is it that freezing rules are non-uniform/arbitrary/capricious
> across language constructs?> 4) Something else?
> 5) All of the above?

I'm not Pascal ;-), but I'll answer these...
Please do not assume that language designers are masochists that make
the language unnecessarily complicated for no good reason. There are
good reasons, and these can usually be found in the annotated reference
manual.

For example, if freezing happened at the end of a package (as you
suggest), it would not be possible to declare a variable or a constant
in the same package as its type (the type has to be frozen - i.e. its
representation determined - for an object to be declared). Therefore,
the declaration of an object freezes the type. Then, when you freeze a
type, of course you have to freeze all types of subcomponents. etc...
You end up with 13.14.

You may argue that the way 13.14 is written is not very... pedagogical.
True, but this is really for compiler writers, therefore rigor of
definition is more important than clarity of the statement. The casual
user just needs to rely on the compiler's message telling that some
clause happens too late.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Dmitry A. Kazakov]

It is simpler to argue that, evidently:

1. there must be a freezing point
2 there is no reason to have it any earlier than absolutely necessary

The result is the rules as they stated.

To have another outcome one have to change the structure of compilation
units or invent some advanced forward/partial declarations.

P.S. The real trouble with freezing will first come with full multiple
dispatch.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Dan'l Miller]

On Friday, June 22, 2018 at 12:01:37 AM UTC-5, J-P. Rosen wrote:
> Le 21/06/2018 à 22:18, Dan'l Miller a écrit :
> > Pascal, what makes freezing rules difficult when writing Ada compilers?
> > 1) Is it that the freezing occurs later than what the compiler writer
> > would find convenient, forcing the compiler writer to keep clay soft
> > when it already seems to be in the kiln?> 2) Is it that freezing occurs prematurely, requiring the compiler
> > writer to expend effort enforcing the freezing too early for no good
> > reason?> 3) Is it that freezing rules are non-uniform/arbitrary/capricious
> > across language constructs?> 4) Something else?
> > 5) All of the above?
>
> I'm not Pascal ;-), but I'll answer these...
> Please do not assume that language designers are masochists that make
> the language unnecessarily complicated for no good reason. There are
> good reasons, and these can usually be found in the annotated reference
> manual.

I was merely trying to enumerate all the logically possible ways that freezing rules could make it harder on the compiler writer to which Pascal was referring. Pascal is implying some sort of pain there. I am trying to understand that pain more precisely than a terse “why?” would evoke.

> For example, if freezing happened at the end of a package (as you
> suggest), it would not be possible to declare a variable or a constant
> in the same package as its type (the type has to be frozen - i.e. its
> representation determined - for an object to be declared). Therefore,
> the declaration of an object freezes the type. Then, when you freeze a
> type, of course you have to freeze all types of subcomponents. etc...
> You end up with 13.14.

Well, in an alternate universe, there would be a way to accomplish those declarations of constants or variables in the same package as their subtypes. In the alternate-universe Ada, Ada would have borrowed (on steroids in spades) the C++ idea of postponement/deferral of settling those affairs until the closing semicolon at the terminating end of the private section of the package. A dependency graph would have naturally arisen among the various not-yet-frozen declarations. If the dependency graph lacks a cycle of •conflicting• semantic requests among the declarations, then simply walk the dependency graph at the time of this later freezing, settling all requested affairs during postponement/deferral roughly analogous to the way C++ later compiles member-function bodies during its class-closing-} postponement/deferral.

(I am not saying that that postponement/deferral would certainly be easier for compiler writers than the existing freezing rules that Pascal is considering a challenge for Ada compiler writers; I am merely exploring what pain Pascal could have referring to. Also, I am well aware that Ada83's predecessor of freezing rules predate C++'s postponement/deferral of compiling member-function bodies that appear in the class declaration by somewhere on towards a decade, so Ada83 would have needed a time machine to borrow a page from C++'s book there. That is why this all occurred in the alternate universe, where perhaps alternate universe's Ada9X program would have had a requirement to lovingly embrace C++'s postponement/deferral as part & parcel of Ada9X's retort to the rise of C++, where alternate-universe's Ada9X AJPO requirements would have overtly rejected Ada83's precursor of freezing rules instead of our timeline's AJPO's tacit permission to expand them.)

Conversely, to OP's question: C++ (as the modern C replacement) freezes all types at the point of nonforward declaration, without any later adjustments to size or layout. That is simpler than Ada's let-it-float-for-just-awhile freezing rules.

[Dmitry A. Kazakov]

It is not a good idea IMO, regardless freezing rules. Ada's approach is
"asymmetric", i.e. forward declarations or limited with declare certain
aspects of the type or object limiting its use before full declaration.

An example why C++'s "symmetric" approach is not that good is this:

type A is record
Inner : B;
end record;

type B is record
Inner : A;
end record;

I bet outlining the rules necessary to handle such cases would take much
longer than current freezing rules. And understanding them would be
beyond normal programmer.

[Dan'l Miller]

1) This red herring is not permitted in the analogous C++ syntax (because neither A nor B is a postponed-/deferred-compilation ••body of member-function••). Even if you were to forward declare B, that does not rectify the lack of body of member-function whose compilation gets deferred/postponed.

2) This red herring would not be permitted in the alternate-universe Ada (with freezing at the ; of the not-shown terminating end of the package) due to having the overtly prohibited •cycle• of •conflicting• semantic requests (i.e., 2 infinite-length record).

[Alejandro R. Mosteo]

On 20/06/2018 00:34, Dan'l Miller wrote:
> On Tuesday, June 19, 2018 at 4:33:38 PM UTC-5, Vincent wrote:
>> Dear Ada programers,

>>
>> 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 ?
>>

>> Regards,
>>
>> Vincent
>
> The ARG mailing list (and extracts thereof, as appearing as appendix to each AI) is filled with descriptions of how over-the-top difficult some proposal is until the complexity of the proposal is whittled down. That is the forum where the luminaries & experts of Ada-world come together to discuss that complexity-of-the-compiler topic, as represented by each Ada compiler vendor.
>
> Also, there is this ominous house-of-cards complexity warning in C++world from the progenitor of C++ himself:
>
> https://www.TheRegister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus

That's an interesting read, thanks.

[Lucretia]

On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:

> * A section of the Ada _LRM_ standard commonly called the "heart of darkness" which supposedly only a handful of people on the planet grok

Which section is this in the manual? It should be titled that :)

[Dmitry A. Kazakov]

Well, any language rule can be formulated as "no red herring permitted".
However determining the color of a particular herring could be tricky.

[anti...@math.uni.wroc.pl]

Dan'l Miller <opt...@verizon.net> wrote:
> On Thursday, June 21, 2018 at 5:44:41 AM UTC-5, Marius Amado-Alves wrote:
> > The stated opposites to Ada were C and Pascal, not C++. I suspect a C++ compiler is as hard to make as an
> > Ada one. Or even harder, because of the much higher grade of kludginess.
>
> I am pretty sure that the OP was saying by implication Pascal-family or C-family compiler. (And I would categorize Java, J++, and C# as all C-esque in syntax, but decisively outside the C family philosophically & semantically.) Has any new (not-coursework) commercial or FOSS C-proper compiler been written from scratch since, say, 1993 onward? Not to my knowledge.
>

Hmm, Tiny C and SDCC


--
Waldek Hebisch

[Simon Clubley]

3.10.2 (according to Randy)

Personally, I don't think it's something to be proud of however.

When a language is used in the critical environments that Ada is used in,
it shouldn't have anything in it which is that difficult to understand.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Lucretia]

On Friday, 22 June 2018 18:10:35 UTC+1, Simon Clubley wrote:

> On 2018-06-22, Lucretia <> wrote:
> > On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:
> >
> >> * A section of the Ada _LRM_ standard commonly called the "heart of darkness" which supposedly only a handful of people on the planet grok
> >
> > Which section is this in the manual? It should be titled that :)
>
> 3.10.2 (according to Randy)

Thanks, but I found it in the index, it's actually labelled as that ;)

> Personally, I don't think it's something to be proud of however.

Well no.

> When a language is used in the critical environments that Ada is used in,
> it shouldn't have anything in it which is that difficult to understand.

Yes, but Ada is a complex language.

[Dan'l Miller]

Writing a compiler in OP refers to both writing it from scratch as well as maintenance over the years. All of the Ada compilers listed on that antiquated page are in various stages of broken links, out of business, and no longer supporting Z80 in recent •decades•.

After performing a fair amount of searching on both Bing and Google, I could not find any Ada compiler targeting Z80 other than ancient archives of CP/M-era Ada compilers from the 1980s for ancient OSes. The only hope for a still-in-operation vendor of a still-maintained-for-a-fee Ada compiler for Z80 would be RR Software's old Janus Ada for CP/M. Apparently, it is either technically difficult and/or financially cost-prohibitive to support Ada for resource-constrained* targets in the 8080/Z80, 6809, and 6502 families, which have been repurposed as 8-bit microcontrollers (notwithstanding AVR's novel usage of “8-bit microcontroller” to refer to a modern RISC processor that has 32 registers many of which are 16-, 24-, or 32-bit in size)

* e.g., 64 KiB DRAM address space; clock rate of single-digit or tens of megahertz

Various ports of GCC to Z80 exist, but they seem to focus exclusively on C-proper, instead of on C++ or Ada.

[Luke A. Guest]

Dan'l Miller <> wrote:

> Writing a compiler in OP refers to both

OP???

> writing it from scratch as well as maintenance over the years. All of
> the Ada compilers listed on that antiquated page are in various stages of
> broken links, out of business, and no longer supporting Z80 in recent •decades•.
>

Well, the Z80 is no longer supported, you can at least still buy them. I
have one sitting in my desk ready to be put into a retroputer.

> * e.g., 64 KiB DRAM address space; clock rate of single-digit or tens of megahertz
>
> Various ports of GCC to Z80 exist, but they seem to focus exclusively on
> C-proper, instead of on C++ or Ada.
>

The ports are in various states of broken-ness as well. None are up to
date, all are partially done. Believe me I’ve looked.

Luke

[Dan'l Miller]

On Friday, June 22, 2018 at 6:15:45 PM UTC-5, Luke A. Guest wrote:
> Dan'l Miller <> wrote:
>
> > Writing a compiler in OP refers to both
>
> OP???

the original posting of this thread; the original poster's posting that started this thread

> > writing it from scratch as well as maintenance over the years. All of
> > the Ada compilers listed on that antiquated page are in various stages of
> > broken links, out of business, and no longer supporting Z80 in recent •decades•.
> >
>
> Well, the Z80 is no longer supported, you can at least still buy them. I
> have one sitting in my desk ready to be put into a retroputer.

Which is a little ironic that antiquated hot slow limited-RAM power-slurping hardware at the heart of the CP/M era and the Timex/Sinclair era outlived the Ada-compiler software of the same era. Who would've predicted that? Thus demonstrating once again: bit-rot in software is real.

Speaking of retrocomputers, there was a point many years ago at which Zilog notified its customers of the Z8000 (the 16-bit version of the Z80) of the last-time buy manufacturing run. I once worked for the telecom company that was one of those Z8000 customers who received that last-time-buy notice. They sent a quite official response, in person to Zilog's C-level executives, I think: hey Zilog, speaking of last-time-buy for the Z8000, we assume that this is the last-time-buy for the masks too. We'd like to buy the Z8000 masks & all related fab data to manufacture Z8000s ourselves henceforth.

… And that is how the Air Force started buying Z8000s during the 1990s from that telecom equipment manufacturer instead of from Zilog.

> > * e.g., 64 KiB DRAM address space; clock rate of single-digit or tens of megahertz
> >
> > Various ports of GCC to Z80 exist, but they seem to focus exclusively on
> > C-proper, instead of on C++ or Ada.
> >
>
> The ports are in various states of broken-ness as well. None are up to
> date, all are partially done. Believe me I’ve looked.

I can understand phasing Alpha and VAX and National Semiconductor 32032 ISAs out of modern GCC because each is no longer manufactured, but I think that every compiler should support every processor on the planet that is manufactured •today•.

[Luke A. Guest]

Dan'l Miller <opt...@verizon.net> wrote:

>> The ports are in various states of broken-ness as well. None are up to
>> date, all are partially done. Believe me I’ve looked.
>
> I can understand phasing Alpha and VAX and National Semiconductor 32032
> ISAs out of modern GCC because each is no longer manufactured, but I
> think that every compiler should support every processor on the planet
> that is manufactured •today•.
>

But Z80 was never officially ported to GCC, there have been attempts which
seemed to die because of the severe lack of registers, iirc. Also Z80
doesn’t have zero page tricks like the 6502.

I’ve read that the current LRA (I think it’s called) register scheduler
would be better for these kinds of CPU’s.

[Dan'l Miller]

On Friday, June 22, 2018 at 8:49:37 PM UTC-5, Luke A. Guest wrote:

> Dan'l Miller wrote:
>
> >> The ports are in various states of broken-ness as well. None are up to
> >> date, all are partially done. Believe me I’ve looked.
> >
> > I can understand phasing Alpha and VAX and National Semiconductor 32032
> > ISAs out of modern GCC because each is no longer manufactured, but I
> > think that every compiler should support every processor on the planet
> > that is manufactured •today•.
> >
>
> But Z80 was never officially ported to GCC, there have been attempts which
> seemed to die because of the severe lack of registers, iirc. Also Z80
> doesn’t have zero page tricks like the 6502.

Yes, but the Z80 has the 8080's three 16-bit registers BC, DE, and HL by concatenating 8-bit register pairs, but the Z80 has three more shadow 16-bit registers BC', DE', and HL' that can be swapped in and out. (Plus AF and AF' if you like living dangerously with the flag registers.) 6502 needed the page-zero trick because its register-set was so spartan. (Only TI's TMS9900 had an even more spartan register-set in that era.)

> I’ve read that the current LRA (I think it’s called) register scheduler
> would be better for these kinds of CPU’s.

It would appear so. What came before LRA looks like big-ball-of-mud architecture whose concrete set hard & brittle long long ago.

[J-P. Rosen]

Le 22/06/2018 à 18:10, Simon Clubley a écrit :
> 3.10.2 (according to Randy)
>
> Personally, I don't think it's something to be proud of however.
>
> When a language is used in the critical environments that Ada is used in,
> it shouldn't have anything in it which is that difficult to understand.

Well, it is an attempt at making pointers safer, and this is inherently
difficult. Other languages didn't even try...

[Dan'l Miller]

On Saturday, June 23, 2018 at 12:56:43 AM UTC-5, J-P. Rosen wrote:
> Le 22/06/2018 à 18:10, Simon Clubley a écrit :
> > 3.10.2 (according to Randy)
> >
> > Personally, I don't think it's something to be proud of however.
> >
> > When a language is used in the critical environments that Ada is used in,
> > it shouldn't have anything in it which is that difficult to understand.
>
> Well, it is an attempt at making pointers safer, and this is inherently
> difficult. Other languages didn't even try...

Except Rust nowadays, and hopefully Ada2020 will catch up

[Shark8]

SPARK is better than Rust in terms of safety/reliability; there was a [possible] proposed extension to SPARK to allow access-types in certain, controlled conditions that was shown to the ARG. (They asked that we not promulgate it, I think because they wanted to publish/present it for their academic career.)

[Dan'l Miller]

Don't say any more. It might have been embargoed for a patent application not yet submitted.

[Shark8]

I wasn't going to; just saying that there are efforts to bring safe, provable access-types into SPARK. (And, actually, I'm certain there's several publicly available papers on the general topic; I've come across a few... probably here: http://spark-2014.org/ )

[Simon Wright]

https://arxiv.org/abs/1805.05576 (was posted on reddit/r/ada)

[Jacob Sparre Andersen]

"Dan'l Miller" <opt...@verizon.net> writes:

The problem with Rust is that the language isn't well specified (a
"reference implementation" doesn't count as a specification).

At Ada-Europe 2018, Maroua Maalej presented a paper with the title "Safe
Dynamic Memory Management in Ada and SPARK". It explains how you can
implement borrowing access types in Ada quite trivially (I had figured
out the basics myself beforehand). The challenge is that borrowing
access types are behaviorally incompatible with existing Ada access
types, so you have to select the behaviour per access type. - And this
still doesn't solve all the problems related to anonymous access types
(i.e. "the heart of darkness").

Greetings,

Jacob
--
"Logic, my dear, merely enables one to be wrong with authority!"

[Paul Rubin]

Lucretia <lague...@googlemail.com> writes:
>> Ada might be harder to compile than C or Pascal, but not by *that* much
> You are living in a dream world [if] you think that.

You are right, looking into this a little further, the amount of stuff
in Ada is enormous compared to C or Pascal, much larger than Ada
Distilled makes it sound. It's not possible to write a minimalistic Ada
compiler comparable in size to some of the small C or Pascal compilers
that have been written. Compared to an industrial-strength C compiler
though, it's still not that big an increment: i.e. GNAT was not that
large an addition to GCC.

It's also not clear to me that Ada has actual difficult-to-compile
features (maybe it does, and I just haven't spotted them) as opposed to
a very large number of straightforward ones. By comparison, lots of the
stuff in GHC resulted from academic research projects that represented
new advances in the state of PLT knowledge.

[Lucretia]

On Sunday, 24 June 2018 18:33:22 UTC+1, Paul Rubin wrote:

> Distilled makes it sound. It's not possible to write a minimalistic Ada
> compiler comparable in size to some of the small C or Pascal compilers
> that have been written. Compared to an industrial-strength C compiler

It's possible, by using a subset (pragma's restrictions/profiles), but you'd still need basic packages, basic generics, integral/enum types and subprograms.

> It's also not clear to me that Ada has actual difficult-to-compile
> features (maybe it does, and I just haven't spotted them) as opposed to
> a very large number of straightforward ones. By comparison, lots of the
> stuff in GHC resulted from academic research projects that represented
> new advances in the state of PLT knowledge.

I think it's more that once you have a parser, it's all the semantic stuff that has to go over the AST to sort out what's what.

[Simon Clubley]

On 2018-06-22, Lucretia <lague...@googlemail.com> wrote:

> On Friday, 22 June 2018 18:10:35 UTC+1, Simon Clubley wrote:
>> On 2018-06-22, Lucretia <> wrote:
>> > On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:
>> >
>> >> * A section of the Ada _LRM_ standard commonly called the "heart of darkness" which supposedly only a handful of people on the planet grok
>> >
>> > Which section is this in the manual? It should be titled that :)
>>
>> 3.10.2 (according to Randy)
>
> Thanks, but I found it in the index, it's actually labelled as that ;)
>

Is that the AARM ?

It's not in the Ada 95 paper LRM I have or a PDF copy of the Ada 2012 LRM.

[Simon Clubley]

On 2018-06-23, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> On Fri, 22 Jun 2018 18:03:28 -0700 (PDT), "Dan'l Miller"
><opt...@verizon.net> declaimed the following:
>
>>
>>I can understand phasing Alpha and VAX and National Semiconductor 32032 ISAs out of modern GCC because each is no longer manufactured, but I think that every compiler should support every processor on the planet that is manufactured ?today?.
>
> Yet there are a lot of installations running OpenVMS (Alpha and/or VAX
> variants) via virtual machines, because it is easier to certify that the VM
> emulation is producing identical binaries as the original hardware, than it
> is to certify the software that would be built by porting from the VMS
> build-tools to native (cross-) development {the case I have experience with
> is an emulated VAX/VMS running a cross-compiler for 68040}.
>

Yes, I was going to say that Alpha systems are still in active use
(VSI now have support contracts for Alpha VMS users) and recent
security research work revealed that there still appear to be a
number of VAX users as well.

[Simon Clubley]

On 2018-06-24, Jacob Sparre Andersen <ja...@jacob-sparre.dk> wrote:
> "Dan'l Miller" <opt...@verizon.net> writes:
>> On Saturday, June 23, 2018 at 12:56:43 AM UTC-5, J-P. Rosen wrote:
>
>>> Well, it is an attempt at making pointers safer, and this is
>>> inherently difficult. Other languages didn't even try...
>>
>> Except Rust nowadays, and hopefully Ada2020 will catch up
>
> The problem with Rust is that the language isn't well specified (a
> "reference implementation" doesn't count as a specification).
>

Especially when that reference implementation keeps changing...

> At Ada-Europe 2018, Maroua Maalej presented a paper with the title "Safe
> Dynamic Memory Management in Ada and SPARK". It explains how you can
> implement borrowing access types in Ada quite trivially (I had figured
> out the basics myself beforehand). The challenge is that borrowing
> access types are behaviorally incompatible with existing Ada access
> types, so you have to select the behaviour per access type. - And this
> still doesn't solve all the problems related to anonymous access types
> (i.e. "the heart of darkness").
>

Are anonymous access types a mistake ?

Removing them increases the level of required formality in code but
you can argue either way whether this is a bad thing or not.

[Jacob Sparre Andersen]

Simon Clubley wrote:

> Are anonymous access types a mistake?

I suspect it. But even if we could come up with a solution to the
challenges related to implementing containers with as readable usage as
what we have to day, it would be a - hugely untraditional - major break
of backwards compatibility to remove them from the language again.

> Removing them increases the level of required formality in code but
> you can argue either way whether this is a bad thing or not.

It is my experience that the current containers, with "for ... of" loops
and variable access to container elements make for much more readable
source text.

My problem is that giving us that bit of readability also has allowed
API developers to use anonymous access types in all other kinds of
places - mostly in places where traditional, named access types would
work perfectly well, and not impose a severe run-time (and compiler
complexity) cost.

Greetings,

Jacob
--
»It will not be forever. - It will just seem like it.« -- Death

[Alejandro R. Mosteo]

On 25/06/2018 07:48, Simon Clubley wrote:
> On 2018-06-22, Lucretia <lague...@googlemail.com> wrote:
>> On Friday, 22 June 2018 18:10:35 UTC+1, Simon Clubley wrote:
>>> On 2018-06-22, Lucretia <> wrote:
>>>> On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:
>>>>
>>>>> * A section of the Ada _LRM_ standard commonly called the "heart of darkness" which supposedly only a handful of people on the planet grok
>>>>
>>>> Which section is this in the manual? It should be titled that :)
>>>
>>> 3.10.2 (according to Randy)
>>
>> Thanks, but I found it in the index, it's actually labelled as that ;)
>>
>
> Is that the AARM ?

Yes:

"3.b/3 Subclause 3.10.2, home of the accessibility rules, is informally
known as the “Heart of Darkness” amongst the maintainers of Ada. Woe unto
all who enter here (well, at least unto anyone that needs to understand
any of these rules)."

[Alejandro R. Mosteo]

It was just presented in Ada-Europe 2018, and they said that it was
inspired by Rust borrowing rules.

What I find interesting about the Rust approach is that (perhaps by their
C-fixing motivation) it addresses something that is not tackled by Ada
attempts, so I find it curiously orthogonal. So having something similar
in SPARK seems only logical.

[Lucretia]

On Monday, 25 June 2018 06:48:57 UTC+1, Simon Clubley wrote:

> > Thanks, but I found it in the index, it's actually labelled as that ;)
> >
>
> Is that the AARM ?
>
> It's not in the Ada 95 paper LRM I have or a PDF copy of the Ada 2012 LRM.

http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-0-5.html

"accessibility rules
See also Heart of Darkness 3.10.2(3.b/3)"

[Lucretia]

On Sunday, 24 June 2018 14:41:14 UTC+1, Jacob Sparre Andersen wrote:

> The problem with Rust is that the language isn't well specified (a
> "reference implementation" doesn't count as a specification).
>
> At Ada-Europe 2018, Maroua Maalej presented a paper with the title "Safe
> Dynamic Memory Management in Ada and SPARK". It explains how you can

Shame this is unobtainium.

[Dan'l Miller]

On Monday, June 25, 2018 at 12:48:57 AM UTC-5, Simon Clubley wrote:
> On 2018-06-22, Lucretia wrote:
> > On Friday, 22 June 2018 18:10:35 UTC+1, Simon Clubley wrote:
> >> On 2018-06-22, Lucretia <> wrote:
> >> > On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:
> >> >
> >> >> * A section of the Ada _LRM_ standard commonly called the "heart of darkness" which supposedly only a handful of people on the planet grok
> >> >
> >> > Which section is this in the manual? It should be titled that :)
> >>
> >> 3.10.2 (according to Randy)
> >
> > Thanks, but I found it in the index, it's actually labelled as that ;)
> >
>
> Is that the AARM ?
>
> It's not in the Ada 95 paper LRM I have or a PDF copy of the Ada 2012 LRM.

Paper copy? From 1995? Well, here is the _AARM_ (the _Annotated Ada Reference Manual_) for Ada2012+TC1 (which could be called Ada2016)
http://www.ada-auth.org/standards/aarm12_w_tc1/AA-Final.pdf

For completeness, here where to get the _LRM_ for Ada2012+TC1 (Ada2016) as well:
http://www.ada-auth.org/arm.html

[Dan'l Miller]

On Tuesday, June 19, 2018 at 4:33:38 PM UTC-5, Vincent wrote:
> Dear Ada programers,
>
> 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 ?

The commit history alone of GNAT, Clang, and Flang is where empirical data (e.g., size of source code; intertwinedness of source code; burstiness of change; number of key mastermind contributors; defect rate) can be harvested for an academic paper that explores this topic, to see whether Ada is any more complicated or any larger at all than other modern quite-evolved programming languages: modern C++ and modern Fortran especially. Even deeper analytics could compare the open-source repositories to their corresponding language-standard documents to measure difficulty of implementing certain features.

I suspect that the answer is that all programming languages become the same enormous size and same complexity given enough decades of ISO standardization or design-by-committee analogue thereof. What differs is what each committee/community expended their energies & diligence & tenacity on.

Benevolent-dictators-for-life languages likely have far less sprawl over the decades, but likely fall into 2 size/complexity categories:

1) kiss-principle (keep it simple, stupid) languages that evolve relatively little over the period of decades (Yukihiro Matsumoto's Ruby seems to be an example of this category.)
versus
2) conquer-new-dominions languages that convulse every decade or so to reinvent themselves to do something entirely out-of-scope for their earlier eras/convulsions. (Larry Wall's Perl6 seems to be an example of this category.)

[Simon Clubley]

Thanks; I just use the normal LRM when writing Ada code.

Perhaps I should think about switching to the AARM...

[Simon Clubley]

On 2018-06-25, Dan'l Miller <opt...@verizon.net> wrote:
> On Monday, June 25, 2018 at 12:48:57 AM UTC-5, Simon Clubley wrote:
>>
>> It's not in the Ada 95 paper LRM I have or a PDF copy of the Ada 2012 LRM.
>
> Paper copy? From 1995? Well, here is the _AARM_ (the _Annotated Ada Reference Manual_) for Ada2012+TC1 (which could be called Ada2016)
> http://www.ada-auth.org/standards/aarm12_w_tc1/AA-Final.pdf
>

Yes. When I started getting interested in Ada, Ada 95 was the current
version and back in those days you used to have these things called
books which you stored in physical containers called "bookcases". :-)

More seriously however, my later Ada materials are all digital based.
Makes searching them a _lot_ easier. :-)

[Dirk Craeynest]

In article <0a01e940-ec24-40b2...@googlegroups.com>,

Paper:
https://link.springer.com/content/pdf/10.1007%2F978-3-319-92432-8_3.pdf

Presentation:
http://www.ada-europe.org/conference2018/presentations/Safe%20Dynamic%20Memory%20Management%20in%20Ada%20and%20SPARK.pdf

Dirk
Dirk.Cr...@cs.kuleuven.be (for Ada-Belgium/Ada-Europe/SIGAda/WG9)

*** Ada-Europe 24th Intl. Conf. on Reliable Software Technologies ***
June 10-14, 2019 * Warsaw, Poland * www.ada-europe.org/conference2019

[Olivier Henley]

> Ummmm, apparently you are stuck in 1992 or something. C++ ain't your father's Oldsmobile anymore, to paraphrase the old television commercials. Time marched onward in C++, as shown in the timeline at the URL below. Threads-of-execution, sequence points, thread-local storage, condition variables, multireader-uniwriter locks, threadsafe STL, atomic smart pointers, futures, latches & barriers, coroutines, transactional memory, task blocks (i.e., rendezvous), plus inheriting C99's and C11's work on multithreading and lack-of-aliasing.

Ummmm, apparently you are stuck in 2021 or something. C++ is your father's Oldsmobile that was selected for a 'Pimp My Ride' episode.

From http://clang.llvm.org/cxx_status.html

- transactional memory : No
- task blocks are not even mentioned (N4411)

From https://gcc.gnu.org/projects/cxx-status.html

- coroutines : No
- task blocks are not even mentioned (N4411)
what else ... not more time to loose on that.

Do you really want me to check for Visual Studio 15/17 support for the features you mentioned?

[Dan'l Miller]

C++ is the standardization effort's output specification-documents, especially those proposals which have been accepted or are clearly on-track to being accepted. C++ is not some lagging snapshot of some particular compiler release. If the undulating mass compiler feature-content is your definition of a programming language, then that programming language changes every day; job postings would need to call out specific release numbers of specific brands of compiler instead of merely saying Ada95 or Ada2012 or C++11 or C++17.

Btw, OpenWatcom is really lagging behind, but OpenWatcom is under active development. Do we say that C++ lacks a feature until OpenWatcom catches up? Likewise, do we say that Ada lacks a feature until every single one of its still-actively-maintained Ada compilers has the feature?

For example, clearly, C++98 is …

void LookMaNoHands()
try
{
; // Your code here.
}
catch( ... )
{
; // Your code here.
}

… even though no compiler on the planet ever implemented that standardized feature of elision of the function's outermost braces, replacing them with an outermost try-catch block. Under your flawed logic, C++98 doesn't exist due to all compilers on the planet lacking that one feature. And then as soon as one or all of them were to implement that old (now-deprecated) feature, poof suddenly out of the nebulous ether C++98 comes into existence ≥20 years later.

[Olivier Henley]

You literally bumped the previous comment over planned features. From now on, please save me of such technical diversions.

He is right, "you can’t compare Ada’s high level tasking to the thin veneer over threading that’s in C++".

The key here, FYI, is "that's in C++" as in --> common sense "usable" <--, not "to come in C++".

[Dan'l Miller]

Rust is close to surpassing Ada as the safe-systems language (unless Ada2020 adopts Rust-esque safe-pointers and safe-threading). Go thinks that it is too, but I cannot see any clear features of Go that substantiates Go's claim. C++ is close to surpassing Ada as the programming language with generous amounts of concurrency built •directly• into the language, not such rinkydink library wrappers as it was formerly. Wake up.

The acquire-release fences of the memory model alone in C++11 (7 years ago for those keeping count) is a major concurrency language feature that is far beyond mere “thin veneer over threading”. Extant in Clang 3.3 and onward. Extant in GCC 4.8 and onward. Ancient history nowadays, not vaporware as you claim.

blog posts from 2016, not from 2021 as you claim:
http://www.modernescpp.com/index.php/category/multithreading-memory-model

[Olivier Henley]

The federation of "who/when/where/how" of most C++ features is extremely schizophrenic compared to Ada high level tasking which is arguably mature, well documented (every books, not articles), clean and coherent within the rest of the language.

[Dan'l Miller]

Yes, I agree. That concurs with various recent postings that I am making over on the “Ada successor language” thread regarding how the landmine field in C++ occurs over time. Bjarne himself is starting to publicly state similar sentiments about C++ language features not being designed to work together and even language features in isolation being “half-baked” (his term) internally within their own proposal:

https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus

[Mehdi Saada]

Could all of you STOP talking about other language, please ? Or at least not in a way that require ACTUAL knowledge of these ?
State your points in Ada terms at least, or neutral computer science terms. So that maybe, outsiders could understand with more ease, what the heck you're talking about, especially when I have the intuition that what you're saying isn't so complicated in fact.

[Vincent]

Le lundi 25 juin 2018 22:07:16 UTC+2, Dirk Craeynest a écrit :
>
> >> At Ada-Europe 2018, Maroua Maalej presented a paper with the title "Safe
> >> Dynamic Memory Management in Ada and SPARK". It explains how you can
>
>

> Paper:
> https://link.springer.com/content/pdf/10.1007%2F978-3-319-92432-8_3.pdf

I am a little bit shocked by this proposal :

1. The "Owning Object Aspect" changes the semantics of Access types in Ada.
X := Y; would now mean that
- X'New = Y'Old
- Y'New = null

2. Shouldn't we create a new category of Owning Types instead of a new special case of access values ? And add a new operator like :
X <- Y;

3. In fact shouldn't this idea of owning object be instatiated in Ada as limited types ? Wasn't the purpose of limited types to precisely forbid assignement so as to avoid aliasing of dynamically allocated objects ? Like tasks types for instance, or protected types...

Regards,

Vincent

[Simon Wright]

Vincent <vincent....@gmail.com> writes:

> 1. The "Owning Object Aspect" changes the semantics of Access types in
> Ada.
> X := Y; would now mean that
> - X'New = Y'Old
> - Y'New = null

auto_ptr? (or unique_ptr, now)

[Luke A. Guest]

Vincent <> wrote:

> 2. Shouldn't we create a new category of Owning Types instead of a new
> special case of access values ? And add a new operator like :
> X <- Y;

Yes, plus it makes it visually distinct so you know it’s an owned type.

Type A is access owned T;

Makes sense.

> 3. In fact shouldn't this idea of owning object be instatiated in Ada as
> limited types ? Wasn't the purpose of limited types to precisely forbid
> assignement so as to avoid aliasing of dynamically allocated objects ?
> Like tasks types for instance, or protected types...

But you can still grab an access to a limited type.

[Dan'l Miller]

The OP of the “Why are Ada compilers difficult to write?” thread explicitly requests comparing Ada compilers to other languages' compilers at a reason-by-reason level. Perhaps this whole thread is not for you.

The OP of the “Ada successor language” thread explicitly requests considering what a next-generation Ada would look like. Part of this ngAda is insularly inward looking: what Ada-esque features have been requested in AIs but blocked for various reasons. But the bigger part of this ngAda is to outward looking: what nonAda features (from •other• languages; from theoretical work; from •nonAda• luminaries) might be good for ngAda to have. Since ngAda is not strictly Ada, perhaps that whole thread is not for you either.

And perhaps most importantly for Ada's continued existence: attempting to suppress all speech about how to import currently-nonAda concepts into Ada to improve Ada to survive through this period of serious competition and encroachment from other languages catching up or surpassing Ada (at least in those other languages' propaganda) is a direct threat to Ada's future existence, or at least its future relevance.

In general in the world, there are 2 systems regarding speech:
1) totalitarian suppression of certain categories of speech (e.g., speak only in historically Ada{83,95,2005,2012} terms), so that only the ‘approved’ speech remains
versus
2) the USA's first amendment's fostering of multiple voices speaking a diversity of thoughts so that at least some subset of the speech starts saying what needs to be heard, contemplated, and acted upon, so in turn that speech rises as the cream to the top, leaving bad speech as a precipitate that sinks to the bottom.

Nations that follow scheme #1 usually die out. Nations that follow scheme #2 tend to flourish. The same with communities regarding programming languages.

On Thursday, June 28, 2018 at 7:08:39 AM UTC-5, Vincent wrote:
> Le lundi 25 juin 2018 22:07:16 UTC+2, Dirk Craeynest a écrit :
> >
> > >> At Ada-Europe 2018, Maroua Maalej presented a paper with the title "Safe
> > >> Dynamic Memory Management in Ada and SPARK". It explains how you can
> >
> >
> > Paper:
> > https://link.springer.com/content/pdf/10.1007%2F978-3-319-92432-8_3.pdf
>
> I am a little bit shocked by this proposal :
>
> 1. The "Owning Object Aspect" changes the semantics of Access types in Ada.
> X := Y; would now mean that
> - X'New = Y'Old
> - Y'New = null

That would be a linear type system:

https://en.wikipedia.org/wiki/Substructural_type_system

There are some concerns that to accomplish its safety-critical goals, a few portions of Ada are set on the wrong foundations. (AJPO, HOLWG, and Ada9X were decades ago; their overseeing wisdom might be showing its staleness by now.) The competition from Rust's affine type system (including Rust's borrow checker) might be motivating the Ada community to consider more-formal embracing of the categories of type systems that arose since HOLWG and Jean Ichbiah's era of work during the 1970s. That Wikipedia article and its hyperlinks therein introduces 4: {linear, affine, relevant, ordered}.

> 2. Shouldn't we create a new category of Owning Types instead of a new special case of access values ? And add a new operator like :
> X <- Y;
>
> 3. In fact shouldn't this idea of owning object be instatiated in Ada as limited types ? Wasn't the purpose of limited types to precisely forbid assignement so as to avoid aliasing of dynamically allocated objects ? Like tasks types for instance, or protected types...

I agree that there should be some overt syntax for placing Ada in the linear-typing mode instead of its access's historical mode.

[J-P. Rosen]

Le 28/06/2018 à 14:08, Vincent a écrit :
> 1. The "Owning Object Aspect" changes the semantics of Access types in Ada.

Yes. This would be a different kind of pointer, safer but less powerful.
For example, it would not be possible to write a circular list with
them. So it is not intended to replace current access types, it would be
something different.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Dmitry A. Kazakov]

On 2018-06-28 16:43, J-P. Rosen wrote:
> Le 28/06/2018 à 14:08, Vincent a écrit :
>> 1. The "Owning Object Aspect" changes the semantics of Access types in Ada.
> Yes. This would be a different kind of pointer, safer but less powerful.
> For example, it would not be possible to write a circular list with
> them. So it is not intended to replace current access types, it would be
> something different.

I used this strategy in my implementation of linked lists, e.g. when an
element is inserted into a list then the original access type is set to
null.

I don't think this is a universal enough approach to deserve a special
class of types. Then, I don't know SPARK good enough, but I wonder why
it is not possible to simply contract subprograms like list insert to
leave a single access (maybe single circular access) to each list
element? It does not look difficult to prove.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Paul Rubin]

"Dan'l Miller" <opt...@verizon.net> writes:

> Rust is close to surpassing Ada as the safe-systems language (unless
> Ada2020 adopts Rust-esque safe-pointers and safe-threading). Go
> thinks that it is too, but I cannot see any clear features of Go that
> substantiates Go's claim.

I don't think Go is in the same space. It has a quite weak type system
and (for better or worse) is GC'd. If you want GC, weak types, and
concurrency, try Erlang. If you want GC, strong types, and concurrency,
try Haskell.

I liked this old comparison about Go: http://cowlark.com/2009-11-15-go/

[G. B.]

Dan'l Miller <opt...@verizon.net> wrote:

> C++ is close to surpassing Ada as the programming language with generous
> amounts of concurrency built •directly• into the language, not such
> rinkydink library wrappers as it was formerly. Wake up.
>

Also, cleverly the language seems to continue its tradition of playing into
the hands of programmers who enjoy building a multitasking solution rather
than using one.

[Dan'l Miller]

On Friday, June 29, 2018 at 11:36:07 AM UTC-5, G. B. wrote:

Very astute observation. Perhaps the Ada community can utilize this as a differentiator/path-to-victory in the forthcoming explanations'/articles'/books'/bake-off-competitions' battle of the minds for mindshare.

One of the weak links in the chain of C++'s forthcoming new era of concurrency in the language is how precisely it fits with each OS's differing existing practices. Programmers go through crawl, walk, run phases of utilizing new tech. At the ‘crawl’ level, C++'s new threads support and multireader-uniwriter locks are obviously mapped to POSIX equivalents. But on the other ‘walk’/‘run’ extreme, it is not clear at all how all of C++'s new concurrency-in-the-language features fully map onto, say, Apple's Grand Central Dispatch concurrency, if at all. I predict (as G.B. seems to, as well) that C++'s roll-your-own approach is going to get overwhelming for the average programmer to get entirely correct in anything other than the plain-vanilla cases at the ‘crawl’ stage.

[Randy Brukardt]

"Paul Rubin" <no.e...@nospam.invalid> wrote in message
news:87o9g38...@nightsong.com...

> "Dan'l Miller" <opt...@verizon.net> writes:

>>> > resource-constrained to the point of making any Ada or C++ or Java
>>> > support impractical therein...
>> Which Ada complier(s) support any
>> of sdcc's following 8-bit microcontrollers (many of which are vintage
>> 1970s-era 8-bit ISAs)? 1) Intel's MSC51 (8031, 8032, 8051, 8052), ...
>
> That nobody bothered to develop such a compiler doesn't mean it's
> impractical to do so.

We looked at doing so in the late 1980s; there didn't seem to be a technical
problem but it wasn't clear that we could find/sell to the customers
involved. In the end, we didn't do it.

Randy.

[Randy Brukardt]

There's no particular problem in supporting a Z80 cross-compiler, we just
haven't had anyone asking about it in decades. I'd be concerned about
getting the old runtime up to modern specifications, but otherwise I don't
think it would be too hard. (Not sure if I could find the source to the old
code cruncher, which doubled the amount of code one could run on that
processor.)

Randy.

"Dan'l Miller" <opt...@verizon.net> wrote in message
news:8e8e7ce9-d7ac-4ec5...@googlegroups.com...

On Thursday, June 21, 2018 at 10:44:21 PM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" <opt...@verizon.net> writes:

> > Which Ada complier(s) support any of... Zilog's Z80
>
> http://www.z80.eu/ADA.html mentions a few. Found in 2 sec by typing
> "z80 ada" into web search. You could try the same with the other cpus
> you mentioned. I'm guessing it's Ada-83 or some subset, but that's a
> start.

Writing a compiler in OP refers to both writing it from scratch as well as
maintenance over the years. All of the Ada compilers listed on that
antiquated page are in various stages of broken links, out of business, and
no longer supporting Z80 in recent .decades..

After performing a fair amount of searching on both Bing and Google, I could
not find any Ada compiler targeting Z80 other than ancient archives of
CP/M-era Ada compilers from the 1980s for ancient OSes. The only hope for a
still-in-operation vendor of a still-maintained-for-a-fee Ada compiler for
Z80 would be RR Software's old Janus Ada for CP/M. Apparently, it is either
technically difficult and/or financially cost-prohibitive to support Ada for
resource-constrained* targets in the 8080/Z80, 6809, and 6502 families,
which have been repurposed as 8-bit microcontrollers (notwithstanding AVR's
novel usage of "8-bit microcontroller" to refer to a modern RISC processor
that has 32 registers many of which are 16-, 24-, or 32-bit in size)

* e.g., 64 KiB DRAM address space; clock rate of single-digit or tens of
megahertz

Various ports of GCC to Z80 exist, but they seem to focus exclusively on
C-proper, instead of on C++ or Ada.

[Randy Brukardt]

All of the jokes are only in the AARM. Not intended for the general public.
Look up "unpolluted" if you want a laugh (use the HTML version, and not the
Ada 2020 version).

Randy.

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
message news:pgpvo7$nms$1...@dont-email.me...

> On 2018-06-22, Lucretia <lague...@googlemail.com> wrote:
>> On Friday, 22 June 2018 18:10:35 UTC+1, Simon Clubley wrote:
>>> On 2018-06-22, Lucretia <> wrote:
>>> > On Wednesday, 20 June 2018 18:55:02 UTC+1, Dan'l Miller wrote:
>>> >
>>> >> * A section of the Ada _LRM_ standard commonly called the "heart of
>>> >> darkness" which supposedly only a handful of people on the planet
>>> >> grok
>>> >
>>> > Which section is this in the manual? It should be titled that :)
>>>
>>> 3.10.2 (according to Randy)
>>

>> Thanks, but I found it in the index, it's actually labelled as that ;)
>>
>
> Is that the AARM ?
>

> It's not in the Ada 95 paper LRM I have or a PDF copy of the Ada 2012 LRM.
>

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in

message news:pgjai9$bhp$1...@dont-email.me...
...
> Personally, I don't think it's something to be proud of however.

No one is "proud" of it.

> When a language is used in the critical environments that Ada is used in,
> it shouldn't have anything in it which is that difficult to understand.

Any language that has been around for 40+ years and 5 major revisions is
going to have a few ideas that were not worth the effort. Dynamic
accessibility checks seem to be in that category. (So far as is known, no
compiler correctly implements them for Ada 2005/2012, and that hasn't
exactly led to an outcry.)

Randy.

[Randy Brukardt]

"Jacob Sparre Andersen" <ja...@jacob-sparre.dk> wrote in message
news:874lhsn...@adaheads.home...
...
> And this
> still doesn't solve all the problems related to anonymous access types
> (i.e. "the heart of darkness").

pragma Restrictions (No_Anonymous_Access);

would seem to do the trick. (Sadly, it's missing from Annex H.)

pragma Restrictions (No_Anonymous_Allocators);

does eliminate most of the oddities, but you still get dynamic accessibility
checks (and see my previous message about that).

Randy.

[Randy Brukardt]

"Dan'l Miller" <opt...@verizon.net> wrote in message

news:2d287ba3-209d-4d6a...@googlegroups.com...
...
>Well, in an alternate universe, there would be a way to accomplish
>those declarations of constants or variables in the same package as
>their subtypes.

Surely.

But Ada 83 had a goal that Ada text would be processed linearly. It didn't
quite achieve that (see visibility of goto labels), but it's close. This
goal has been preserved in all more recent revisions of the language.

This goal wasn't adopted to make it easier to write compilers (although it
sometimes has that effect), but rather to make it easier to *read* Ada code
(ease of reading being one of Ada's primary goals). In general, you don't
have to read anything following a declaration to determine how it will be
implemented and execute.

Randy.

[Tucker Taft]

Perhaps the hardest aspect of getting an Ada compiler to pass all of the ACATS conformance tests is to correctly diagnose all errors, which includes both compile-time error detection (the so-called "B" tests of the ACATS test suite) and the run-time checks, which raise exceptions when some dynamic semantics rule of the language is violated (the so-called "C" tests of the ACATS test suite).

One of the great strengths of Ada compared to other languages is the strictness of the conformance test suite, and its attention to both correctly executing "good" tests but also correctly detecting compile-time or run-time problems in "bad" tests. I remember many times when an implementor of an Ada compiler would announce that they were "almost done," only to discover that passing all of the B tests took another five person years of effort.

I would presume that correctly implementing C++ is harder than Ada these days, given that C++ seems to contain the union of all language features ever invented for any language. But relative to C or Pascal, Ada and C++ are at least one order of magnitude harder, with exceptions, generic templates, object-oriented programming, and finalization/destructors, as just a few of the sources of compiler complexity.

[Lucretia]

As there's been talk of creating a new compiler, from someone who's done it, what advise, apart from "don't do it," would you give to someone considering it?

On a separate tangent, would you say look into designing a new language completely? Again, for anyone considering it.

[Alejandro R. Mosteo]

I think someone is already playing with that idea :)

https://en.wikipedia.org/wiki/ParaSail_(programming_language)

[Lucretia]

On Tuesday, 2 October 2018 13:58:03 UTC+1, Alejandro R. Mosteo wrote:

> I think someone is already playing with that idea :)
>
> https://en.wikipedia.org/wiki/ParaSail_(programming_language)

Yes, there are others doing other stuff too.