!section 03.05.04 (07) Ron Brender 90-06-04 83-01372 !version 1983 !topic Unsigned integer !references AI-00579/02 etc On page 3, insert something like "entities within" before "TEXT_IO for such a file", which ends the first full paragraph on page 3. TEXT_IO itself is not a generic unit. The second full paragraph is much too vague and weak. It reads like: just for the fun of it, the ARG has stuck in some random thoughts on how an unsigned integer type might be defined. Instead, the tone should be much more of a strong recommendation that if an implementation does provide unsigned integer type, it's properties should be precisely what follows. (I know this is "merely" a permisive AI and can't force these and only these properties -- but there should be no doubt that that is what is intended.) The paragraph beginning "3.5(7-9) says" and ending "have the FIRST and LAST attributes" belongs somewhere near the middle of page 2. On page 4 (line 7 et al) , it probably is overkill, but if you want to be really fussy, the correct statement is T'POS(X+Y) = ... T'POS(X-Y) = ... For the final paragraph (on page 5), the alternative suggesting nonstatic universal expressions must be supported even in the unsigned integer range seems definitely a mistake. This would seem to require some kind of runtime bookkeeping as to whether a value is signed or unsigned in order to correctly range check the inevitable consuming use (and type conversion). Such run-time type variability has no precedent in Ada -- and no obvious important benefit either. Finally, if you are going to provide modular types (which I do not oppose), it is unfortunate that the base types are limited to powers of two (or their ones complement equivalent). For example, a 60 second cyclic counter cannot be conveniently declared. This at least desires to be made explicit. ***************************************************************************** !section 10.03 (05) Hans Hurvig 90-01-09 83-01369 !version 1983 !topic Generic units that do not require a body !reference AI-00506/05 AI-00506 deals with the case where a generic unit requires a body, but does not directly address the questions raised in the appendix by BiiN and TeleSoft, concerning the case where a body is not required. An even simpler case is: package Q is generic package J is end J; end Q; Neither J nor Q require a body, so presumably there should be no problems with instantiating J right away: with Q; package IJ is new Q.J; However, it is impossible, within the usual framework of depen- dencies among compilation units, to record the fact that IJ was created without the presense of a body for J, in a way that keeps IJ valid if a body for Q, but not J, is compiled: package body Q is -- No body for J end Q; Apart from the dependency on library unit Q, IJ can depend on no other unit except possibly the implicit body for Q. And this dependency is indeed necessary, since otherwise IJ would stay valid after any body for Q was compiled. But since any explicit body for Q will render the implicit body obsolete, this also obsoletes IJ, whether or not body Q contains a body for J. Is this the intention, or must the dependency mechanism be extended to, say, record the dependency on a future unit body NOT containing a body for a nested unit? A further note on implicit bodies: if the explicit body Q becomes obsolete, presumably a fresh implicit body for Q becomes available. Does this affect anything? The next bit may be Ada-9X material, but here goes anyway: It would be a big improvement to require all packages to have a body, as is the case for the remaining program units, subprograms and tasks. The advantages include: Simplicity. Too many rules have had to be amended with the notion of an implicit empty body, for activating tasks, etc. The above case with generic dependencies is just one more example where special attention is required. Safety. There is the nasty case where code in a non-required body initializes variables in the visible part, but where obsoletion of the body does not stop the program from being legal; it just becomes erroneous. Readability. It is good documentation to give an explicit empty body. If it is left out, the reader cannot feel sure that he hasn't simply overlooked it. All these benefits, and all you have to do is write: package body P is end P; ***************************************************************************** !section 10.03 (05) Hans Hurvig 90-01-09 83-01370 !version 1983 !topic Avoiding recompilation after small changes !reference EA3003B0-3 ACVC 1.11 tests EA3003B0-3 seem to imply that just adding a declaration to a package cannot possibly affect previous users of the package. This is incorrect: package P is type A is new INTEGER; end P; with P; package Q is package R is type B is new FLOAT; end R; use P,R; -- make P.A and R.B directly visible X: B; end Q; package P is type A is new INTEGER; procedure B; -- just adding another declaration end P; Even though no B could be denoted in the original package P, the effect of the use-clause in Q nevertheless relies on the fact that there is no B in P, overloadable or not. But even if there had been no change to P at all, there is no justification in the RM for not requiring the recompilation of dependent units (Q) when a unit (P) is recompiled. All 10.3(5) notes is that the compiler might be able to short-cut the compilation process once it has established that no significant change has taken place. But the dependent units must stay obsolete until they are re-submitted to the compiler. Are such relaxations of the rules permissible? I, for one, would welcome it, relying instead on a more general rule: Any program that reaches execution must come from a set of mutually consistent, complete, and legal source files. It is up to the programming environment to enforce this somehow, possibly with aid of a program library. And it is quite possible (and sometimes desirable) to by-pass the program library all-together and make a system that is based directly on the available source-files, with the necessary version-information in the object-files, checked by the linker. Symbol-table information can be obtained by pseudo-compiling library units from source when needed (like include files). ***************************************************************************** !section 14.01 (00) Ron Brender 90-06-04 83-01373 !version 1983 !topic File objects passed by value versus reference !references AI-00828/01, see also AI-00302 My immediate reaction was to agree with this AI that, of course, file objects need not be passed by reference. However, there are some unpleasant consequences. In particular, synchronization across tasks that "share" a file variable may well need to be explicit in the user application, rather than relying on the atomicness of the I/O primatives. Further, any code that uses I/O libraries may well be erroneous without any obvious warning even with proper synchronization if anywhere in the program an actual/formal parameter association happens to be outstanding at the time of some other use of a file object -- indeed, any passing of a file object as a parameter in a program with tasks becomes a suspect practice. Seems like it would be much friendlier to conclude that file objects *are* effectively passed by value. (The "problem" of a null access value mentioned in the text can be solved by the I/O subsystem keeping a redundant tombstone marker...). ***************************************************************************** !section 14.01 (00) Dan Stock 90-06-07 83-01374 !version 1983 !topic Comment on version 02 I have some difficulty with classifying this AI as a ramification. I agree with the essence: TEXT_IO should be reentrant. But the argument used in the resonse to justify this on the basis of the LRM is dubious. Chapter 14, unlike most other sections, defines its effect in terms of a separately-implementable Ada package. Such Ada packages generally do not provide reentrancy. In fact, if reentrancy is desired, it is generally specifically mentioned in a package's specification documents. By classifying this AI as a ramification, the ARG would gloss over this important point, setting a poor example for those who write specification documents for packages. ("What do you mean, it's not reentrant? Of course I wanted it to be reentrant. I didn't have to say so. The ARG practically said as much in AI-591/02 ...") This AI should probably be extended to other predefined packages, such as CALENDAR and LOW_LEVEL_IO. Otherwise, an implementor could conceivably do something silly like using an unprotected global variable for speed on some architectures. One also might want to discuss the effect of abort. It may be worth explicitly mentioning that aborting a task that is currently executing within TEXT_IO (or whatever) will not affect other uses of the package. This could be important because it may affect some implementation techniques (such as using a global variable for speed or other reasons, but having a semaphore to protect it -- the semaphore might need to be reset if a task is aborted). dan ***************************************************************************** !section 14.03.02 (01) Ron Brender 90-06-04 83-01371 !version 1983 !topic CREATE is like OPEN wrt default files !references AI-00048, AI-00546/03 The comment by Cohen of 90-05-15 concerning AI-546 really applies to AI-48, I think. Further, the observations offered were considered during the discussions on AI-48 (I wish they had been more persuavive at the time, but they were considered). In the absence of reconsidering AI-48 (I do NOT recommend any reconsideration) this AI seems right on as is. *****************************************************************************