comp.lang.ada
 help / color / mirror / Atom feed
From: dsr@hector.UUCP (David S. Rosenblum)
Subject: Re: Collective response to := messages
Date: 30 Nov 88 22:28:37 GMT	[thread overview]
Message-ID: <10913@ulysses.homer.nj.att.com> (raw)
In-Reply-To: 3698@hubcap.UUCP

In article <3698@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>From article <10906@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
>> In
>> particular, by allowing overloading of assignment, it would be possible to
>> override one of the fundamental steps of the assignment operation, which is to
>> guarantee that the target variable in an assignment statement is assigned a
>> legal value of its type.  
>
>     Since the overloaded assignment would be implemented in terms of
>     the existing low-level assignment operations, I don't see where any 
>     potential problem exists here.  Please clarify.

Essentially, the problems arise from the characteristics of Ada's parameter passing semantics.
(Or we could change those too while we're at it. :-) )  Suppose ":=" overloadings are required
to have an out-mode parameter to represent the target variable.  Then an overloaded ":="
on a composite type can selectively assign to some components of the target and
leave other components undefined (if they were undefined prior to execution of the assignment).
This cannot happen with predefined assignment to objects of a composite type (i.e., when a full
composite object, not just a component of one, is given as the left-hand side).  Alternatively,
suppose ":=" overloadings are required to have an in out-mode parameter to represent the target
variable.  Then it would be impossible to assign to an undefined variable, because the
variable would first be constraint-checked when it is passed in to the assignment procedure.

For example,

procedure CIRCUMVENT is

    type LCD_FORM is
	record
	    NUMERATOR, DENOMINATOR : INTEGER;
	end record;

    X, Y : LCD_FORM;	-- X and Y undefined.

    procedure ":=" (L : out LCD_FORM; R : in FLOAT) is
    begin
	if R = 0.0 then
	    L.NUMERATOR := 0;
	else
	    -- calculate LCD form.
	end if;
    end ":=";

begin
    X := 1.5;
    -- X.NUMERATOR is presumably 3, X.DENOMINATOR is presumably 2.

    -- Y.DENOMINATOR is undefined.
    Y := 0.0;
    -- Y.DENOMINATOR is STILL undefined.
end CIRCUMVENT;

You can object that I didn't define ":=" "correctly" and that I stupidly failed to assign to
DENOMINATOR when R is zero, but that's the whole point--I've circumvented the type checking
that is inherent in predefined assignment.

> 
>> As I understand your LCD example, you seem to see assignment overloading
>> as a vehicle for implementing type constraints that can't be expressed in
>> Ada's constraint language (such as LCD-ness).  
>> [...] 
>> Yet after all these exertions, my evenness constraint would STILL not
>> be enforced consistently, unless I was given several more language changes.
>> For example, type conversions, qualifications, attribute evaluations and
>> membership tests never propagate exceptions.  Yet what would be the effect
>> of the type conversion "EVEN(3)"?  What would be the effect of the attribute
>> evaluation "EVEN'POS(3)"?  What would be the effect of the tests
>> "2 in 0 .. 3" or "3 in 0 .. 10" ?  Should they raise CONSTRAINT_ERROR, or
>> should they round 3 to some even value?  
>
>    The problems mentioned pertain specifically to this implementation
>    only; if EVEN were implemented as a limited private type within an
>    appropriate package, all the operations mentioned would be available 
>    only through the procedures/functions provided.  Type conversions
>    would not be legally expressible in the usual notation, most attributes
>    would not be defined, etc.  Ada 83 allows us to do all of these things,
>    but not in the "conventional" notation.  

That's the whole point of why you don't need assignment overloading!!!  You can also do assignment
with limited private types, but not in the "conventional" notation.  All you need to do is provide
an "appropriate subprogram".

>
>    Since Ada does not allow implicit type conversions, the fact that we
>    cannot overload type conversion does not cause us any grief in the
>    parameter-passing process.  Nor do any of the other operations mentioned.

You seem to be missing my point.  You are trying to use an overloaded assignment operator
to implement a constraint on your LCD type that can't be expressed in Ada's constraint language.
I've argued that I would want the ability to overload the other basic operations so that
I could implement in a consistent manner the constraints that I may dream up.  You've ignored that
argument and instead still seem to be harboring the belief that assignment is "different" from
the other basic operations.  What is so unique about assignment that it alone of all the basic
operations requires special treatment?

>
>    Only assignment and destruction play vital roles in the evaluation of
>    parameters and in the creation and destruction of variables (particularly
>    with regard to block entry and exit).  It is the fact that the language
>    does not consider the impact of these mechanisms upon the ADT paradigm,
>    mechanisms which can play havoc with our abstractions, that compels us 
>    to call for changes in the language with regard to the ability to
>    define specific procedures for assignment and destruction which are 
>    taken into consideration by these mechanisms. 

We can argue about implicitly invoked destruction mechanisms some other time, since Ada provides no
such animal.  And Ada's parameter passing mechanisms are defined implicitly, beyond the reach
of the programmer, as they should be (again to enforce type checking)--they have nothing
to do with assignment at the source level.  Regarding your assignment "abstraction", all
I can offer is the suggestion that reduction to LCD form is an over-specification of what I
consider to be the normal semantics of an assignment operation, and it is better left to
another procedure whose sole purpose is to perform the reduction.  If you define your
LCD type as a limited type in a package, you can provide a NORMALIZE procedure which
will achieve the desired effect.  If you need to add new code later, your only
recourse will be to use the NORMALIZE procedure, as there is no predefined assignment operation
available to confuse you.

>    It is entirely possible that given the desire of AJPO to minimize the
>    extent of changes in the language, it will not be possible to get Ada
>    to provide complete support for the abstract data type paradigm.  Ada
>    was explicitly intended as an interim solution, covering the range
>    1983..20xx, and not as "the perfect language".  Perhaps for Ada it is
>    already too late.  But the issue needs to be thoroughly discussed,
>    because it is a major area in which Ada has "missed the boat". 

I tend to agree with your last comment.  But Ada's abstraction mechanisms will never
be improved in the next revision without a proposal that is carefully thought out and
is fully consistent with the goals of the language.  As I've tried to illustrate, none
of the proposals I've seen for assignment overloading come close to meeting these criteria.

-------------------------------------------------------------------
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
-------------------------------------------------------------------

  reply	other threads:[~1988-11-30 22:28 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1988-11-28 22:19 Collective response to := messages Geoff Mendal
1988-11-29 14:39 ` Dennis Doubleday
1988-11-29 21:08 ` Ray Trent
1988-11-30 14:37   ` Stephe Leake
1988-12-01 14:54     ` David S. Rosenblum
1988-12-02 20:21       ` William Thomas Wolfe,2847,
1988-12-04 21:15         ` David S. Rosenblum
1988-12-04 23:27           ` William Thomas Wolfe,2847,
1988-12-05 14:46             ` David S. Rosenblum
1988-12-05 21:23               ` William Thomas Wolfe,2847,
1988-12-07 17:33                 ` Stephe Leake
1988-12-07 16:03               ` Definition of pass by reference Robert Eachus
1988-12-07 17:15             ` Collective response to := messages Stephe Leake
1988-12-07 16:07       ` Stephe Leake
1988-12-09  3:15         ` David S. Rosenblum
1988-12-01 21:31     ` Ray Trent
1988-12-07 16:21       ` Stephe Leake
1988-11-30 16:29   ` David S. Rosenblum
1988-11-30 18:29     ` William Thomas Wolfe,2847,
1988-11-30 22:28       ` David S. Rosenblum [this message]
1988-12-01  3:09         ` William Thomas Wolfe,2847,
1988-12-01 15:16           ` David S. Rosenblum
1988-12-02 19:31             ` William Thomas Wolfe,2847,
1988-12-04 21:03               ` David S. Rosenblum
1988-12-05  2:34                 ` William Thomas Wolfe,2847,
1988-12-05 14:07                   ` David S. Rosenblum
1988-12-07 17:26                     ` Stephe Leake
1988-12-06 19:16                 ` Collective response to := messa stt
1988-12-09  3:39                   ` David S. Rosenblum
1988-11-30 19:13     ` CORRECTION Re: Collective response to := messages David S. Rosenblum
1988-12-01 18:31     ` Ray Trent
1988-12-02 14:49       ` David S. Rosenblum
1988-12-05 17:33         ` Collective response to := messa stt
1988-11-30 18:24   ` Collective response to := messages Robert Eachus
1988-12-02 14:58     ` David S. Rosenblum
1988-12-02 19:34   ` Mark C. Adolph
1988-12-05 17:15     ` Collective response to := messa stt
1988-11-29 21:44 ` Collective response to := messages William Thomas Wolfe,2847,
  -- strict thread matches above, loose matches on Subject: below --
1989-07-26 20:34 Memory Access Question tony
1989-07-27 13:06 ` richard a hammond
1989-07-27 18:53   ` Ray Trent
1989-07-28  0:48     ` Mike Murphy
1989-08-02 13:23       ` Mike Walsh
1989-08-02 20:20         ` Mike Murphy
1989-07-29  0:00 ` Brian Sullivan
1988-12-05  6:53 Collective response to := messages Erland Sommarskog
1988-12-03 22:53 Erland Sommarskog
1988-12-04 20:41 ` William Thomas Wolfe,2847,
1988-12-05  5:47   ` Richard A. O'Keefe
1988-12-05 12:45     ` William Thomas Wolfe,2847,
1988-12-06  1:54       ` Richard A. O'Keefe
1988-12-06 20:43         ` William Thomas Wolfe,2847,
1988-12-03 21:08 Erland Sommarskog
1988-12-04 20:30 ` William Thomas Wolfe,2847,
1988-11-14 13:20 Ada language revision Stanley Roger Allen, AdaDude
1988-11-15 23:28 ` Wilmer Rivers
1988-11-16 19:06   ` William Thomas Wolfe,2847,
1988-11-17 15:34     ` Stephe Leake
1988-11-18 16:39       ` Steve Tynor
1988-11-18 19:22       ` Ron Guilmette
1988-11-23 22:22       ` William Thomas Wolfe,2847,
1988-11-29 15:35         ` Stephe Leake
1988-11-18  0:32     ` Ron Guilmette
1988-11-22 14:37       ` Stephe Leake
1988-11-23 13:37         ` Dennis Doubleday
1988-11-23 19:41           ` Steve Tynor
1988-11-23 21:14             ` Richard Pattis
1988-11-25 20:36             ` Robert Firth
1988-11-29 15:12           ` limited private types Stephe Leake
1988-12-01 23:06             ` Ron Guilmette
1988-12-05  1:48               ` Paul Stachour
1988-12-05 12:31                 ` Reference Semantics William Thomas Wolfe,2847,
1988-12-06  0:29                   ` Paul Stachour
1988-12-07  1:07                     ` Reference Semantics, assignment overloading, etc Ray Trent
1988-12-08 17:36                       ` Reference Semantics, assignment ryer
1988-12-06 16:56               ` limited private types ryer
1988-12-06 20:09               ` stt
1988-12-07 15:51               ` Stephe Leake
1988-11-21 15:40   ` Ada language revision stt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox