!section 02.08 (07) Ron Brender 89-06-05 83-01291 !version 1983 !topic The meaning of operators and identifiers in pragma arguments !reference AI-00010/07, AI-00509/02 I disagree with Mike's comment of 88-01-03, for reasons that are well articuled in my own comment of 88-01-19 that is associated with AI-00509. The key point is that there is no requirement that the argument of a pragma BE an expression, only that it have the FORM of an expression. The form requirement itself was adopted primarily to assure that an implementation could successfully parse any pragma, including an unknown one from some other implementation. Having satisfied that goal, there is no benefit in attempting to disallow a non-expression based interpretation for an argument of an implementation defined pragma. ***************************************************************************** !section 04.06 (15) Ron Brender 89-06-05 83-01293 !version 1983 !topic The number of implicit conversions !reference AI-00606/01 I support the conclusion of this AI. The "algorithm" presented in the IG always struck me as wrong from "day zero". This is reflected in the following comment on the IG submitted back in 1984: Section 08.07.a.07(S3-S12) Ron Brender 84-01-04 Version G1 Topic "more or less" implicit conversions The use of a count of the number of implicit conversions in the model given here seems ill-advised. The ARM certainly says nothing about "minimizing" the number of implicit conversions -- it only states conditions under which a particular implicit conversion is applied or not. Adopting a model that counts the number of implicit conversions invites concern about cases where there may be a choice of implicit conversions -- cases which can be shown to be just not possible (the argument is lengthly and will not be dealt with here). [Ed. In light of the question in this AI, perhaps the argument was too lengthly to be correct...] It appears that the appeal to a count is motivated solely by the examples involving **. But we know that the right operand of ** can never be of a universal type: the predefined ** operators all require INTEGER and any user-defined overloading of ** must have a non-universal type in its specification. It follows that in any syntactic occurance of the ** operator (whether infix or call notation) any implicit conversions that MIGHT be applied to satisfy the required type of the right operand in fact MUST be applied. Consequently, the presence (never absence) of an implicit conversion in the right operand cannot make any difference in the resolution of any larger complete context. Having disposed of the need to take account of implicit conversions in the right operand of **, there appears to be no need to have a count as such for the purposes of the remaining part of the model -- it suffices to replace the current use of the count with a simple bit indicating whether or not an interpretation involves any implicit conversion (other than in the right operand of **). I think everything else goes through without further difficulty. ***************************************************************************** !section 12.03 (00) 10.03 (05) Ron Brender 89-06-05 83-01292 !version 1983 !topic Instantiation before occurrence of a body !reference AI-00506/05, 83-01027 Tom Houser's comment 83-01027 raises an interesting fine point in the interpretation of AI-00506 (and AI-00408) but not one that requires any major rethinking. Successful compilation of package Q in example 2 by a compiler that does establish a dependence on a generic body requires that such a compiler, in effect, establish a dependence on the absense of a body for generic package J. When a body is subsequently compiled, one of two conclusions must be reached: 1. The body is legal, which causes units that contain instantiations to become obsolete, which causes the body to become obsolete... Of course, if the body is obsolete, then it can hardly have an effect on any other unit! 2. The body is not legal, because it violates an assumption about the body that was made in the specification. The second conclusion is infinitly more appealing on many grounds, but may appear to lack any foundation. However, the following related example is instructive: package PACK is generic type T is private; package GP is end; package NP is new GP(STRING); end; package body PACK is OBJ : T; end; Assume a compiler that does not establish a dependence on a generic body in carrying out an instantiation. In compiling the first unit, success requires, in effect, making an assumption that the body for GP (if any) does not use formal type T in a way that requires that T be constrained (because of the instantiation using STRING as the actual for T). When package body PACK is encountered, it must be rejected because it is inconsistent with this assumption. (Recall that AI-00256 requires that this assumption, needed to support a legality rule, must be checked during compilation because the body PACK does, of course, depend on its specification.) In particular, it is the body that is rejected -- not both the spec and the body. Returning to the original example as found in the AI, it is only a small step to recognise the assumption of no body as a kind of legality assumption -- no unit can both depend on a unit and not depend on a unit simultaneously! It follows that the package body Q should be rejected because it violates the assumption made in the spec. Further, it is clear that the compile-time check for such a violation is not novel -- it is just a minor variation on a kind of check that must be made in any case (as illustrated in the example above). Now turn to example 4 as discussed in 83-01027. It seems clear that package spec Q is quit legal, and so is instantiation I. The fact that a body has not yet been given (but must be) is not, of itself, definitive. A perfectly acceptable body can be given for Q that does not include a body for the generic J. In such a case, everything is fine and there is no basis for rejecting anything -- even by a compiler that establishes a dependency on the unit that contains a generic body. Finally, consider example 5 as discussed in 83-01027. In line with the dicussion for example 4, package spec Q and its body are clearly legal -- the presence of instantiation I between them is quite irrelevant to that legality. As argued earlier, instantiation I does NOT become obsolete as a result of compiling Q because Q does not provide a body for J and thus does not violate any assumption made in the compilation of I. ***************************************************************************** !section 13.02 (10) Ron Brender 89-06-05 83-01290 !version 1983 !topic Pragma PACK for an array type !reference AI-00555/04 While I do not (any longer) have a vote on the ARG, I am stimulated to pass along this note indicating that I would vote NO on this AI if I could. The AI seems to build logically on the principle of not requiring accesses that are "uncharacteristically complex" and then seems to arbitrarily discard this principle in the case of slices. Even if the correct conclusion is reached (which I here challenge), the justification is total nonsense. Working backwards, the final paragraph argues thus: Accessing slices can be expensive, THEREFORE, don't consider them. What kind of logic is that? If you don't think the accessing cost of slices is important, then say so and say why these costs are not as important as other kinds of accessing costs (like indexing). The cost of slicing, of course, results from the effect it has on subprogram calling sequences. Considering type A is array (POSITIVE) of ; pragma PACK(A); procedure PROC(P : A); The implementation issue is whether the representation of objects of type A are homogeneous with respect to slicing. If so, then the obvious call interface is appropropriate. If not, then there are generally two choices: (1) use a less efficient call interface that can handle arbitrary alignment of the parameters, or (2) use a call interface that favors the alignment of whole objects, and use copy-in/copy-out for slices that might not satisfy this alignment. The first generally makes all calls less efficient; the second generally makes calls that have slices as an actual parameter much less efficient than other calls. The "floor(K/N) components in every K bits" rule required by this AI forces a representation that is non-homogeneous with respect to slicing. Now, I expect everyone on the ARG understands this. But this certainly does not come through from the AI as written. I urge that the AI be reconsidered. If the current rule is kept, then, at the very least, the homogeneity issue discussed above should be more explicity recognised in the writeup and a real statement made as to why it should be ignored. *****************************************************************************