!standard 3.8(3) 20-01-08 AI12-0213-2/01 !standard 3.8(6/3) !standard 3.8(28) !standard 13.5.1(2) !standard 13.5.1(6) !class Amendment 20-01-08 !status work item 20-01-08 !status received 20-01-06 !priority Very_Low !difficulty Easy !subject Unify record syntax !summary Allow an alternative syntax for the end of record definitions and record representation clauses which includes identifiers. !problem Ada's record_type_definition and record_representation_clause are unique to the language in that it is the only kind of type definition to feature an enclosed list of components, and being that it is not a program unit or a named construct such as a loop, it was classically not considered relevant to allow an identfier with its enclosing "end." However, many Ada users can attest to having records with upwards of 15 or more components complete with comments and whitespace leaving the enclosing "end record" to be below the page of start of the type declaration - meaning some benefit would arise from being able to label the record declaration with the type identifier. Also, it is often the case that Ada programmers in the course of typing a record_type_definition accidently type "end identifier" out of force of habit instead of the correct "end record". !proposal We propose introducing an "end identifier" syntax for record definitions and representation clauses so that their syntax more closely matches program units such as subprogram_declarations and package_declarations. See the code fragments below for an overview of the proposed change: type Rec_B is record A : Boolean; B : Boolean; end Rec_B; for Rec_B use record A at 0 range 0 .. 0; B at 0 range 1 .. 1; end Rec_B; As an alternative to: type Rec_B is record A : Boolean; B : Boolean; end record; for Rec_B use record A at 0 range 0 .. 0; B at 0 range 1 .. 1; end record; !wording Replace 3.8(3) with: record_definition ::= record component_list end record_terminator | null record record_terminator ::= defining_identifier | record Add after 3.8(6/3): If a /record_/identifier appears at the end of the record_definition, it shall repeat the defining_identifier of the enclosing full_type_declaration. Replace 3.8(28) with: type Complex is record Re : Real := 0.0; Im : Real := 0.0; end Complex; Replace 13.5.1(2) with: record_representation_clause ::= for /first_subtype_/local_name use record [mod_clause] {component_clause} end record_representation_terminator; record_representation_terminator ::= local_name | record Add after 13.5.1(6): If a local_name appears at the end of the record_representation_clause, it shall repeat the /first_subtype_/local_name. !discussion We considered allowing "record" to be optional as well, so that one could write "end Complex" for the example above. We rejected that because no one wanted to allow "end" by itself in this context, and requiring either "record" or an identifier would have added yet another way to terminate a construct, reducing consistency further. This proposal is at least similar to "end loop ". Following this we recieved user feedback showing a preference for "end id" rather than "end record id". !ACATS test An ACATS B-Test and C-Test are needed to check that the new capabilities are supported. !appendix From: Justin Squirek Sent: Monday, January 6, 2020 9:39 AM Hi everyone, following internal discussions within AdaCore I would like to propose changes to the current Ada 2020 standard. [Other AIs removed, filed appropriately - Editor] AI12-0213: Withdraw the changes to record syntax in this AI and resubmit a modified proposal more like the first revision. As a reminder, the approved change allowed a record type identifier to optionally appear after “end record” in a record type declaration or record representation clause while the original proposal was for an alternative syntax allowing both "end record" and "end identifier" . This new modified proposal is attached. [Version /01 of this AI - Editor.] Link to the relevant Ada/SPARK AI12-0213 RFC: https://github.com/AdaCore/ada-spark-rfcs/pull/13 **************************************************************** From: Randy Brukardt Sent: Monday, January 6, 2020 7:48 PM ... > AI12-0213: Withdraw the changes to record syntax in this AI and > resubmit a modified proposal more like the first revision. As a > reminder, the approved change allowed a record type identifier to > optionally appear after "end record" in a record type declaration or > record representation clause while the original proposal was for an > alternative syntax allowing both "end record" and "end identifier" . > This new modified proposal is attached. Procedurally, I don't think it is acceptable to come back with the exact same proposal that the ARG found unacceptable the first time. At a minimum, you need to make some attempt to address the concerns of the ARG. Otherwise, we just end up having to rehash the same discussion we had last time, and it is highly likely that we would get the same result. For good reason, we don't allow reopening decided AIs without significant new information, otherwise we would never make any progress. It *is* in bounds to say that you have feedback that says that the ARG's counterproposal is not acceptable. But in the absence of a new counter proposal, that probably means that it is better to make no change at all in this area. We surely don't need change for changes sake. Anyway, since we're going to have this discussion again, I want to find out what the truly interested Ada community has to say. Therefore, I've started a conversation on the technical issues associated with this AI on Ada-Comment. Please make any technical comments there, and not on this list (so everyone interested can see them) -- restrict any replies to this e-mail to the procedural issues. **************************************************************** From: Justin Squirek Sent: Tuesday, January 7, 2020 9:44 AM > Procedurally, I don't think it is acceptable to come back with the > exact same proposal that the ARG found unacceptable the first time. At > a minimum, you need to make some attempt to address the concerns of > the ARG. Otherwise, we just end up having to rehash the same > discussion we had last time, and it is highly likely that we would get > the same result. For good reason, we don't allow reopening decided AIs > without significant new information, otherwise we would never make any > progress. This is not true for the ARG members that are part of AdaCore. I believe there has been a shift in perspective on this one - which is why I moved that we re-examine it. Also, it is not exactly the same as the original proposal as allowing only "end" is not in it which did incorporate some feedback. > It *is* in bounds to say that you have feedback that says that the > ARG's counterproposal is not acceptable. But in the absence of a new > counter proposal, that probably means that it is better to make no > change at all in this area. We surely don't need change for changes sake. Perhaps that is the correct thing to do here then since I believe AdaCore members no longer see the current wording as beneficial to the language - including myself. > Anyway, since we're going to have this discussion again, I want to > find out what the truly interested Ada community has to say. > Therefore, I've started a conversation on the technical issues > associated with this AI on Ada-Comment. Please make any technical > comments there, and not on this list (so everyone interested can see > them) -- restrict any replies to this e-mail to the procedural issues. Great, as you know I attempted to cross post this on Ada-Comment to do the same. Also, we did get some feedback on Github as well from Ada users in support of the 'new' proposal. **************************************************************** From: Erhard Ploedereder Sent: Monday, January 6, 2020 9:20 PM > AI12-0213: Withdraw the changes to record syntax in this AI and > resubmit a modified proposal more like the first revision. As a > reminder, the approved change allowed a record type identifier to > optionally appear after “end record” in a record type declaration or > record representation clause while the original proposal was for an > alternative syntax allowing both "end record" and "end identifier" . > This new modified proposal is attached. For obvious reasons, the "new modified proposal" would have to deal with the following issue: if "end id" is ok for records, it also should be ok for tasks, packages, accepts, and everything else that ends with 'end '. Otherwise everybody will ask why the rules for records are different from everything else. **************************************************************** From: Tucker Taft Sent: Tuesday, January 7, 2020 9:59 AM Well, tasks, packages, and accepts all end with "end []" already. The select statement ends with "end select" but there is no obvious to use for that. "end loop" *requires* the loop identifier after "loop" if there is a label on the loop. That was the original justification for the "end record " but several folks found the verbosity of "end record " unhelpful. > Otherwise everybody will ask why the rules for records are different > from everything else. They will be closer to other things if we allow at all, independent of exactly what we allow before it. **************************************************************** From: Erhard Ploedereder Sent: Wednesday, January 8, 2020 9:46 AM Shows how far my brain is gone. Sorry. Yesterday I obviously believed that the standard syntax is "end package", "end accept", and "end task" in analogy to "end record". But also goes to show that some folks expect uniformity :-) in whatever the syntax may be. So, "end record " would be an odd alternative, even if "end record" has been a bit odd, albeit explainable, from day one. **************************************************************** From: Tucker Taft Sent: Wednesday, January 8, 2020 9:56 AM For what it is worth, in ParaSail, everything ends "end " with neither optional. Let's hear it for uniformity ... ;-) -Tuck **************************************************************** From: Stephen Michell Sent: Wednesday, January 8, 2020 12:34 PM But the standard syntax is “end if’, “end loop” and “end case”. I think that it should be left alone. **************************************************************** From: Randy Brukardt Sent: Monday, January 6, 2020 7:24 PM We recently received a comment that the proposed solution for this problem was not acceptable and that the original proposal should be adopted instead. The reasoning for that is "user feedback". I would like to get some feedback from the users here to find out what the broader Ada community thinks about this proposal. All of these proposals are intending to make the end of records to be more like program units. Many of us (including me) have put an identifier at the end of a record rather than "record", and that would have the same benefits as putting the id at the end of a subprogram. All of these proposals also change the end of record representation clauses in order to be consistent. [1] The current proposal is to add an optional id after "end record", which, if given, would have to match the identifier of the enclosing type declaration. The ARG chose this proposal as it matches the syntax for "end loop" (although it does not match semantically -- the id is not optional for a loop). [2] The original proposal was to allow, instead of "end record", "end [id]", with the id, if any, required to match the enclosing type declaration. The ARG did not like the possibility of a record ending with "end;", given that the id is optional in this proposal. (More on this below in my personal thoughts.) Note that there is no "end" like this in Ada's current syntax. [3] An alternative proposal that was considered by the ARG was to allow either "end record" or "end id", with the id being required to match the enclosing type declaration. We didn't adopt this because it would be different than any existing syntax in Ada. However, if you consider the semantics as well, [1] is also different than any existing proposal, so this does not seem like a very strong reason to prefer [1] over [3]. [4] Finally, we could do nothing at all. Ada has used "end record" for more than 40 years and it is unclear why in 2020 it is so important to change this. My personal opinion on this is that any proposal other than [2] is acceptable, but my preference is for [4] (do nothing). This syntax causes an occasional annoyance (usually a syntax error when compiling), but one grumbles about it, fixes it, and moves on. If we could eliminate the annoyance by changing this syntax to be consistent with some other syntax, that might be a good idea. But we can't do that (since we have to continue to allow "end record"), and given that none of these changes really provides any new functionality, it seems more like a case of moving the "bump under the rug" (as Tucker sometimes has put it) than any sort of fix. As such, and given that there is a non-zero amount of work for implementers, authors, trainers in this area, it doesn't seem worth making any change here. I find proposal [2] unacceptable because of the presence of "end;" as an acceptable ending for a record. Every Ada style guide I have read bans writing "end;" other than in the case of anonymous blocks (I even saw one guide that banned anonymous blocks so "end;" was never appropriate). It doesn't make any sense to adopt a syntax that then 99% of style guides would immediately ban. Why make anyone waste time on that? [Aside: Ada's syntax is pretty close to the best possible syntax IMHO, but one thing it got wrong is too much optionality. There are a number of constructs that should be mandated, and indeed many style guides do mandate them, but Ada allows them being omitted. We can't really fix this because it would likely break some existing code not built under a strong style guide (such as ACATS tests, which intentionally use a variety of styles). But there is no reason to repeat a mistake. Anyway, let's hear where all of you stand on this, and which of these proposals you find acceptable and why. This is one of these simple questions that *everyone* probably has an opinion on, so let's hear it! **************************************************************** From: Richard Wai Sent: Monday, January 6, 2020 8:00 PM I'm firmly in the [4] camp - do nothing. From a practical perspective, I am not sold on the value of this proposal. Typically, "end Something;" syntax is helpful for readability when a combination of nesting and length can make it otherwise diffficult to separate what, exactly, is ending. This is particularly true for loops. In the case of record types, I can only see this proposal being useful if record types could be nested ("anonymous" records), i.e. Type A is Record Nested: record Inner_Thing: object; End record; End record; Obviously this is not currently valid Ada (and I hope it never will be). So that, to me, is the more important reason this proposal has little value. Besides that, I can only see this being very slightly justified for extremely long record definitions. But in my opinion, if you have a record type that is 100 lines long, you are probably not doing it in the best way. One could argue "what if the record definition has a lot of comments". To that I'd say - well you still aren't likely going to need to know what record is ending at the bottom of that anyways - because there is no nesting! I'd be serriously interested in hearing more rationale for this proposal other than introducing superficial othagonality that is (from my exeprience), of no practical value. I can't think of any, to be honest. **************************************************************** From: Tucker Taft Sent: Monday, January 6, 2020 8:11 PM There might have been some confusion in what was suggested. I believe the discussions at AdaCore led to the idea of allowing either: end record; or end ; and did *not* allow the combination: end record ; I believe the point was that the fewer options the better, but the form "end ;" is something that many, many people seem to have typed in the past unintentionally, whereas probably no one ever wrote "end record ;". Hence it seems silly to standardize some new form that no one has ever written, while there is some justification for having a form that includes the record-type identifier. I am personally on the fence on this one whether we should do anything at all. But I agree that if we do anything, we should definitely not allow both "end record ;" and "end ;" because I know some project's coding convention is going to require one of them while another is going to require the other! ;-) **************************************************************** From: Randy Brukardt Sent: Monday, January 6, 2020 8:41 PM > There might have been some confusion in what was suggested. > I believe the discussions at AdaCore led to the idea of allowing > either: > > end record; > > or > > end ; > > and did *not* allow the combination: > > end record ; I'm just commenting on the proposal that was actually posted, as I don't think anyone is going to guess what the actual intent is. The syntax in this proposal is: record_definition ::= record component_list end record_terminator record_terminator ::= [defining_identifier] | [record] ...which has both the identifier and the keyword record optional. One could read the English description to support what you suggest here (and I suggested as proposal [3] in my original message), but if there is a conflict !wording is what one depends upon -- and that leaves the identifier optional. > I believe the point was that the fewer options the better, but the > form "end ;" is something that many, many people seem to have > typed in the past unintentionally, whereas probably no one ever wrote > "end record ;". Hence it seems silly to standardize some new form > that no one has ever written, while there is some justification for > having a form that includes the record-type identifier. > > I am personally on the fence on this one whether we should do anything > at all. But I agree that if we do anything, we should definitely not > allow both "end record ;" and "end ;" because I know some > project's coding convention is going to require one of them while > another is going to require the other! ;-) I agree that it doesn't make sense to allow both (note that I didn't include that in the list of possibilities in my original message). As I said previously, I could live with either of these, but neither of them are particularly close to the "original" proposal *or* the posted new proposal. In any case, I'd like to hear from some of the 94 other people here, since I pretty much know how the usual suspects think on this topic. :-) **************************************************************** From: Niklas Holsti Sent: Monday, January 6, 2020 11:38 PM When I make this typing mistake, it is always of the form "end id", probably from analogy with subprograms, so I vote for [3] if something is done. But I agree with Randy that the problem is very minor. **************************************************************** From: Dirk Craeynest Sent: Tuesday, January 7, 2020 1:46 AM What I'm missing, both from this mail thread and from the AI itself at http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0213-1.txt?rev=1.1 is a description of "the programming problem and why the Ada 2012 solution is complex, expensive, or impossible." (quoted from "Community Input for the Maintenance and Revision of the Ada Programming Language" at https://www.adaic.org/2017/08/community-input-for-ada/). I may be overlooking something, but without such rationale to warrant this change IMHO the "problem" is so minor that option [4] is preferable (i.e. do nothing). **************************************************************** From: Arnaud Charlet Sent: Tuesday, January 7, 2020 2:31 AM > There might have been some confusion in what was suggested. I believe the > discussions at AdaCore led to the idea of allowing either: > > end record; > > or > > end ; > > and did *not* allow the combination: > > end record ; That's correct, the updated proposal is not suggesting to allow "end;", if it appears it does, that's a mistake. I'm in favor of either doing nothing, or allowing the above possible "end ;" as long as we don't go with the currently approved AI ("end record [record_type_identifier];") **************************************************************** From: Weston Pan Sent: Tuesday, January 7, 2020 3:29 AM Part of me always felt that “end identifier;” should have been the way from the beginning. After not programming in Ada for long periods (which is the norm for me :( ) I find myself automatically trying to do that. I often add a comment after “end record;” just to put the record name so that I don’t have to scroll the screen to see what type I am looking at. Of course this is more of an issue with larger records, and they do occur now and then, especially when I add comments to each record field. If the ARG chooses “do nothing”, I won’t lose sleep over it. The edition of the Pi symbol seems far less important than “end identifier;”, but it was still added to the standard and thus requiring full unicode support. **************************************************************** From: Jeffery R. Carter Sent: Tuesday, January 7, 2020 2:22 AM > My personal opinion on this is that any proposal other than [2] is > acceptable, but my preference is for [4] (do nothing). > > [Aside: Ada's syntax is > pretty close to the best possible syntax IMHO, but one thing it got > wrong is too much optionality. There are a number of constructs that > should be mandated ... I am in full agreement with Brukardt on this( including the comment on too much optionality [and I would add too many implementation-defined things]). There is no real problem here and nothing that needs to be fixed. While "end record ID;" is appealing intellectually due to its similarity to "end loop ID;", the only error I have ever made with record termination is "end ID;", so if a change is to be made, I would want it to be to allow "end ID;". **************************************************************** From: Jean-Pierre Rosen Sent: Tuesday, January 7, 2020 4:41 AM I was never tempted to write "end ;", and was surprised at this proposal. Moreover, modern GUIs close the current constuct automatically, and that's extremely convenient. So, I type "record Ctl-E" (which adds the "end record;"), and then write the inside. Even if you write the "end record" yourself, it's better to start with the closing construct before you fill the inside, i.e. write from the outside inwards rather than from the top down. So for my use-case, it's very minimal value (i.e. I vote for [4]-forget it) **************************************************************** From: Jean-Pierre Rosen Sent: Tuesday, January 7, 2020 4:47 AM > Part of me always felt that “end identifier;” should have been the way > from the beginning. After not programming in Ada for long periods > (which is the norm for me :( ) I find myself automatically trying to > do that. I often add a comment after “end record;” just to put the > record name so that I don’t have to scroll the screen to see what type I am > looking at. Don't you have an editor that brings you to the beginning of the current construct? In GPS, Alt-Up does the trick. > Of course this is more of an issue with larger records, and they do > occur now and then, especially when I add comments to each record field. > If the ARG chooses “do nothing”, I won’t lose sleep over it. The > edition of the Pi symbol seems far less important than “end > identifier;”,  but it was still added to the standard and thus requiring > full unicode support. Which is exactly why it was added - to make sure that every compiler was supporting Unicode. Nobody uses that declaration. **************************************************************** From: John Barnes Sent: Tuesday, January 7, 2020 10:20 AM I agree with the thought that we should do nothing to the syntax of the end of records. It has been around for some 40 years and the language is big enough already. **************************************************************** From: Bob Duff Sent: Tuesday, January 7, 2020 12:52 PM > That's correct, the updated proposal is not suggesting to allow > "end;", if it appears it does, that's a mistake. > > I'm in favor of either doing nothing, or allowing the above possible > "end ;" as long as we don't go with the > currently approved AI ("end record [record_type_identifier];") I agree with Arno's position. P.S. Here's a type declaration in the private part of the System.Tasking package in the GNAT runtimes. You don't need to read it, but just note that when you're looking at "end record;", you can't see "type Ada_Task_Control_Block". Of course you can press your "go to beginning" button, but that's not quite as easy as just pointing your eyes at the screen. I don't agree with people who say it's bad design because it's too big. It's just the right size for the purpose. type Ada_Task_Control_Block (Entry_Num : Task_Entry_Index) is limited record Common : Common_ATCB; -- The common part between various tasking implementations Entry_Calls : Entry_Call_Array; -- An array of entry calls -- -- Protection: The elements of this array are on entry call queues -- associated with protected objects or task entries, and are protected -- by the protected object lock or Acceptor.L, respectively. New_Base_Priority : System.Any_Priority; -- New value for Base_Priority (for dynamic priorities package) -- -- Protection: Self.L Open_Accepts : Accept_List_Access; -- This points to the Open_Accepts array of accept alternatives passed -- to the RTS by the compiler-generated code to Selective_Wait. It is -- non-null iff this task is ready to accept an entry call. -- -- Protection: Self.L Chosen_Index : Select_Index; -- The index in Open_Accepts of the entry call accepted by a selective -- wait executed by this task. -- -- Protection: Written by both Self and Caller. Usually protected by -- Self.L. However, once the selection is known to have been written it -- can be accessed without protection. This happens after Self has -- updated it itself using information from a suspended Caller, or -- after Caller has updated it and awakened Self. Master_Of_Task : Master_Level; -- The task executing the master of this task, and the ID of this task's -- master (unique only among masters currently active within Parent). -- -- Protection: Set by Activator before Self is activated, and read -- after Self is activated. Master_Within : Master_Level; -- The ID of the master currently executing within this task; that is, -- the most deeply nested currently active master. -- -- Protection: Only written by Self, and only read by Self or by -- dependents when Self is attempting to exit a master. Since Self will -- not write this field until the master is complete, the -- synchronization should be adequate to prevent races. Alive_Count : Natural := 0; -- Number of tasks directly dependent on this task (including itself) -- that are still "alive", i.e. not terminated. -- -- Protection: Self.L Awake_Count : Natural := 0; -- Number of tasks directly dependent on this task (including itself) -- still "awake", i.e., are not terminated and not waiting on a -- terminate alternative. -- -- Invariant: Awake_Count <= Alive_Count -- Protection: Self.L -- Beginning of flags Aborting : Boolean := False; pragma Atomic (Aborting); -- Self is in the process of aborting. While set, prevents multiple -- abort signals from being sent by different aborter while abort -- is acted upon. This is essential since an aborter which calls -- Abort_To_Level could set the Pending_ATC_Level to yet a lower level -- (than the current level), may be preempted and would send the -- abort signal when resuming execution. At this point, the abortee -- may have completed abort to the proper level such that the -- signal (and resulting abort exception) are not handled any more. -- In other words, the flag prevents a race between multiple aborters -- -- Protection: protected by atomic access. ATC_Hack : Boolean := False; pragma Atomic (ATC_Hack); -- ????? -- Temporary fix, to allow Undefer_Abort to reset Aborting in the -- handler for Abort_Signal that encloses an async. entry call. -- For the longer term, this should be done via code in the -- handler itself. Callable : Boolean := True; -- It is OK to call entries of this task Dependents_Aborted : Boolean := False; -- This is set to True by whichever task takes responsibility for -- aborting the dependents of this task. -- -- Protection: Self.L Interrupt_Entry : Boolean := False; -- Indicates if one or more Interrupt Entries are attached to the task. -- This flag is needed for cleaning up the Interrupt Entry bindings. Pending_Action : Boolean := False; -- Unified flag indicating some action needs to be take when abort -- next becomes undeferred. Currently set if: -- . Pending_Priority_Change is set -- . Pending_ATC_Level is changed -- . Requeue involving POs -- (Abortable field may have changed and the Wait_Until_Abortable -- has to recheck the abortable status of the call.) -- . Exception_To_Raise is non-null -- -- Protection: Self.L -- -- This should never be reset back to False outside of the procedure -- Do_Pending_Action, which is called by Undefer_Abort. It should only -- be set to True by Set_Priority and Abort_To_Level. Pending_Priority_Change : Boolean := False; -- Flag to indicate pending priority change (for dynamic priorities -- package). The base priority is updated on the next abort -- completion point (aka. synchronization point). -- -- Protection: Self.L Terminate_Alternative : Boolean := False; -- Task is accepting Select with Terminate Alternative -- -- Protection: Self.L -- End of flags -- Beginning of counts ATC_Nesting_Level : ATC_Level := Level_No_ATC_Occurring; -- The dynamic level of ATC nesting (currently executing nested -- asynchronous select statements) in this task. -- Protection: Self_ID.L. Only Self reads or updates this field. -- Decrementing it deallocates an Entry_Calls component, and care must -- be taken that all references to that component are eliminated before -- doing the decrement. This in turn will require locking a protected -- object (for a protected entry call) or the Acceptor's lock (for a -- task entry call). No other task should attempt to read or modify -- this value. Deferral_Level : Natural := 1; -- This is the number of times that Defer_Abort has been called by -- this task without a matching Undefer_Abort call. Abortion is only -- allowed when this zero. It is initially 1, to protect the task at -- startup. -- Protection: Only updated by Self; access assumed to be atomic Pending_ATC_Level : ATC_Level_Base := Level_No_Pending_Abort; -- Indicates the ATC level to which this task is currently being -- aborted. Two special values exist: -- -- * Level_Completed_Task: the task has completed. -- -- * Level_No_Pending_Abort: the task is not being aborted to any -- level. -- -- All other values indicate the task has not completed. This should -- ONLY be modified by Abort_To_Level and Exit_One_ATC_Level. -- -- Protection: Self.L Serial_Number : Task_Serial_Number; -- Monotonic counter to provide some way to check locking rules/ordering Known_Tasks_Index : Integer := -1; -- Index in the System.Tasking.Debug.Known_Tasks array User_State : Long_Integer := 0; -- User-writeable location, for use in debugging tasks; also provides a -- simple task specific data. Free_On_Termination : Boolean := False; -- Deallocate the ATCB when the task terminates. This flag is normally -- False, and is set True when Unchecked_Deallocation is called on a -- non-terminated task so that the associated storage is automatically -- reclaimed when the task terminates. Attributes : Attribute_Array := (others => 0); -- Task attributes -- IMPORTANT Note: the Entry_Queues field is last for efficiency of -- access to other fields, do not put new fields after this one. Entry_Queues : Task_Entry_Queue_Array (1 .. Entry_Num); -- An array of task entry queues -- -- Protection: Self.L. Once a task has set Self.Stage to Completing, it -- has exclusive access to this field. end record; **************************************************************** From: Stephen Leake Sent: Tuesday, January 7, 2020 1:26 PM My preferences, in order: 4 3 I have occasionally typed "end ;", but Emacs does "end record;" for me, so I should use that more. **************************************************************** From: Vincent Marciante Sent: Tuesday, January 7, 2020 5:24 AM Writing Ada exclusively for 30 years, can't remember ever writing "end id" for records (and hate seeing "begin -- [sub name]" all over the place - especially in short subprograms). So, I'd vote [4] do nothing! If a change is made, I'd vote [1] "end record [id]" with id optional and would _hate_ [2] optional "end (record | id)" **************************************************************** From: Randy Brukardt Sent: Tuesday, January 7, 2020 4:39 PM ... > P.S. Here's a type declaration in the private part of the > System.Tasking package in the GNAT runtimes. You don't need to read > it, but just note that when you're looking at "end record;", you can't > see "type Ada_Task_Control_Block". Playing Devil's Advocate here, one can use this example in support of "end record id" or even "end record". Why? Because when you doing maintenance in unfamiliar code, and have searched for an id, not knowing what it's in, "end record" tells you more than "end id". Entry_Queues : Task_Entry_Queue_Array (1 .. Entry_Num); -- An array of task entry queues -- -- Protection: Self.L. Once a task has set Self.Stage to Completing, it -- has exclusive access to this field. end Task_Block; If I see "end id", I would first think subprogram, quickly reject that, but then I'd probably think package, and would have no way to tell. For people that use suffixes as part of their names, that wouldn't be a problem: end Task_Block_Record; ...but for the many who dislike suffixes, the names would often be unlike what sort of entity is involved. I doubt this would change anyone's mind, but it does show that this is not an open-and-shut of being better in all circumstances. **************************************************************** From: Alejandro R. Mosteo Sent: Tuesday, January 7, 2020 10:39 AM Another one in favor of no change. I use autocomplete these days anyway, it's been ages since this bite me. **************************************************************** From: Simon Wright Sent: Wednesday, January 8, 2020 2:36 AM Me too. My more common mistake (I think, not counting here) is to type 'end select'. **************************************************************** From: Simon Wright Sent: Wednesday, January 8, 2020 2:36 AM 'end accept'. Sorry. **************************************************************** From: Jeff Cousins Sent: Wednesday, January 8, 2020 11:09 AM I’d be ok with [1] or [4]. I think the talk about auto-complete is a bit of a red herring, this AI is more about readability than writability. **************************************************************** From: Jean-Pierre Rosen Sent: Wednesday, January 8, 2020 11:22 AM Not as far as some people complained that users would "naturally" write "end ", and the argument is that nowadays you use autocomplete, so this does not happen so often. On the side of readability, a decent environment also has a "goto beginning of declaration" function, so finding the name of the type that corresponds to "end record" is no big deal either. The main point is that with modern IDEs, this change is even less useful than in 1983... **************************************************************** From: Brad Moore Sent: Wednesday, January 8, 2020 6:51 PM I'd be Ok with [1] or [4], nothing else. I don't have a strong preference between these two, but if I had to pick, I'd stick with [4], the current proposal. I think making "record" in "end record" optional introduces a backwards incompatibility. Not for the compiler, but mentally for the programmers who have used the existing syntax historically. I fear having two different ways for how to end a record declaration will just add confusion, and introduce coding style arguments. I think this would be confusing for new people learning the language as well. At the same time, I see adding the id after end record is not a different syntax, but an extended "more annotated" form to the existing familiar syntax. I myself never write the mistake of writing "end id;" (At least not that I can recall). When learning to program in Ada, record types are used frequently enough that I think most people quickly get used to the syntax. But I think there are a lot of people who currently write; end record; -- id particularly for large record types. I see it as a minor improvement to allow eliminating the comment, and having the compiler check that the id matches the declaration name. Comments often become stale and out of date. For example, if someone during maintenance decides to modify the name of a record type, the comment update can be missed, particularly for larger record types. For the same reason, I wish that the id could be accepted after "begin" for subprograms, rather than having to use comments, but I digress. **************************************************************** From: Brad Moore Sent: Wednesday, January 8, 2020 10:37 PM > I'd be Ok with [1] or [4], nothing else. I don't have a strong > preference between these two, but if I had to pick, I'd stick with > [4], the current proposal. Just for the record, or rather the end of it; ;-), I meant [1], the current proposal not [4]. **************************************************************** From: Weston Pan Sent: Wednesday, January 8, 2020 7:23 PM After reading Brad's comment, I now prefer [1] "end record id;" , but am okay with [4] "do nothing" since it's a minor thing. **************************************************************** From: Jean-Pierre Rosen Sent: Wednesday, January 8, 2020 11:53 PM > But I think there are a lot of people who currently write; > > end record; -- id > > particularly for large record types. > > I see it as a minor improvement to allow eliminating the comment, and > having the compiler check that the id matches the declaration name. Excellent idea. I'll write an AdaControl rule to check the presence of this comment. This should be sufficient for those who want the id, and close the debate. **************************************************************** From: Weston Pan Sent: Thursday, January 9, 2020 12:58 AM There are people who do not use GNAT which last time I read AdaControl has only been useable with it. But do correct me if I am wrong. **************************************************************** From: Weston Pan Sent: Thursday, January 9, 2020 1:05 AM I should point out that I’m not against the idea of AdaControl having such a rule available. It definitely would be a good feature to have for users of the tool. **************************************************************** From: Jean-Pierre Rosen Sent: Thursday, January 9, 2020 4:19 AM > There are people who do not use GNAT which last time I read AdaControl > has only been useable with it. But do correct me if I am wrong. It's true that currently, only Gnat-ASIS is able to support AdaControl. If you want to use it with another compiler, just install a Gnat-CE in addition, and AdaControl will work with it. **************************************************************** From: Weston Pan Sent: Thursday, January 9, 2020 8:49 AM Yes, many people could do that. There will still be some who cannot, such as those whose company explicitly forbids installation of non-approved tools, especially in classified work environments. **************************************************************** From: Christoph Grein Sent: Thursday, January 9, 2020 10:54 AM Having worked for 25 years with Ada (mainly 83, a lot 95 and a bit of 2005, 2012) and read all these opinions, I strongly vote for 4, do nothing; but 1, end record [id], is also OK. I'm strongly opposed to 2. Seeing      Comp: Some_Name;   end Id; I immediately would think of a (nested) package. **************************************************************** From: Randy Brukardt Sent: Friday, January 10, 2020 7:54 PM ... > This is not true for the ARG members that are part of AdaCore. I > believe there has been a shift in perspective on this one - which is > why I moved that we re-examine it. Also, it is not exactly the same as > the original proposal as allowing only "end" is not in it which did > incorporate some feedback. Unfortunately, the posted AI did not make this intent clear, as the syntax is in brackets (which means optional for Ada syntax). And the discussion references the "original proposal". I've corrected the AI that you sent to reflect this intent, both the syntax and the discussion. It will be posted as an alternative to the original AI (AI12-0213-2). [Version /01 of this AI - Editor.] **************************************************************** From: Randy Brukardt Sent: Friday, January 10, 2020 7:54 PM ... > Anyway, let's hear where all of you stand on this, and which > of these proposals you find acceptable and why. This is one > of these simple questions that *everyone* probably has an > opinion on, so let's hear it! Thanks to everyone that responded so far. I made a simple spreadsheet to tally the opinions received. I gave 2 points to everyone's first choice, and 1 point to their second choice. Since I didn't make a formal straw poll, I had to interpret everyone's response, so some people might have preferred different weighting of their response -- so this is best used as a general guide. Here's the result: 19 Respondents 33 pts, 66% -- Do nothing. ("end record") 9 pts, 18% -- AI12-0213-1 ("end record [id]") 8 pts, 16% -- AI12-0213-2 ("end id | end record") Interestingly, several people that voted for AI12-0213-1 said they couldn't live with AI12-0213-2. And several people that voted for AI12-0213-2 said they couldn't live with AI12-0213-1. So this looks like the definition of "lack of consensus"! Note that the scoring scheme only assigns 2 points to someone that only made a single choice, so it's the case that the people that voted only for do nothing are underweighted in this result. I've attached the spreadsheet for the ultra-curious, it gives the detailed scoring rules I used and the individual results. If you haven't responded yet, feel free to do so. If enough additional people respond, I'll update the spreadsheet before Wednesday's ARG meeting. **************************************************************** From: Arnaud Charlet Sent: Saturday, January 11, 2020 3:42 AM > So this looks like the definition of "lack of consensus"! Agreed, clear lack of consensus, so let's abandon the current AI and not discuss this non important issue further :-) **************************************************************** From: Bob Duff Sent: Saturday, January 11, 2020 6:33 AM > Thanks to everyone that responded so far. I made a simple spreadsheet > to Thanks, Randy. > So this looks like the definition of "lack of consensus"! And the definition of "bike shedding". ;-) **************************************************************** From: Tucker Taft Sent: Saturday, January 11, 2020 7:26 AM I will say that Christoph Grein's comment was the most interesting to me, and made me feel that our original notion of "end record [id]" was the best, so feel free to change my vote to that. From a readability point of view, it seems superior to any of the other suggestions. **************************************************************** From: Martin Dowie Sent: Saturday, January 11, 2020 8:40 AM +1 for that **************************************************************** From: Pascal Pignard Sent: Saturday, January 11, 2020 11:25 AM > ... > If you haven't responded yet, feel free to do so. If enough additional > people respond, I'll update the spreadsheet before Wednesday's ARG meeting. Well, let's take the opportunity to remind what is saying the language about end. From the classification of the invaluable John Barnes' book, end occurrences are: a) accept Toto [...] do ... end [Toto]; b) begin ... end; c) procedure | function | package | package body | task | task body | protected | protected type | protected body Toto [...] is ... end [Toto]; d) if ... end if; case ... end case; loop ... end loop; e) return ... do ... end return; f) record ... end record; g select ... end select; For d, e, f and g: the word after end repeats the introduction word of the structure. It would have been the same for b except that "end begin" isn't so appealing. These structures are unnamed unlike a and c which are named structures Thus for those a and c, the chosen optional word after end was the name given to the structure which has been obviously preferred to the introduction word of the structure as for instance: package Toto is ... end package; These latter structures are named because the name is meaningful in order to refer to it. This name was conveniently reused to help for reading and error checking. A same logical named record structure might have been: record | class type Toto is [new ... with] ... end Toto; Perhaps for another Ada language. Thus, my personal opinion is for do nothing for current Ada. **************************************************************** From: Justin Squirek Sent: Saturday, January 11, 2020 8:26 AM As the instigator of this change I suppose I should say a couple things. The idea behind end id | end record was to provide both readability and convenience. If you prefer the current syntax it would allow you to continue to use it and I assume most of you guys who have already written large programs would not - for the sake of consistency. However, the problem remains that having an extremely large record forces the programmer to either scroll up or add a comment at the "end record" section. I don't think auto-complete and keeping things the way they are for the sake of it (which seems a bit like circular reasoning : P) are very valid arguments and making small changes like this to the language could be a great step in making Ada feel more friendly and accessible to new users as Rust kind of steals away attention that Ada used to get. I believe we need to move to get a fresh user-base. If we include those who provided feedback on the Github page the vote would look very different as all 8 people who commented liked "end id | end record". If you add my vote to it then that makes it 9 extra votes in favor of that option - that is if Bob wasn't counted already. https://github.com/AdaCore/ada-spark-rfcs/pull/13 **************************************************************** From: Peter Hermann Sent: Saturday, January 11, 2020 12:18 PM ---pro: with this, my own typical lines of e.g.    end record -- [id] ((as well as      begin -- subroutine_name      end if -- if_command_repeat      end procname; -- proc      end packname; -- body   etc. )) could be verified by the compiler. ---contra: OTOH,   1. backward compatibility at risk   2. burden for compiler writers **************************************************************** From: Tucker Taft Sent: Sunday, January 12, 2020 2:34 PM > ... > b) begin ... end; Don't forget "Toto: [declare ...] begin ... end Toto;" > c) procedure | function | package | package body | task | task body | > protected | protected type | protected body Toto [...] is ... end > [Toto]; > d) if ... end if; case ... end case; loop ... end loop; Don't forget "Toto: [for ...] loop ... end loop Toto;" > e) return ... do ... end return; > f) record ... end record; > g select ... end select; > > For d, e, f and g: the word after end repeats the introduction word of the > structure. It would have been the same for b except that "end begin" isn't > so appealing. These structures are unnamed unlike a and c which are named > structures Not always, since declare blocks and loops can have "statement identifiers," and when they do, the ending identifier is not optional. So making any sort of general statement is difficult! I think we can decide to do something (or not) and not fear that we are breaking some sort to Ada "rule" here. ;-) From my perspective, it really should be about readability, not about writability. **************************************************************** From: Randy Brukardt Sent: Sunday, January 12, 2020 3:00 PM > As the instigator of this change I suppose I should say a couple > things. > > The idea behind end id | end record was to provide both readability > and convenience. If you prefer the current syntax it would allow you > to continue to use it and I assume most of you guys who have already > written large programs would not - for the sake of consistency. > However, the problem remains that having an extremely large record > forces the programmer to either scroll up or add a comment at the "end > record" section. Readability seems to favor "end record id" (and argubly adding the optional ability to say "end package id", "end procedure id", etc.). I think I will change my vote to favor "end record id" over "end id", as Christoph and Tucker have reconvinced me that it is better. > I don't think auto-complete and keeping things the way they are for > the sake of it (which seems a bit like circular reasoning : P) are > very valid arguments and making small changes like this to the > language could be a great step in making Ada feel more friendly and > accessible to new users as Rust kind of steals away attention that Ada > used to get. I believe we need to move to get a fresh user-base. I don't see how adding a fifth form of ending (and either proposed choice is a fifth form of ending by my count, as the id is not optional in "end loop id", so either of these are different than any existing choice) is making anything "more friendly". One would need to redesign the syntax for that. (And I don't think "more friendly" is a goal for Ada in any event.) Getting a fresh user base requires designing, adding, and implementing new and potentially exciting features, such as contracts were for Ada 2012. I can see big things like safe parallelism and safer access types making that grade. Syntax tweaks are down in the weeds -- people use C syntax all the time (and design new languages using it) after all, and it's full of problems. At least one of the comments here noted that there doesn't seem to be much of a case for a change in the AI. Perhaps if there was a stronger case for a change it would get more traction. > If we include those who provided feedback on the Github page the vote > would look very different as all 8 people who commented liked "end id > | end record". If you add my vote to it then that makes it 9 extra > votes in favor of that option - that is if Bob wasn't counted already. > > https://github.com/AdaCore/ada-spark-rfcs/pull/13 Bob is counted already, and I was hoping that most of the others in your original group were here as well. I definitely don't want to double count anyone. The discussion here is different in the sense that I asked to choose between 4 alternatives, and I'm not sure how meaningful mixing answers of different questions would be. In particular, I would want to know how invested each respondent is in making a change, as well as the particular change they favor if a change is made. As it stands, we have 22 responses here (counting you and Bob, and making the requested vote changes for several people), 36 points for Do Nothing, 12.5 points for "end record id", 8.5 pts for "end id". Even if we assume that all 7 other people would have voted exclusively for "end id", it would still only have 22.5 pts and there would still be a strong split between the choices and still the winning option by a wide margin is "do nothing". (And I would guess that some of those 7 people also would have given some points to "do nothing".) **************************************************************** From: Randy Brukardt Sent: Sunday, January 12, 2020 3:09 PM > > ... > > b) begin ... end; > > Don't forget "Toto: [declare ...] begin ... end Toto;" > > > c) procedure | function | package | package body | task | task body | > > protected | protected type | protected body Toto [...] is ... end [Toto]; > > d) if ... end if; case ... end case; loop ... end loop; > > Don't forget "Toto: [for ...] loop ... end loop Toto;" > > > e) return ... do ... end return; > > f) record ... end record; > > g select ... end select; > Right. I count 4 separate ending conventions here: (b), (a)+(c), (d), and (e)+(f)+(g). ... > I think we can decide to do > something (or not) and not fear that we are breaking some sort to Ada > "rule" here. ;-) But if we do something compatible, we're adding a fifth kind of ending (making (e) different from (f) and (g), we can't make it like (c) or (d) as that would incompatible). > From my perspective, it really > should be about readability, not about writability. Agreed. That applies to pretty much everything we do. **************************************************************** From: Randy Brukardt Sent: Sunday, January 12, 2020 3:24 PM > > So this looks like the definition of "lack of consensus"! > > And the definition of "bike shedding". ;-) Wikipedia suggests that this is more appropriately an instance of "Wadler's Law", which states that the bulk of discussion in programming language design centers on syntax rather than semantics. Here we *only* are discussing syntax with no semantic change involved. Certainly, our work over the years have shown this repeatedly; we've even had solid proposals sunk mainly because of dislike for the proposed syntax. P.S. And this message can be considered a form of bike-shedding itself. ;-) **************************************************************** From: Jeffrey R. Carter Sent: Sunday, January 12, 2020 3:32 PM > Readability seems to favor "end record id" (and argubly adding the > optional ability to say "end package id", "end procedure id", etc.). I > think I will change my vote to favor "end record id" over "end id", as > Christoph and Tucker have reconvinced me that it is better. After reading additional comments here since I presented mine, I, too, have changed my mind about my 2nd choice: I would like to change it to "end record [id]". My first choice remains to do nothing. **************************************************************** From: Gary Dismukes Sent: Monday, January 13, 2020 2:10 PM > If you haven't responded yet, feel free to do so. If enough additional > people respond, I'll update the spreadsheet before Wednesday's ARG meeting. Finally putting in my two cents: If we were to make a change here, my preference is still for the "end record [id]" syntax, as it has always been (and, to be clear, I'm against the syntax without "record"), based on readability and consistency concerns. Removing the "record" keyword would be reducing readability, in my opinion (taking away useful info). As a very minor side note, it would seem that we should also consider the "null record" case. Should that allow an optional identifier? Perhaps, though obviously there's no real need to give the identifier in that case, since the declaration is so short, but why disallow it if it were to be allowed with the normal form? In any case, I'm fine with doing nothing here, and that seems to be the way this issue is (strongly) trending. ****************************************************************