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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT 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!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!oleane.net!oleane!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Proposal: pragma Assumption Date: Thu, 29 May 2008 19:27:07 -0500 Organization: Jacob's private Usenet server Message-ID: 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: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1212107266 10248 69.95.181.76 (30 May 2008 00:27:46 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 30 May 2008 00:27:46 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:461 Date: 2008-05-29T19:27:07-05:00 List-Id: "Santiago Urue�a" wrote in message news:4d2bb014-c956-454b-bcfb-a98cd524e5b4@m36g2000hse.googlegroups.com... ... >> ------------------- >> -- Unimplemented; -- >> ------------------- >> >> procedure Unimplemented is >> begin >> Ada.Exceptions.Raise_Exception >> (Program_Error'Identity, "interrupts/signals not implemented"); >> raise Program_Error; >> end Unimplemented; >> >> Then call "Unimplemented;" where needed. and remove the call when >> routine is corrected. >> >I also considered this approach (but of course the procedure was >called "Asumption" and it received a boolean parameter :-), but when >compiling the final binary you are again at risk of forgetting to >search for any remaining calls to that procedure or to remove its body >(people make that kind of mistakes all the time). Instead, with pragma >Assumption the compiler will warn you, anyway it is common practice to >have different compilations options for each development phase, and >unless that option is explicitly added the compiler will reject any >occurrence of that pragma. I don't get it. If you remove the package containing Unimplemented from the 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 from some sort of compiler switch -- it's just as easy to forget changing that. Anything that requires a change is a bad thing! These days, "production" systems and "debugging" systems often are the same -- computers are fast enough that there is rarely a need to remove the 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. 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. Finally, as a pragma, there is nothing preventing an implementer from adding it if it is found useful. There doesn't seem to be any compelling reason to 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. Randy Brukardt.