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,FREEMAIL_FROM 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.224.185.201 with SMTP id cp9mr2040191qab.6.1362761565438; Fri, 08 Mar 2013 08:52:45 -0800 (PST) X-Received: by 10.50.7.163 with SMTP id k3mr382706iga.1.1362761565397; Fri, 08 Mar 2013 08:52:45 -0800 (PST) Path: o5ni47qas.0!nntp.google.com!dd2no8275847qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 8 Mar 2013 08:52:44 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.20.190.126 References: <87k3pjht79.fsf@ludovic-brenta.org> <3e01ac49-4427-4f50-8577-8edab7e539a6@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9e0bbbdf-ccfa-4d4c-90af-2d56d46242b3@googlegroups.com> Subject: Re: Ada and OpenMP From: Shark8 Injection-Date: Fri, 08 Mar 2013 16:52:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-03-08T08:52:44-08:00 List-Id: On Thursday, March 7, 2013 8:42:15 PM UTC-7, Randy Brukardt wrote: >=20 > In order for that to be the case, the pragma would have to make various= =20 > constructs illegal in the loop and in the surrounding code (exception=20 > handlers, any code where one iteration of the loop depends on the next,= =20 > erroneous use of shared variables). But a pragma shouldn't be changing th= e=20 > legality rules of the language. (And it's not clear this would really fix= =20 > the problem.) Why would that have to change the semantics of the program: since there wou= ld have to be a non-implementation-defined code-generation method (for when= the pragma was off) the compiler should just use that if those constructs = are used. It limits the usefulness, yes; but there's no reason to assume that it shou= ld cause erroneous execution. -- I suppose that in early versions of playin= g w/ an experimental version there might be some because of some case that = was overlooked. -- Though this does seem to bring us back to the idea of e= xceptions (and how to indicate/assert to the compiler that none, or a limit= ed set, can be raised). >=20 >=20 >=20 > Alternatively, the parallel version could simply be erroneous if any of= =20 >=20 > those things happened. But that means you have no idea what will happen, = and=20 >=20 > you've introduced new forms of erroneousness (meaning that there is no=20 >=20 > chance that the pragma would ever be standardized). >=20 >=20 >=20 > Ada is about doing things right, and that should be true even for=20 >=20 > implementation-defined stuff. And we *need* people to figure out good way= s=20 >=20 > of doing these things (for instance, a "parallel" classification for=20 >=20 > functions would be very helpful). The sloppy way helps little. >=20 >=20 >=20 > Randy "No New Pragmas" Brukardt