From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!cme-durer!leake From: leake@cme-durer.ARPA (Stephe Leake) Newsgroups: comp.lang.ada Subject: Re: Ada language revision Message-ID: <733@marvin.cme-durer.ARPA> Date: 17 Nov 88 15:34:54 GMT References: <44449@beno.seismo.CSS.GOV> <3563@hubcap.UUCP> Organization: National Bureau of Standards, Gaithersburg, MD In-reply-to: billwolf@hubcap.clemson.edu's message of 16 Nov 88 19:06:02 GMT List-Id: In reference to Stanley Allen's comments in message <8811141420.AA01652@ajpo.sei.cmu.edu>, I agree completely. However, he did not give adequate references for me to go out and buy the reading material he suggested, and I have the impression they are not available in my corner bookstore. It seems to me that this forum is an excelent place for us novices to propose changes, giving him and others more knowledgeble a chance to spread some education. So, I am responding to Wolfe's list of changes with my own opinions, and I hope others do the same. Note to future suggestors: please include the LRM section and paragraph when suggesting a change to a specific rule. In article <3563@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes: 1) The assignment operator should be available for overloading as part of an ADT specification... Hear Hear! Right on! (and other assorted agreeable noises) 2) Similarly, there is no provision for defining the DESTROY procedure over an abstract data type such that UNCHECKED_DEALLOCATION is required to invoke it... This needs clarification; what does a DESTROY procedure do that UNCHECKED_DEALLOCATION doesn't? 3) The rule that a limited private type cannot be a direct component of another limited private type should be repealed... What rule are you refering to? I have a Commented_IO package which defines a limited private FILE_TYPE, which includes as a component Text_IO.FILE_TYPE (also limited private). It compiles just fine. 4) It should be possible to overload generic packages with differing generic parameter structures.... This sounds good. Currently, a better work-around is to have two packages, both using a common lists sub-package. 5) The rule that functions must have only in parameters should be repealed.... I have often wanted to do this myself, but I usually (not always) find that a procedure ends up making more sense. In general, I find that the restrictions Ada imposes usually lead to better code. (See my personal gripes below for exceptions to this.) 6) Exceptions should be capable of being passed as parameters.... What's wrong with a small if statement? Personally, I would like to have an EXCEPTION_IO that would let me print the name of an exception. 7) Arrays should be initializable via named association... According to LRM 4.3.2 (3), they are. 8) Record types should have the attributes NUMBER_OF_FIELDS, FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).... This sounds good, but I suspect it would be difficult to handle [limited] private types and variant records. Does NUMBER_OF_FIELDS return the number for the current discriminant, or something else? You can't expect the compiler to do _everything_ for you! Here are a couple restrictions that I would like relaxed: 9) LRM 10.2 (5) states that the simple names of all subunits that have the same ancestor library unit must be distinct. This means I can have tasks named ROBOT.PLANNER.MAIN_TASK and ROBOT.TRAJECTORY.MAIN_TASK, but only if the task bodies are not separately compiled; then the simple name MAIN_TASK must be changed. This seems contrary to the intent of Ada naming. If the rule where changed to "the simple names of all subunits that have the same _parent_ unit must be distinct", things would be nicer. 10) LRM 4.3.2 (6) says if I have an array aggregate with named association and an others clause, it must be an actual parameter or function result; ie, _not_ an object initalization. This prevents me from declaring an object with an anonymous array type and initializing it; which is exactly the correct thing to do for a state table in a lexical analyzer. I do not want a named array type, since I do not want any other state tables; I only need one. 11) LRM 8.5 (2) lists the things that can be renamed. I would like to add enumerals. I like to rename some things from a package (usually with the same name) to make them visible, instead of "use"ing the whole package; this makes it clear I am _not_ using the whole package. Currently, to make an enumeral visible, I must declare a derived type, which means I have to use explicit type conversions. Well, that's probably enough for now. Stephe Leake (301) 975-3431 leake@cme.nbs.gov National Institute of Standards and Technology (formerly National Bureau of Standards) Rm. B-124, Bldg. 220 Gaithersburg, MD 20899