Re: Ichbiah 2022 compiler mode

"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.