Re: Collective response to := messages

[dsr@hector.UUCP (David S. Rosenblum)]

In article <772@marvin.cme.nbs.gov> leake@cme.nbs.gov (Stephe Leake) writes:
>In article <10917@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:
>
>   As I argued in the case of assignment, overloading of type conversion is
>   overloading of a basic operation, and such a facility would allow
>   one to circumvent type checking.  As you suggested above, we don't want
>   to turn Ada into C.
>
>Type checking _cannot_ be circumvented by overloading of type
>conversion! Consider:
>
>type DEGREES is digits 6 range 0.0 .. 360.0;
>type RADIANS is digits 6;
>
>function DEGREES (Item : in RADIANS) return DEGREES
>is
>begin
>	return Item * 180.0 / PI;	-- range constraint is checked!
>end;
>
>Since the underlying Ada type checking is done on the function result,
>no circumvention of type checking is possible.

My comment did NOT have to do with checking the constraints of the
target type.  I hope anybody with a minimal familiarity with Ada knows
that type constraints are checked on function return values.  My point
was that overloading of type conversion will allow you to "covert" pointers
to integers, arrays to files, tasks to widgets, etc.  This is called "casting"
in C, better known as "anything goes".  To me such conversions are a
circumvention of Ada's strong typing model.

I'll try this just one more time.  By allowing the overloading of
basic operations, you may gain some flexibility in defining your
abstractions, but this gain will be achieved only at the (to me, unjustifiable)
cost of severely weakening Ada's strong typing strictures.  Any
proposal to increase flexibility in defining abstractions in Ada
MUST ("read my lips"--MUST) conform to the fundamental language philosophies
of Ada.

I would suggest two promising areas for making such improvements
in an "Ada-like" way.  (1) Allow user-specifiable initialization and
destruction routines for types.  Ray Trent and Bill Wolfe have been arguing
for a parameter passing semantics based on assignment.  Stroustrup, in his
C++ book, argues that you need initialization mechanisms, not assignment, for
parameter passing, and that initialization and assignment are
fundamentally different operations.  Initialization routines would
be appropriate for initializing parameters that are passed by copy, which
(at least for scalars) is the mandated parameter passing mechanism.
(2) Define a mechanism for allowing richer user-specified constraints
on types, e.g. "all objects of type EVEN must have even values", or "for
all objects of record type FOO, component BAR must always be greater than
component BAZ".  Then let Ada's inherent type checking mechanisms check
these constraints automatically.

In short, Ada has a very nice type checking framework.  We should try to
come up with proposals that improve that framework in ways that increases
its flexibility without decreasing its robustness; don't just propose tacking
on new language rules and band-aids that will cheaply rid you of your
frustrations with the current framework.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------