ryer@inmet.UUCP (12/09/88)
/* Written 8:07 pm Dec 6, 1988 by trent@sri-unix.UUCP in inmet:comp.lang.ada */ /* ---------- "Re: Reference Semantics, assignment" ---------- */ In the above article stachour@umn-cs.cs.umn.edu (Paul Stachour) writes: >In article <3739@hubcap.UUCP> billwolf@hubcap.clemson.edu writes: >> OK, we're sold on the benefits of reference semantics. Let's assume >> that "in out" parameters are always passed by reference. Now why Actually, :-), LRM 6.2(7, last sentence) states that such an assumption is either irrelevant or makes the program erroneous. :-) >> should it be impossible for the programmer to choose pass-by-value, >> as in "in" and "out" modes? Actually, I'd like the programmer to be always able to specify the method used. (as s/he is likely to know better than the compiler which is more efficient in some circumstances) BTW, check the phrasing of LRM 6.2(especially 7&11). It implies to me that pass by reference is only allowed for arrays, records and task types (and only at the discretion of the compiler vender). Any comments on this? I base my statement on LRM 6.2(7): (emphasis mine) "[Arrays, records and tasks may be passed by copy], *as for scalar types*. [...] Alternatively, an implementation may acheive these effects by reference...". This wording, combined with the qualification "For parameters of array and record types" in LRM 6.2(11), leads me to believe that pass-by-reference is verboten for scalar variables. If this was not the intent, I would suggest a rewording. But that aside, I wanted to mention something related to the assignment overloading discussion. To wit, many people have pointed out that source level assignment semantics are not used in parameter passing. I disagree. First, there are no source level assignment semantics, as writing an ":=" is not allowed. :-) Assignment semantics are defined only at the language level in Ada. Second, given this, I would argue that even if assignment semantics are not explicitly called by parameter passing, the effects of Ada parameter passing are indistinguishable from Ada assignment. In an assignment, a value is copied to the variable and subtype checked. In "in" or "in out" parameter passing, a value is copied and subtype checked. The effect is exactly as though the programmer had typed "<FormalParam> := <ActualParam>" (followed at return by "<ActualParam> := <FormalParam>" for "in out"s). For "out" parameters, an ":=" must have been called explicitly. Since they are equivilent, and since ":=" is not overloadable, I'm not surprised the LRM didn't state this explicitly...it would be redundant. The arguments that assignment should be overloadable seem to revolve around the complaint (the valid complaint) that Ada type semantics are inadequate. I.e. that the idea of type constraints needs expanding. (to include user defined constraint checks, which *could* be implemented as overloaded assignment) Overloading assignment *would* require that the overloaded assignment be used in parameter passing, but that is not a significant departure from the current parameter passing scheme...only from the current assignment scheme. Now, of course, the problem with this is that the programmer might "override" type checking with hir assignment operation. I would claim that writing an assignment operation is the same as providing an expanded ADT for the type. If the programmer writes an assignment operator, s/he is *defining* a new semantics for the type. Of course, this makes proving correctness harder. *Of course*. So does tasking, so does unchecked programming, so do generics, so do many other useful things. Now, admittedly, it might be better to allow user-defined constraint checks for ADTs than to allow overloaded assignment. I suspect that there would be even more complaints about this suggestion than about assignment overloading. (one reason for this is that it would require a whole new syntax) Of course, doing it this way would require that type checking be allowed to modify the result and not raise a constraint error if it felt like it...get's pretty evil, huh? In many ways, asking for overloaded assignment is a kludge. It doesn't really solve the problems with Ada type semantics, it just provides a workaround. -- "Our little lives get complicated It's a simple thing Simple as a flower And that's a complicated thing" ../ray\.. /* End of text from inmet:comp.lang.ada */