Re: Ichbiah 2022 compiler mode

["Randy Brukardt" <randy@rrsoftware.com>]

"Kevin Chadwick" <kc-usenet@chadwicks.me.uk> wrote in message 
news:vbc625$at65$1@dont-email.me...
...
> What do you think Ichbiah would jettison from Ada 2022? All comments
> welcome.

My recollection is that he wanted a more complex "class" feature, which IMHO 
would have made Ada more complex, not simpler.

In any case, I can't guess what Ichbiah would have suggested after 40 years 
of experience. (He probably would have moved on to some other language 
anyway, you have to be somewhat resistant to change to stick with a single 
language for your entire career. I seem to resemble that remark... ;-)

What I can do is suggest what an RLB_2022 mode would look like, as I did the 
exercise when we all were cooped up during the early days of the pandemic. 
My philosophy is that Ada has a lot of combinations of features that cause a 
lot of implementation trouble, but which are not very useful. So I want to 
reduce the combinations that cause trouble. I note that every feature is 
useful for something (else it wouldn't be in Ada in the first place). But 
some things are not useful enough for the trouble that they cause. Also note 
that I am not worrying about compatibility with Ada, which is always a 
problem when updating Ada itself.

Here's some highlights off the top of my head:

(1) Simplify the resolution model; essentially everything resolves like a 
subprogram. For instance, objects resolve similarly to enumeration literals. 
This substantially reduces the danger of use clauses (having matching 
profiles and names is less likely than just matching names), and eliminates 
the subtle differences between a constant and a function (they should really 
act the same).

(2) Operator functions have to be primitive for at least one of the types in 
the profile. (Operators in a generic formal part have a pseudo-primitive 
requirement.) That includes renamings. In exchange for that, operators have 
the same visibility as the type (which means they are always directly 
visible when any object of the type is visible). One then can eliminate "use 
type" (since it would literally do nothing).

(3) A number of syntax options are eliminated. Matching identifiers are 
required at the end of subprograms and packages. Initializers are always 
required (<> can be used if default initialization is needed). Keyword 
"variable" is needed to declare variables (we do not want the worst option 
to be the easiest to write, as it is in Ada).

(4) Anonymous types of all sorts are eliminated. For access types, we would 
use aspects to declare properties (static vs. dynamic accessibility, 
"closure" types, etc.). For arrays, see next item.

(5) The array model would be greatly simplified. New Ada users (and old ones 
as well) have a hard time dealing with the fact that the lower bound is not 
fixed in Ada. Additionally, the existing Ada model is very complex when 
private types are involved, with operators appearing long after a type is 
declared. The more complex the model, the more complex the compiler, and 
that means the more likely that errors occur in the compiler. There also is 
runtime overhead with these features. The basic idea would be to provide the 
features of an Ada.Containers.Vector, and no more. Very little is built-in. 
That means that arrays can only be indexed by integers, but that is a good 
thing: an array indexed by an enumeration type is really a map, and should 
use a map interface. So I would add a Discrete_Map to the Ada.Containers 
packages. Bounded_Arrays are a native type (most of the uses of arrays that 
I have are really bounded arrays built by hand).

A side-effect of this model change is to greatly simplify what can be 
written as discriminant-dependent components. Discriminant-dependent arrays 
as we know them are gone, replaced by a parameterized array object that has 
only one part that can change. Much of the nonsense associated with 
discriminant-dependent components disappears with this model.

(6) Static items have to be declared as such (with a "static" keyword rather 
than "constant"). Named numbers are replaced by explicit static constants. 
(I would allow writing Universal_Integer and Universal_Real, so one could 
declare static objects and operations of those types.)

(7) Types and packages have to be declared at library-level. This means that 
most generic instances also have to be declared at library-level. Subtypes, 
objects, and subprograms still can be declared at any nesting level. I make 
this restriction for the following reasons:
    (A) Accessibility checks associated with access types are simplified to 
yes/no questions of library-level or not. The only cases where accessibilty 
checks do any real good is when library-level data structures are 
constructed out of aliased objects. These would still be allowed, but almost 
all of the complication would be gone. Even if the check needs to be done 
dynamically, it is very cheap.
    (B) Tagged types declared in nested scopes necessarily require complex 
dynamic accessibility checks to avoid use of dangling types (that is, an 
object which exists of a type that does not exist).
    (C) Reusability pretty much requires ODTs to be declared in 
library-level packages. Mandating that won't change much for most programs, 
and you'll be happier in the long run if you declare the types in library 
packages in the first place.
    (D) There are a lot of semantic complications that occur from allowing 
packages in subprograms, but this is rarely a useful construct.

(8) Protected types become protected records (that is, a regular record type 
with the keyword "protected"). Primitive operations of a protected record 
type are those that are protected actions. (Entries can be declared and 
renamed as such, they would no longer match procedures, which leads to all 
kinds of nonsense.) This would eliminate the problems declaring helper types 
and especially *hiding* helper types for protected types.
(See the problems we had defining the queues in the Ada.Containers to see 
the problem.) The protected operations would allow the keyword "protected" 
in order to make the subprograms involved explicit.

(9) Strings are not arrays! Strings would be provided by dedicated packages, 
supporting a variety of representations. There would be a Root_String'Class 
that encompasses all string types. (So many operations could be defined on 
Root_String'Class).

(10) Variable-returning functions are introduced. They're pretty similar the 
semantics of anonymous access returns (or the aliased function returns 
suggested by Tucker). This means that a variable can easily be treated as a 
function (and indeed, a variable declaration is just syntactic sugar for 
such a function).

(11) Various obsolete features like representation_clauses, representation 
pragmas, and the ability to use 'Class on untagged private types are 
eliminated or restricted.

There were a couple of areas that I never made up my mind on:

(A) Do we need tasks at all? Parallel and task are very much overlapping 
capabilities. But the parallel model would need substantial changes if we 
were to allow suspension of parallel threads (Ada 2022 does not allow this). 
Suspension seems necessary to support intermittent inputs of any type 
(including interrupts) without wasting resources running busy-wait loops.

(B) Should type conversions be operators or remain as the type name as in 
Ada? A type conversion operator, automatically constructed, would allow 
user-defined types to have the same sort of conversions to numeric and 
string types that the predefined do. But an operator would make conversions 
easier, which is probably the wrong direction for a strongly typed language.

(C) I wanted to simply the assignment model, but my initial attempt did not 
work semantically. I'm not sure that simplification is possible with the Ada 
feature set (I'm sure Bob and Tuck tried to do that when creating Ada 95, 
but they failed). The main issue is that one would like to be able to 
replace discriminant checks on user-defined assignment. (Imagine the 
capacity checks on a bounded vector; Ada requires these to match, but that's 
way too strong; the only problem is if the target capacity cannot hold the 
actual length of the source object. A user-defined replacement would be 
helpful.)

My $20 worth (this was a lot more work than $0.02!!). I probably forgot a 
number of items; my actual document is about 20 pages long.

                   Randy.