Re: Ada and OpenMP

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> 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