From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,18069d15345a10c8
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-14 14:27:27 PST
Newsgroups: comp.lang.ada
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!swrinde!sgiblab!pacbell.com!amdahl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Modulus and Remainder operations (Was Re: Help with a bit of C
 code)
Message-ID: <hbakerCxo659.H6w@netcom.com>
Organization: nil
References: <37er8t$oh0@watnews1.watson.ibm.com> <hbakerCxL95y.8L3@netcom.com>
 <37k951$153e@watnews1.watson.ibm.com>
Date: Fri, 14 Oct 1994 15:39:09 GMT
Date: 1994-10-14T15:39:09+00:00
List-Id: <comp.lang.ada>

In article <37k951$153e@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes:
>In article <hbakerCxL95y.8L3@netcom.com>, hbaker@netcom.com (Henry G. Baker)
>says of the bounded error that results from aliasing subprogram
>variables: 
>
>|>                     But this policy is still a crock, especially for
>|> Ada 'limited' types, because the definer of the type has lost control
>|> of the type.  The 'textbook' definitions of prototypical limited types
>|> such as 'bank accounts' are no longer safe in the presence of such
>|> equivocation.
>|>
>|> See "How to Steal from a Limited Private Account--Why Mode INOUT
>|> Parameters for Limited Types MUST be Passed by Reference".  Ada
>|> Letters XIII, 3 (May/June 1993), 91-95.  This paper is also in my ftp
>|> directory.
>
>Henry, you seem to be envisioning some sort of adversarial relationship
>between the writer of a limited private type and the client who uses the
>type.

In short, yes.  We'll never reach the nirvana of being able to
more-or-less painlessly put together large systems from smaller
components without some strong guarantees that clients of
encapsulations cannot screw up the objects exported by the
encapsulations.  The more of these 'contractual' issues that can be
put _into_ the language and type system so that they can be enforced,
the easier it will be to construct these systems by composition.

Static type systems and 'packages' were deemed important for precisely
these reasons.  However, Ada83 & Ada9X have heretofore refused to close
this loophole in the strong typing model.

>It's still a step forward from Ada 83, where the same rule violation is
>considered erroneous, which means in effect that the underlying abstract
>machine is broken and NOTHING is guaranteed.

I agree that it is a step forward, in much the same vein that a square
wheel is an improvement on a triangular one.  Still makes for one heck
of a bumpy ride, though.  :-)

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.