Split Ada into Ada 1983 and Ada 202y branches

[jquorning]

Summary

Split Ada into the embedded / system language here called Ada 1983 and into the application / RAD language Ada 202y.

Motivation

Ada is a big language. It could be advantageous to split it into two language branches. This will reduce toolchain, standard library, and runtime system complexities.

Ada 1983 = Ada 83 added lessons learned from Ada 95 .. Ada 2023. Without OOP, Child units. Ada 202y = Ada 2023 subtracted low-level like real-time, pragma, atomic, representation, access, aliased

Ada 1983 will be the 'real' Ada Ada 202y could be the base of a myriad of other languages with various syntactic traits.

Ada 1983 is for the bare metal target. Ada 202y is for the OS target.

The two branches should work together effortlessly.

Caveats and alternatives

It is far above my level of competence to write this section.

Disclaimer

This issue is more or less based on intuitive hunches and dreams.

[Lucretia]

This comes back to deprecate stuff which they won't do.

[sttaft]

We do move items into the Obsolescent Annex (Annex J) when there is a replacement. However, we don't generally remove useful capabilities.

Ada 95, Ada 2005, and Ada 2012 have certainly been used for many resource-constrained, hard real-time applications. The advanced features of Ada are designed to introduce little or no "distributed" overhead, so you only pay for what you use. The subset defined by SPARK + Ravenscar is an example of a subset that is ideal for resource constrained environments.