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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-30 03:56:12 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!ken-transit.news.telstra.net!news.telstra.net!news-server.bigpond.net.au!not-for-mail From: Dale Stanbrough Newsgroups: comp.lang.ada Subject: Re: Saturated Math References: <3ECFF541.1010705@attbi.com> <3ED0B820.5050603@noplace.com> <3ED2096F.3020800@noplace.com> <3ED353BE.40605@noplace.com> <3ED4A323.3000909@noplace.com> <3ED5E8DE.8070308@noplace.com> User-Agent: MT-NewsWatcher/3.3b1 (PPC Mac OS X) Message-ID: Date: Fri, 30 May 2003 10:54:50 GMT NNTP-Posting-Host: 144.132.47.50 X-Complaints-To: abuse@bigpond.net.au X-Trace: news-server.bigpond.net.au 1054292090 144.132.47.50 (Fri, 30 May 2003 20:54:50 EST) NNTP-Posting-Date: Fri, 30 May 2003 20:54:50 EST Organization: BigPond Internet Services (http://www.bigpond.net.au) Xref: archiver1.google.com comp.lang.ada:38074 Date: 2003-05-30T10:54:50+00:00 List-Id: AG wrote: > "Dale Stanbrough" wrote in message > news:dstanbro-D4C3C0.18423630052003@mec2.bigpond.net.au... > > I've just tried writing such a package (generic) and it doesn't seem > > that it would be altogether seemless for the end user. > > > > procedure main is > > type Number is new Integer range 1..5; > > > > package Saturated_Int is new Saturate (Number); > > use Saturated_Int; > > > > x : Number := 4; > > begin > > x := Saturated_Int."+" (x, 2); > > x := Saturated_Int."-" (x, 6); > > end; > > > > > > The function "+" in the following > > > > x := x + 2; > > > > is said to be ambiguous with Standard."+" (according > > to gnat). > > In this case, the problem seems to be that the compiler > (quite rightly) can't tell which "+" you mean since there > are, in fact, two implementations visible at that spot. yes, i agree. But i think that's the problem of user defined saturation maths packages. (unless someone can come up with a different solution). It seems that the client has to use the package.operator notation if you want to implement saturated maths this way. Is there any way around this? Dale