Re: Reference Semantics, assignment

[ryer@inmet.UUCP]

/* 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 */