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 autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!cca!mirror!ishmael!inmet!stt From: stt@inmet.UUCP Newsgroups: comp.lang.ada Subject: Ada '88 Proposals Message-ID: <124000004@inmet> Date: Fri, 10-Jul-87 18:22:00 EDT Article-I.D.: inmet.124000004 Posted: Fri Jul 10 18:22:00 1987 Date-Received: Thu, 16-Jul-87 05:56:59 EDT Nf-ID: #N:inmet:124000004:000:4900 Nf-From: inmet.UUCP!stt Jul 10 18:22:00 1987 List-Id: Here are various proposals for Ada '88 being submitted to the Ada Language Issues Working Group. I am presuming that no proposed change should make existing legal programs illegal, though clearly they should make existing illegal programs legal (or else what's the point?). Furthermore, most of the things I am proposing represent relaxing arbitrary language restrictions which can already be circumvented, but only by circuitous nonintuitive methods, and hence don't significantly "relax" the strictures of the language. Tucker Taft c/o Intermetrics, Inc. Cambridge, MA 02138 stt@INMET.INMET.COM; ...{ihnp4,harvard}!inmet!stt 1) The full definition of a private or incomplete type with discriminants should be allowed to be a derived type, providing that the parent type has discriminants with conforming names, types, and defaults. An approximate equivalence can be accomplished now by having the full definition be a record enclosing the desired parent type as the single non-discriminant component, though this almost certainly introduces significant additional overhead and complexity. 2) Initialized constants of limited type should be legal. Since limited type subprogram IN parameters may have defaults, this is equivalent to declaring a subprogram with a single parameter with the initial value as the specified default, and then calling it providing no explicit parameter. To be consistent, a generic object IN parameter of limited type should also be legal. 3) Conversion should be considered static when the value is discrete and static, and the target subtype is discrete and static. This can be accomplished currently by using the circuitous route of a qualified expression above a "'POS" attribute call. 4) There should be some way to explicitly allow or disallow actual generic types being unconstrained in the generic spec. A proposed syntax would be: type A(<>) is private; -- Unconstrained allowed type A() is private; -- Unconstrained disallowed 5) The "=" operator should be definable on any type, so long as the result type is Standard.Boolean (so "/=" is well defined). It is currently possible to accomplish the same thing by a clever use of generics and renaming. The original rationale for disallowing the hiding of pre-defined "=" by a user-defined operator is probably that when used as a component the predefined "=" is used for the enclosing object. However, there is good precedent that predefined operators reemerge in certain circumstances, such as the definition of membership, without precluding their explicit hiding. 6) The LRM should specify the default rep for enumeration types in the absence of a representation clause. Otherwise, every enum type which is to have the "conventional" rep (where the value = the 'POS) will need a rep clause if it is ever to be written out in binary form to the external environment. Similarly, the default rep for integer types should be specified as being unbiased (where the value = the 'POS). Furthermore, the LRM should specify the layout of arrays indexed by enumeration types with representation clauses. I.e., if the enumeration rep has gaps, should the array have gaps or should its elements be contiguous? 7) Change the semantics of exception declaration to improve the feasiblity of sharing code between generic instantiations. Currently a new exception is created for each instantiation at compile-time, but not for each elaboration at run-time. This is the worst possible approach when trying to share code. The current situation means that even though all of the code may be shared between two instantiations, exceptions declared anywhere within the generic body must somehow be exported out to unshared code (within the instantiator presumably) and then have their "address" passed back into the instantiation as an implicit generic parameter. Either exceptions should be created only by explicit declarations in their original code (whether generic or non-generic), or should be created at each elaboration. I personally favor the latter since it is consistent with all other entities, including types, program units, and objects. What this would mean is that an exception declared within a subprogram would be unique to the particular subprogram execution. Since the declaration is only visible to itself, and its nested units, the only time it would matter is when the exception is propagated to a recursive call made from itself or some nested unit, which is of limited value anyway. It is always possible to move the exception definition out a level if there is any real need for handling local exceptions in recursive calls. I would venture to say this would not affect any existing code. Without this change, the correct implementation of generic sharing will be significantly more complicated, and less likely to be supported in most Ada compilers any time soon.