Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!inmet!ishmael!inmet!ada-uts!stt
From: stt@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messa
Message-ID: <57900084@ada-uts>
Date: 5 Dec 88 17:33:00 GMT
References: <10922@ulysses.homer.nj.att.com>
Lines: 33
Nf-ID: #R:ulysses.homer.nj.att.com:-1092200:ada-uts:57900084:000:1519
Nf-From: ada-uts!stt    Dec  5 12:33:00 1988


>  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