Collective response to := messages

[mendal@ANNA.STANFORD.EDU (Geoff Mendal)]

I will respond briefly to some of the replies made to my original
assignment overloading message.  Lines with ">>" are from my original
message, lines with ">" are responses to my original message.  I am a
bit shocked that some people apparantly agree with me... I'm not used
to that sort of thing.

>Date: 23 Nov 88 22:57:59 GMT
>From: hubcap!billwolf@gatech.edu  (William Thomas Wolfe,2847,)
>Subject: Ada Language Change: Assignment Overloading
>
>> 1. Why simply restrict it to assignment?  Why not include membership,
>>    short-circuit control forms, indexing, selection, attributes, etc.?
>>    These are all basic operations....
>
>   First, assignment is a "fundamental" operation; except for attributes,
>   the other things you've suggested apply only to specific classes of
>   ADTs.  As for attributes, I think we could live without them if 
>   appropriate procedures and functions were defined over the predefined
>   ADTs; having attributes for predefined ADTs and functions for user-defined
>   ADTs is another inconsistency.  Procedures and functions are definitely
>   necessary; the attribute mechanism is not.

Wrong.  Membership, qualification, attributes, and explicit type conversion
are all "fundamental" operations defined for EVERY type.  To argue that
assignment is special requires more justification than "we can live without
X and Y is necessary".  Who can live without X?  I can most certainly live
without assignment overloading.  Does this mean that overloading assignment
is a good/bad idea?  Nonsense.  Rethink your argument.

>   Another reason is that assignment procedures need to be invoked as part
>   of the evaluation of a user-defined ADT which is passed by value.  No
>   similarly vital function is performed by the other operations suggested.

I don't understand this at all.  You are assuming pass by value for an
ADT?  Rediculous.  The LRM only states that scalars and access values
are passed by copy.  In general, for an ADT, you cannot assume pass by
value and if your program depends on it, your program will execute
erroneously.  Justifying a language change based on a set of programs
which are known to execute erroneously it itself an erroneous argument.
If an "assignment procedure needs to be invoked as part of the evaluation
of a user-defined ADT" then one can explicitly write the Ada code
necessary for this.  Default components for records provide a simple
solution here.  There are other solutions as well.  None of the solutions
REQUIRE assignment to be overloaded.

>   The argument that the operations listed (except assignment and attributes)
>   should be user-programmable with respect to user-defined ADTs is reasonable,
>   but clearly assignment is in a higher class of importance than the others.

I strongly disagree.  Assignment is assignment.  A relational operator
is a relational operator.  Are we going to change the language by
taking a popular vote of which operations are "higher class" than
others?  Such justification for a language change is rediculous.  So
far, I have seen no justification why assignment should be overloaded
and not other basic operations.  Consider usability, readability,
understandibility, etc.  These should drive the justification, not
someone's arbitrary "higher class" argument.  My argument is that
while readability might be increased, understandability will be
diminished and therefore we should reject the notion that overloading
assignment is a good idea.  The designers of Ada went out of their way
to make typing Ada programs more difficult/time-consuming so that
understanding them would be easier.  Any language change should not
compromise understandability for the sole gain of making programs
easier to type.

>Date: 23 Nov 88 19:13:34 GMT
>From: trent@unix.sri.com  (Ray Trent)
>Subject: Ada Language Change: Assignment Overloading
[some verbage deleted]
>
>This standard argument against allowing the overloading of the ":="
>operator ignores the fact the programmers may want *semantics*
>in their type declarations instead of just syntax. Types are not 
>static objects that can be completely defined at compile time,
>however much the designers of Ada want to think they are.
[fraction example deleted]
>
>The Ada apolgists would have us write the semantics for ensuring
>LCD form for the type Fraction into *each and every operator*
>that acts upon 2 items of this type, instead of having that 
>functionality in the assignment operator, where it belongs. The point 
>is, readable or not, ":=" should validly ensure the *semantics* of
>every type it is defined for, as well as the pure syntactical elemants.
[more fraction examples deleted]

First, assignment is NOT an operator.  It is a basic operation.
Operators are completely different in that they follow different
scope/visbility rules and are afforded some luxeries (overloading)
not currently available to basic operations.  I tried to make this
point clear in my original message but it is obvious that still not
everyone understands the difference.  Read the LRM and be enlighted.

Now, of course programmers want semantics in their type declarations
and I believe that Ada provides some of these semantics through
predefined behavior of basic operations and operators.  But I disagree
that having the complete semantics for a type defined in an
"assignment operator" is appropriate or even desired.  Assignment
already has a very well defined semantics.  Read the LRM.  So what is
the problem?  You don't like those semantics and you would prefer to
alter them?  Fine, but I fail to see why ":=" has to be the syntagma which
carries your favorite semantics (which may not be my favorite
semantics).

One of the examples that I deleted above was "A := B / C;"
where A, B, and C were of some ADT (Fraction).  If I understand the
argument for placing the semantics in assignment instead of having the
programmer define the semantics in each user-defined operation, then
how would the semantics of passing the expression "B / C" to some
subprogram formal be handled?  There is no "assignment" here.  The
semantics have to be part of the division operation.  Perhaps you
are arguing that indeed "assignment semantics" should be a part of
EVERY operation.  This is a completely different language change,
far more involved than a "simple" overloading of "assignment".
Perhaps those who are involved with Ada formal definition projects
(DDC, etc.) can shed some light on what is involved here and if
such would be useful.

>The argument that pre-processors can be used to acheive this effect is
>bull. It ignores the absolute fact that *no one* maintains, reads, or
>is expected to understand the processed code. This is a null argument.

Quite the contrary.  The whole idea of a pre-processor or translation
tool is to remove the need to "read" the processed version.  How many
Ada programmers spend their time disassembling and reading the output
of their compilations?  A compiler is a translation tool.  The idea
being that Ada is more readable/understandable/etc. than assembly.  So
why is it that defining a mapping from some pre-processor to Ada is
met with such cynicism?  It simply provides an additional layer of
abstraction, which, the last time I looked, was thought to be a good
idea.

Those who are convinced that there is nothing above/beyond Ada should
continue to keep their blinders on so that they won't have to worry
about keeping up with computer science and software engineering.  If
others in our field had adopted this attitude, we'd still be
programming by wire wrapping and debugging with oscilloscopes.  (It is
a sad commentary that there are still Ada programmers out there who
still do not understand the need for and utility of an APSE.  You can
spot them right away... they're the ones who think that the only way
to improve/change things is by modifying the language.)

>Date: 24 Nov 88 01:55:31 GMT
>From: hp-sdd!ncr-sd!ncrcae!hubcap!billwolf@hplabs.hp.com  (William Thomas Wolfe,2847,)
>Subject: Ada Language Change: Assignment Overloading
>
>   Why can't an overloadable operation remain as a basic operation?
>
>   In order to preserve compatibility, the "old" interpretation of
>   assignment could be kept as the outermost interpretation (deepest
>   in the background), available as a default assignment procedure.

Yech!  The current language definition is clear and consistent.  A
basic operation (such as assignment) cannot be overloaded.
Overloading is defined only for subprograms, single entries,
operators, and enumeration literals.  My point was that if assignment
was to be overloaded, then it would most likely have to be
reclassified as an operator or a procedure.  Otherwise, this language
change would require much more work.  Having assignment as the only
basic operation which could be overloaded makes the semantics of
"assignment" more murky.  Overloading is complex enough without adding
a new special case to it.  And for what benefit?  I still haven't seen
a response that illustrates a useful case where overloading assignment
would do anything useful.  Does anyone have such a case?  Or is this
basically a theoretical argument whereby the impact of a language
change will not be understood until it has been made and programmers
start to experiment with it?

>>    Program provers might rely on the fact that if no exception is raised 
>>    during the "assignment", that the the value is assigned to the object.  
>
>   And what about the overloadable relational operators???
>
>   Program provers cannot now assume that "=" really means equality,
>   nor can they assume that some side effect will not occur during the
>   evaluation of an equality operator.  There is plenty of precedent here.
>   If we go ahead and overload assignment, the program prover will be able
>   to exercise one simple, consistent rule: "Assume nothing".  I think this
>   is an excellent mode of thought to force a program prover into.  

Well, not really.  Since "=" can only be overloaded by the user for
limited types, it is not a good example.  "*" is a better example.
But the point is that the current semantics of assignment do allow
program provers to make certain assumptions which make the job of
writing a program prover easier.  While it is certainly possible to
write a program prover which does not make use of the current
assignment semantics, it is far harder to do so.  The point being that
there exist applications of Ada out there which will suffer somewhat
from this proposed language change.  Whether this is a desired result
is debatable (do we really want to force the program proving folks to
go back and undertake a major redesign because a few programmers hate
to type ASSIGN?).

>> The proponents of overloading assignment have also overlooked other
>> less costly solutions such as pre-processors that would transform
>> "overloaded assignment" into Ada procedure calls, implementation-defined
>> pragmas, etc.
>
>    Wrong.  The ability to cleanly define abstract data types 
>    is very much a language issue.  Implementation-defined pragmas
>    would annihilate portability.  Preprocessors would have one hell
>    of a time implementing "If this procedure call involves passing
>    a user-defined ADT by value, then generate a temporary variable
>    of that type, invoke ASSIGN on that temporary (assuming we adhered
>    to the convention of using the name ASSIGN rather than, for example,
>    COPY or DUPLICATE), and pass the temporary instead, and remember 
>    to invoke DESTROY on the temporary afterward"...
>
>    There's no way around it.  Assignment needs to be overloadable.

I don't understand this argument at all.  Clearly one can write ASSIGN
procedures by hand to solve this sort of thing.  The only difference
is that ASSIGN (X, Y) has to be written instead of "infix" X := Y.
So why does assignment need to be overloaded?  And if one can write
the code with the intended semantics by hand, then why cannot an
advanced APSE tool do so?  Is your argument that the state of APSE
technology is not sufficient to solve the problem, and therefore we
have to solve it as a language problem?  This is again a silly argument
for making a language change and would prove my case that this is
indeed an APSE issue, not a language issue.

***********
Since overloading of assignment is not a very important issue, I'll
refrain from making any further comments about it.  I'll get back to
doing more important things... writing pre-processor tools for Ada.

gom