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-Thread: a07f3367d7,5164ccc41905b2d0 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.183.135 with SMTP id em7mr3043367wic.0.1363061203423; Mon, 11 Mar 2013 21:06:43 -0700 (PDT) MIME-Version: 1.0 Path: bp2ni87041wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!216.40.29.245.MISMATCH!novia!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!backlog1.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!weretis.net!feeder1.news.weretis.net!usenet.pasdenom.info!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada and OpenMP Date: Thu, 7 Mar 2013 21:42:15 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87k3pjht79.fsf@ludovic-brenta.org> <3e01ac49-4427-4f50-8577-8edab7e539a6@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1362714137 15781 69.95.181.76 (8 Mar 2013 03:42:17 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 8 Mar 2013 03:42:17 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 4143 Date: 2013-03-07T21:42:15-06:00 List-Id: "Shark8" wrote in message news:3e01ac49-4427-4f50-8577-8edab7e539a6@googlegroups.com... On Thursday, March 7, 2013 4:42:59 PM UTC-7, Randy Brukardt wrote: >> >> Pragmas, IMHO, are the worst way to do anything. Compiler writers tend to >> use them because they can do so without appearing to modify the language, >> but it's all an illusion: the program probably won't work right without >> the >> pragma, so you're still locked into that particular vendor. Might as well >> have done it right in the first place (and make a proposal to the ARG, >> backed with practice, so it can get done right in the next version of >> Ada). > >I'm not sure I totally agree with your sentiment; IIRC, Pragmas in Ada were >supposed >to be parentheticals to the compiler that were not essential to program >correctness -- such >as Optimize or the source-printing pragma Page. > >That sentiment was thwarted with the inclusion of representation pragmas. Which are now obsolescent. We've finally removed most of a basic mistake in the design of the language. It would be a pity to bring it back. > -- However, the Ada specification *does* allow for implementation-defined > pragmas. > It seems to me that such would be ideal for experimental or > compiler-specific > code-generation. That's fine if that is all that it does. But that's not possible here. > The previous poster's "Pragma OMP(...)" is an excellent example No, it changes the semantics drastically. Exceptions don't work, I/O and progress counters have to be avoided in the loop, etc. > (though I think the FOR_LOOP parameter is stupid, the feature [OMP] should > be > turned on/off as needed, letting the compiler determine the optimal > technique to use. > {A program written in such a way would be correct even if the code were > ported > to a non-OMP compiler, provided the underlying algorithm was correct.} In order for that to be the case, the pragma would have to make various constructs illegal in the loop and in the surrounding code (exception handlers, any code where one iteration of the loop depends on the next, erroneous use of shared variables). But a pragma shouldn't be changing the legality rules of the language. (And it's not clear this would really fix the problem.) Alternatively, the parallel version could simply be erroneous if any of those things happened. But that means you have no idea what will happen, and you've introduced new forms of erroneousness (meaning that there is no chance that the pragma would ever be standardized). Ada is about doing things right, and that should be true even for implementation-defined stuff. And we *need* people to figure out good ways of doing these things (for instance, a "parallel" classification for functions would be very helpful). The sloppy way helps little. Randy "No New Pragmas" Brukardt