From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ichbiah 2022 compiler mode Date: Thu, 5 Sep 2024 19:03:22 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Fri, 06 Sep 2024 02:03:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0e12de740b46adc6c5662b6a3de7c61f"; logging-data="571835"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196HhD7S2UoD6ywW2d3pq98SUKWMIXeOjM=" Cancel-Lock: sha1:lxmJz5M/f9k+WLzc1FbZtMgi9bA= X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Xref: news.eternal-september.org comp.lang.ada:66320 List-Id: "Kevin Chadwick" 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.