Re: Collective response to := messages

[trent@unix.SRI.COM (Ray Trent)]

In an article mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes:
>>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 
>
>First, assignment is NOT an operator.  It is a basic operation.

The argument is that it should be. (and is, in any sensible 
(i.e. non-Ada) definition of the word operator) That there is no
reason to have "basic" operators that are "special".

>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

Fine, perhaps a better example is assigning to an object that should 
be garbage-collected before assignment. (always, or the program 
will be erroneous (not in the Ada sense)) Which makes more sense, 
putting garbage collection in assignment, or assuming the programmer 
will always call a garbage collector while assigning? Even if
the programmer is a code maintainer, and not the designer?

If you are wondering why I chose my original example, consider
A := (B / C * D) + ... + (Q / (3/4)). (all variables are of type fraction,
and an appropriate "/"(A,B : INTEGER) is defined) Do you still want
LCD maintainance in the arithmetic operations? Of course, you could 
always force A := LCD(foo). What if someone wants to modify the program? 
Aren't they going to wonder/forget about this? If you are worried
about passing the expression B / C as a parameter, my answer is: 
if you have a procedure where LCDness is necessary for proving something,
you can *always* simply make "in" parameters "in out" parameters. This 
*ensures* that an input variable will be in LCD form. (if assignment is
overloadable and is overloaded as suggested) "Requiring" a A := LCD(B/C)
does not ensure the validity of something passed to a sub-program.

If assignment were overloadable, the writer of an Ada spec for
operations involving fractions could be *sure* of always having something
in LCD form when passed to a subprogram by overloading ":=" and passing
all variables as "in out" parameters. The only other way to do this
is force *all* subprograms to perform LCDing on their outputs (or inputs)
whether that condition is necessary or not. This would make the operation
A := <very complicated expression with *many* arithmetic operations>
extremely slow (potentially). The LRM explicitly says that intermediate
results need not follow the constraints of the ADT. 

>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

Because it is used to justify inconsistent language constructs. If 
I had a nickel for every time someone said, "you don't need to 
change the language, just use a pre-processor" I'd drown in them.
Point one: any such preprocessor needs to be standardized to the
level that the language is, or it defeats the purpose of the language.
Point two: If such a preprocessor *is* in fact standarized to the level that 
the language is, there is no discernable difference between changing
the language and adding a preprocessor. Point three: the argument is that 
assignment should not be overloadable because it is not understandable
(though more readable). It makes no real difference whether you put
assignment overloading into a pre-processor or into the language. 
The pre-processing source is what will be maintained and used. 
It is identically as understandable if the language is changed as
it is if a processing step is added. Perhaps more so. If the language
is changed, no one will *assume* that assignment cannot be overloaded.
Tacking on a preprocessor is the coward's way out.

>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

It's needed because the language was designed in an inconsistant and 
inflexible manner in the first place. What would you say about a 
preprocessor that converts C into Ada. Is programming in C then
as good as programming in Ada? (don't laugh, it can be done, especially
if you use unchecked programming) I don't think so.

Another change I'd like to see. (upward compatible this time) Allow:

  if A in B | C | D | Q | Y | N then
    ...
  end if;

I.e. an extension of the membership idea. It's ridiculous to me that

  case A is 
    when B | C => ...
  end case;

is valid but the above (or some equivilent) is not. I argue that such
a construct is both more readable and more understandable than
 
  if A = B or A = C or else ... or else A = N then
    ...
  end if;

and also makes the Ada language more internally consistent. (and thus
easier to use) I also argue that compiler vendors are likely to 
implement the former more efficiently than the latter. This is especially
true when the comparands are of a large enumerated type. (hashing, and all)

Anyway, enough diatribe for today.
-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..