From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Subject: Re: Ada Language Change: Assignment Overloading
Date: 24 Nov 88 01:55:31 GMT [thread overview]
Message-ID: <3658@hubcap.UUCP> (raw)
In-Reply-To: 8811221935.AA21274@grebyn.com
From article <8811221935.AA21274@grebyn.com>, by karl@grebyn.com (Karl Nyberg):
> From: mendal@sierra.stanford.edu (Geoff Mendal)
>
> Consider the following compilation:
>
> with Text_Io;
> package P is
> X : Text_Io.File_Mode := Text_Io.In_File;
> end P;
>
> If assignment were to be overloadable, then it would not be allowed
> to be a basic operation. Therefore, assignment would not be made
> directly visible in the above package. One would need a use clause or
> a renaming declaration to achieve such direct visibility. Thus,
> making assignment an overloadable operation is NOT an upward compatible
> change. It would break virtually every program written, it would
> require changes to the scope and visibility rules, and would require
> little tweaks to the language such as in the semantics of renaming.
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.
> 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.
> This follows Ada's current semantics. But now through overloading
> assignment, we can make that very important assumption no longer true.
> Program provers could no longer rely on the semantics of simple
> assignment, thus significantly hindering the efforts to prove
> anything about a program.
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.
> And yes, what would be the semantics of overloaded assignment for
> task objects and predefined File_Type objects? Could it not be
> the case here that current semantics would be broken through clever
> use of overloading to assign limited objects?
The same argument applies in general to the overloadable relational
operators; a possible solution would be to require that operators,
if they are defined over a private or limited private type, must
be defined within the package specification in which the private
or limited private type is defined. This covers File_Type objects;
since task objects are woven directly into the language rather than
being included in a predefined package, there isn't even a package
specification into which an overloadable operator could be inserted.
> 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. The technology for these kinds of solutions are readily
> available. If you need such capability, pound on your local Ada
> APSE vendor for the tools. This is an APSE issue, not a language
> issue, you know.
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.
prev parent reply other threads:[~1988-11-24 1:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-11-22 19:35 Ada Language Change: Assignment Overloading Karl Nyberg
1988-11-23 12:36 ` Stephe Leake
1988-11-23 19:13 ` Ray Trent
1988-11-23 22:57 ` William Thomas Wolfe,2847,
1988-11-24 2:16 ` William Thomas Wolfe,2847,
1988-11-24 1:55 ` William Thomas Wolfe,2847, [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox