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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,78447032bdbeb343 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!x41g2000hsb.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Santiago_Urue=F1a?= Newsgroups: comp.lang.ada Subject: Re: Proposal: pragma Assumption Date: Fri, 30 May 2008 04:02:02 -0700 (PDT) Organization: http://groups.google.com Message-ID: <39b85410-ff86-42dd-82b7-e24e5e2ae022@x41g2000hsb.googlegroups.com> References: <30917be5-1446-417c-8a4e-18b2f9a1f420@b1g2000hsg.googlegroups.com> <97479cac-db1a-4654-949b-2caa45031cf1@t54g2000hsg.googlegroups.com> <4d2bb014-c956-454b-bcfb-a98cd524e5b4@m36g2000hse.googlegroups.com> NNTP-Posting-Host: 138.4.11.35 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1212145323 22893 127.0.0.1 (30 May 2008 11:02:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 30 May 2008 11:02:03 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: x41g2000hsb.googlegroups.com; posting-host=138.4.11.35; posting-account=Lcd2wAoAAAADW2SqWO5AWY55Q-jjpVWU User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.10) Gecko/20071115 Iceweasel/2.0.0.10 (Debian-2.0.0.10-0etch1),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:469 Date: 2008-05-30T04:02:02-07:00 List-Id: > I don't get it. If you remove the package containing Unimplemented from th= e > program (as you should do in this case), any remaining references will be > caught by the compiler as undefined. I don't see how that is different fro= m > some sort of compiler switch -- it's just as easy to forget changing that.= > Anything that requires a change is a bad thing! > The compiler switches for the production and debugging builds are always carefully chosen, so if by default that pragma is rejected by the compiler IMO it is unlikely that somebody add it to the production build script by accident (but it will be quickly added to the debug target if somebody uses it). > These days, "production" systems and "debugging" systems often are the > same -- computers are fast enough that there is rarely a need to remove th= e > debugging code. (And leaving it in can help technical support a lot, > especially when customers can't send a code sample for one reason or > another.) So anything that depends on a difference in building a system is= > dubious in my view. > I agree, and that's fine. In that case pragma Assumption would only document that: whereas an Assert is (in theory) always true, a pragma Assumption highlights that that code is not completely finished, and that it is known that in some cases it will fail. In both cases, when any Assertion exception is raised, that data should be sent to the technical support (in fact, that's exactly what Tony Hoare explains in the article). Probably there is no need to add another exception when triggering a bad assumption, but it could be added if somebody thinks that those cases should be handled separately. > Moreover, I don't see anything that this feature would provide that is > really helpful. Our coding standard includes a structured comment: > -- **Temp: > for anything that requires later work. I personally usually use "raise > Program_Error;" or a call to a routine defined for that purpose (the > Janus/Ada optimizer has a routine "Die()" for instance) if code is= > left out for any significant period. The structured comment allows future > finding of these areas if desired. But it isn't uncommon to decide to not > bother with implementing such things: if the case never happens, it's > probably a waste of time to implement it. In which case the comment and > "Die" may live for a long time. > This pragma just reflects common software development processes, adding support to the language to the incremental and iterative schemes. (BTW, they are not the same! see: http://www.stsc.hill.af.mil/crosstalk/2008= /05/0805Cockburn.html ) > Finally, as a pragma, there is nothing preventing an implementer from addi= ng > it if it is found useful. There doesn't seem to be any compelling reason t= o > add it to the language in order to get it implemented. As such, I'd > recommend that such a proposal be filed as an AC (received no action). > > If you can convince some implementers to implement it, *and* it proves > useful, *then* it might be considered for future standardization. But not > without something that cannot currently be done. > Thanks for the advice, I think that's the way to go! -- Santiago Urue=F1a Pascual Technical University of Madrid (UPM)