stt@ada-uts (12/06/88)
In LRM paragraph 11.6:6 -- ... For the evaluation of a predefined oepration, an implementation is allowed to use the operation of a type that has a range wider than that of the base type of the operands, provided this delivers the exact result (or a result within the declared accuracy, in the case of a real type), even if some intermediate results lie outside the range of the base type. S. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138
stt@ada-uts (12/06/88)
> However, overloading > of Ada's basic operations does not seem justifiable, because they are > intimately concerned with the implementation of strong typing. I don't agree with the validity of this argument. Replacing user-defined assignment with builtin assignment could never create a violation of strong typing, in the sense that an inappropriate value would be placed in a variable. If assigning one type to another is considered a "violation" then this could be disallowed by rules similar to those that applied to "=", namely that the base types of the parameters to user-defined assignment must be the same. In fact, given the rules associated with parameter passing, there is no way that the substitution of a user-defined operation for a builtin operation could violate "strong typing." If anything, the user-defined operation would be limited to more strict rules, because the intermediate results would not be allowed to violate range restrictions. I think the only "valid" argument against user-defined assignment is an aesthetic/philosophic one, namely that it will have different visibility rules from user-defined operators. In particular, a := b will NOT be strictly equivalent to ":="(a,b), but rather will be interpreted in a local scope including an implicit "use" of the package in which the operand type is defined. However, the very great advantage of providing user-defined assignment outweighs this aesthetic one in my opinion. S. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138
stt@inmet (12/07/88)
Here is another example of assignment leaving
uninitialized components:
type Rec is record
F : Positive;
G : Positive := 5;
end record;
X : Rec;
Y : Rec;
begin
Y := X;
In this example predefined assignment, the compiler is NOT required to
perform any constraint checks, and it is quite possible
that Y.F is < 0 after the indicated assignment.
It would be erroneous to use the value of Y.F, and it would
be erroneous to use Y as a whole as an operand to "=" or "/=",
but the assignment itself is not erroneous. (See LRM 3.2.1:18 for
discussion of erroneous use of uninitialized scalar subcomponents).
S. Tucker Taft
Intermetrics, Inc
Cambridge, MA 02138ron@inmet.UUCP (12/07/88)
Garbage collection certainly does not come for free, but it is extremely useful. It frees the programmer from the need to repeatedly write sophisticated ADT deallocate routines and to deal with the potentially massive book-keeping requirements for determining whether an object is in fact garbage. In general, lack of GC forces a programmer to invest a lot of effort addressing issues that are not fundamentally related to the problem domain. My experience has also shown that problems of "slow heap leakage" are among the hardest errors to correct. An earlier posting claimed that a programmer should know what is and isn't garbage, and that GC is therefore not needed. This argument would never be made by a programmer with experience writing serious applications using both GC'd and non-GC'd languages. It's quite possible that those without GC'd programming experience don't even recognize the additional burden for what it is. I am not saying that garbage collection should or shouldn't be added to Ada. I haven't really thought about all of the issues; there are clearly pros and cons. However, the argument against GC loses much of its credibility if it contains an outright denial of the many positive aspects of GC.
dsr@hector.UUCP (David S. Rosenblum) (12/09/88)
In article <124000022@inmet> stt@inmet writes: |Here is another example of assignment leaving |uninitialized components: | type Rec is record | F : Positive; | G : Positive := 5; | end record; | | X : Rec; | Y : Rec; |begin | Y := X; | |In this example predefined assignment, the compiler is NOT required to |perform any constraint checks, and it is quite possible |that Y.F is < 0 after the indicated assignment. |It would be erroneous to use the value of Y.F, and it would |be erroneous to use Y as a whole as an operand to "=" or "/=", |but the assignment itself is not erroneous. (See LRM 3.2.1:18 for |discussion of erroneous use of uninitialized scalar subcomponents). I don't have an LRM handy, but I believe that the compiler IS required to implement the constraint checks. But the constraint check performed by the generated code may fail, if it is unable to distinguish an undefined value from a correct value, or if undefined objects happen to be elaborated in a valid state. Thus, what is erroneous then is the reliance on a such a quirk of the implementation. Nevertheless, this example is hardly a justification for a further weakening of Ada's strong typing model. I don't feel any better knowing that I can avoid writing an un-erroneous program in this case if I never subsequently use the erroneously assigned object. Yes, Ada allows unchecked programming, Ada defines certain program constructions to be erroneous, Ada defines representation clauses, etc. These are red herrings in a discussion of proposals to improve Ada's abstraction mechanisms. Maybe I'm incredibly naive, but I would like to see language improvements discussed based on the assumption that we will adhere as best as possible to the spirit of Ada's fundamental language philosophies. ------------------------------------------------------------------- David Rosenblum UUCP: {ucbvax, decvax}!ulysses!dsr AT&T Bell Laboratories ARPA: dsr@ulysses.att.com 600 Mountain Ave. dsr%ulysses@att.arpa Murray Hill, NJ 07974-2070 (201) 582-2906 -------------------------------------------------------------------