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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting article on ARG work Date: Fri, 6 Apr 2018 09:30:52 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1b44444f-c1b3-414e-84fb-8798961487c3@googlegroups.com> <62ee0aac-49da-4925-b9aa-a16695b3fc45@googlegroups.com> <9879872e-c18a-4667-afe5-41ce0f54559f@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51350 Date: 2018-04-06T09:30:52+02:00 List-Id: On 06/04/2018 00:18, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:pa4ip3$1ton$1@gioia.aioe.org... >> On 05/04/2018 00:30, Randy Brukardt wrote: >> >>> There is a much more general proposal for Ada 2020 called "ghost code" - >>> a >>> silly name for code and declarations intended only to be used by >>> assertions. >>> (The idea being that if it is marked and enforced as such, it can be >>> removed >>> when the Assertion_Policy is Ignore.) >>> >>> Using that (which may or may not make it into Ada 2020 -- we haven't yet >>> discussed it at a meeting), one could use a ghost function for this >>> purpose: >>> >>> function My_Assertion (...) return Boolean is >>> (if Condition then raise Assertion_Error with Message else >>> True) >>> with Ghost; >>> >>> pragma Assert (My_Assertion (...)); >>> >>> (Note: The "..." here is any objects that Condition needs to be >>> evaluated.) >> >> Assertion code is quite useless from my point of view, but what about >> debugging code? It is quite tedious to comment it in and out all the time >> (and with/use clauses required for it). > > My assumption has always been that Ghost code could be used for that as > well, but since it's more of an idea than a proposal, it's hard to say > anything definitive. > > If you used Janus/Ada, you'd have a built-in solution for that (sadly, > incompatible with Ada 2020): the @ conditional compilation marker. It is > interpreted as either "--" or " " depending on a compilation flag, so it can > easily add or remove anything. We originally invented it to deal with > debugging/assertion code in the Janus/Ada compiler; probably about 25% of > the code in Janus/Ada is marked that way. Since it is lexical, it can > comment out anything, including declarations, pragmas, and with clauses. > > In programs intended to be portable, I just use static Boolean flags for > debugging code. Any compiler with decent dead code elimination (which would > be about all of them) will get rid of most/all of the code that way. But > that doesn't work on pragmas, context clauses, or declarations, so it isn't > quite as through as @. (With Janus/Ada, which does dead subprogram > elimination during binding, including for tagged type primitives, the > difference isn't that substantial unless large data declarations are > involved.) Yes, it is frequently "with Ada.Text_IO" or some internal package like Dump_Pool etc. One could easily imagine record components provided for debugging purpose and attributes selected differently, e.g. X'Storage_Pool etc. Another "requirement" is integration into IDE. It should be easy for the IDE to hide all this code when debugging is inactive and colorize it differently when active. Janus/Ada solution looks better than pragma. And it could be extended to provide multiple sections of debugging code which could be activated and deactivated independently. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de