Path: utzoo!utgpu!watmath!clyde!att!ulysses!hector!dsr
From: dsr@hector.UUCP (David S. Rosenblum)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <10959@ulysses.homer.nj.att.com>
Date: 4 Dec 88 21:03:54 GMT
References: <10918@ulysses.homer.nj.att.com> <3720@hubcap.UUCP>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: dsr@hector.UUCP (David S. Rosenblum)
Organization: AT&T Bell Laboratories, Murray Hill, NJ
Lines: 40

In article <3720@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
|From article <10918@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
|> 
|> The ADT-handling package may feel like leaving a component undefined, but
|> Ada doesn't feel like leaving variables undefined after an assignment.
|> That's why such a user-defined assignment violates Ada's strong typing.
|
|      Really?  Consider the following:
|
|         procedure FUN_WITH_UNDEFINED_VARIABLES is
|
|            A : INTEGER;    -- A is undefined...
|            B : INTEGER;    -- B is undefined...
|         
|         begin
|            A := B;   -- Quick, what value does A have? 
|         end FUN_WITH_UNDEFINED_VARIABLES;

Easy.  A has a value that satisfies the constraints on INTEGER, which
implies that B does also.  We splitting hairs here, but I'll give it
to you--A is still undefined.

Note that you're relying on INTEGER being implicitly initialized with a valid
value; this is probably considered erroneous (I don't have an LRM
on hand).

|
|      This compiles and executes under Alsys Ada.

I don't doubt it.  Do you seriously regard this as "proof" that assignment
doesn't incorporate type checking?


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