Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <3736@hubcap.UUCP>
Date: 5 Dec 88 02:34:24 GMT
References: <10959@ulysses.homer.nj.att.com>
Sender: news@hubcap.UUCP
Reply-To: billwolf@hubcap.clemson.edu
Lines: 38

From article <10959@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> 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.
# |
# |         [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?

     Well, you are quoted above as saying (correct me if I'm wrong...) that
     Ada somehow required that a variable be defined after assignment, and
     that a user-defined assignment such as the one you described could leave
     a component undefined and therefore violate strong typing.  

     As far as I'm concerned, if we implemented your example as a user-defined
     ADT, the only problem that could occur would be failure of the implementor
     to properly respond to a request for the value of the denominator.  If the
     implementor handles the request properly, it wouldn't matter if there were
     undefined components; the user can never access them anyway, and in general
     will never know the difference.  In other words, the implementor may well
     view the state in which the denominator is undefined as a valid state of
     the ADT.  I see nothing wrong with that.