ISO/IEC JTC1/SC22/WG9 N422 WG9 Forum Session Notes 2002 SIGAda conference, December 12, 2002 There were two sessions: - ALIOOOP - IRONMASCC -------------------------------------------------------------------- Summary of ALIOOOP session Session leader: Tucker Taft Scribe: Martin Carlisle Attendance: 17 The session was organized as a discussion to provide feedback on several proposals to enhance the object-oriented features of Ada 95. 1. Object.Method notation Discussion: Some felt this was a "harmless" addition which served only an "advertising purpose". Others felt this made it easier to use Ada in combination with other OO languages (such as Java or C#), and also that this reduced a verbosity problem, and the pressure for use clauses. The current proposal requires the controlling parameter appear first to use object.method syntax. Some wondering about if people have the controlling parameter not first, but it seemed generally agreed that if they wanted to use the new syntax they could change. Important to retain support for old syntax-- some wanted pragma requiring use of old (or new) syntax, e.g. pragma Restriction (No_Method_Prefix_Notation);. In favor : 13 Opposed : 1 Neutral/no vote: 3 1b. Using Object.Method notation for classwide (non-dispatching methods). Can be done in Java, C++, not C# In favor : 1 Opposed : 2 Neutral/no vote: 14 1c. Using Object.Method for non-tagged composite types In favor : 0 Opposed : 5 Neutral/no vote: 12 It was noted that this has been implemented in GNAT (not 1b or 1c) with only 127 lines by Martin Carlisle, and Tucker Taft encouraged experimentation with implementations of the proposals. 2. Interfaces Discussion: As in C# or Java. Java uses some as boolean flags (e.g. Cloneable, Serializable), but Ada would use pragma or attribute. No plan for standardized interfaces, just the ability to create them. In favor : 15 Opposed : 0 Neutral/no vote: 2 3. Type stub type Employee is tagged separate in Workers; Discussion: To resolve problem of mutually dependent types in multiple package. Biggest problem is that there is nothing in the context clause. 5 participants felt it was important to have something appear in the context clause. The problem with GNAT's "with type" was mentioned, and had something to do with compiler implementation difficulties. 3a. Resolve circularity? In favor : 13 Opposed : 0 Neutral/no vote: 4 3b. If so, do we solve problem of many packages with same named type? E.g. type Class1_Typ is tagged separate Class1.Typ Unanimously in favor 4. Anonymous access types Discussion: When modeling a hierarchy, sometime have to cast up to the parent ptr. Should we provide a mechanism to remove type-casts for conversions that are guaranteed to be safe? In favor : 11 Opposed : 0 Neutral/no vote: 6 5. Make limited types less limited Discussion: Aggregate assignment is a good safety feature in Ada, as it ensures that all fields of a record are initialized. This can not be used with limited types. Should this be allowed for initialization only? (Must add <> [box] syntax for tasks and other things for which the "default" behavior is desired/required). In favor : 8 Opposed : 0 Neutral/no vote: 9 5b. Assuming aggregate assignment is allowed, should we allow functions to return limited types for initialization only? E.g. X : Limited_Type1 := Initialize(3,4); In favor : 6 Opposed : 0 Neutral/no vote: 11 6. Assertion pragmas Discussion: pragma Assert is not controversial. Should some sort of dynamic pre/post conditions be added? Yes: 5 -- allows run-time checks that are user specified No: 2 -- because a run-time thing, may require functions not otherwise used. Might standardize something that is immature? 7. Unintialized variables Discussion: Java does not allow local variables to be used before initialized. Should a pragma be added that requires initialization on all paths? (e.g. pragma Require_Initialization;). Closes a safety hole in Ada-- only enforced to the same degree as in Java In favor : 14 Opposed : 0 Neutral/no vote: 3 8. Modeling physical units Discussion: There was limited discussion of adding a compile-time feature for ensuring that units of mass,length,time were combined appropriately, as subtypes of the same type. Relative importance of proposals Proposal\Importance H M L Object.Method 8 4 3 Type stub 9 5 0 Interfaces 13 2 0 Anonymous access types 0 9 6 Limited types aggr. 0 8 4 Limited func ret* 5 4 4 Unintialized vars 11 3 0 *=only if limited types aggr is done -------------------------------------------------------------------- Summary of IRONMASCC session Session leader: Erhard Ploedereder Scribe: Ben Brosgol The session was organized as a general open discussion of several topics. 1. CPU accounting Per-task time is perennially a feature that users want/need; the issue seems more a question of how (rather than whether) it should be realized. A "magic" API is one approach, but a TCB attribute is perhaps more natural. Applications include user-defined scheduling and also enforcement of execution time budgets in Rate Monotonic Scheduling. 2. What to do about distribution There was a question of how time is managed in a distributed system. Having only one clock means a single point of failure; having many clocks means that they must be kept in synch. It was pointed out that in practice fault tolerance requires multiple clocks, and that the synchronization problem, though hard, is solvable. One user indicated that he preferred the Distribution Annex over CORBA since it seemed to give him lower-level facilities that he needed. The Distribution Annex seems not to be used heavily; one reason is that it models a distributed Ada program whereas in practice the need is for distributing mixed-language programs. Should the Distribution Annex be removed from the Standard? Probably not, although for nontechnical rather than technical reasons. There was a request to formalize an Ada interface to CORBA. Several users reported positive experience with Ada in tightly-coupled (shared-memory, multiprocessor) environments. It is interesting that so-called "memory model" issues (relating to optimizations in a tasking program) have not arisen in Ada, whereas they are attracting considerable discussion in Java. 3. What is desired in the area of safety and security A standardized set of restrictions and predefined profiles is needed. Indeed, that is the path being taken by the ARG. Perhaps more flexibly, having various user-selectable stylistic rules enforced by the compiler would be nice. An ASIS tool could presumably do the necessary analysis. An assertion facility is important. There are two kinds: a dynamic mechanism, which evaluates a Boolean expression and raises an exception if the expression is False, and a static mechanism, which involves quantification and predicate logic and which supports "design by contract". The dynamic model is much simpler to specify and implement than the static model. The current AI on the subject seems to be a mixture of the two approaches and is asserted to have some problems. It would be nice if the "physical units" problem had a reasonable (and compile-time) solution in Ada. Should Ada introduce a facility for requiring a subprogram to identify the exceptions that it can propagate? Aside from the compatibility problems, there are several issues with such a feature: * It was considered during the Ada 83 design but rejected on the grounds that most programmers would lazily specify "raise anything" rather than detail all the possible exceptions that might be propagated. * Java takes a compromise approach, distinguishing "checked" from "unchecked" exceptions, but it has some loopholes since e.g. via the intraspection facility a method may throw an arbitrary exception regardless of its "throws" clause. To support security requirements, it would be useful to have a mechanism (e.g. a pragma) that would zero out (or otherwise erase the contents of) the released memory when an object is deallocated or the stack is popped. 4. Miscellaneous One user indicated the desire for several features to support the qualified Ada subset compiler that was described in one of the papers: * Simple syntax for unchecked conversion The subset compiler does not have generics, and achieving the effect of an unchecked conversion (via address clauses) is claimed to be somewhat clumsy. An attribute would be a lighter-weight notation to achieve this sometimes-needed functionality. The opposing argument is that the heavyweight syntax is there by intent, in order to discourage its casual use and to make it clear (by the presence of a with clause identifying the potentially-unsafe feature) when it is being used. * Ability to mark a variable as "readonly" In many abstractions, hidden state is accessed by a query function. Although in principle the function overhead can be avoided by specifying pragma Inline, in practice there may still be some run-time penalty. The ability to specify that a client's view on a variable is readonly would solve this problem since there would be no need to define a query function. * Shift/rotate for unsigned types in general Although shift and rotate functions are provided for the unsigned types in package Interfaces, it would be useful if they were available more generally for user-defined unsigned types as well. The opposing argument is that such a facility might have a major impact on implementations, since no other type declaration introduces functions (other than operator symbols) for the new type.