>John Blair-Fish <[log in to unmask]> writes:
>
>> My understanding was that PURE procedures could be run in
>> parallel. If they were going to do I/O there would be all the
>> potential problems of several instances of a procedure trying to do
>> I/O to the same file or device.
>
>Thorsten Ohl wrote:
>
>> That's an (unfortunately very relevant) implementation issue, that,
>> in the ebst of all worlds, would not compromise language design.
>
>Bill Long <[log in to unmask]> writes:
>
>> On this last point I completely disagree. John Blair-Fish is right.
>> A central issue in language design is the avoidance of ambiguity.
>
>Agreed. Maybe I misunderstood John's point: I thought that he was
>referring to the non-reentrancy of many legacy implementations of the
>Fortran I/O subsystem.
Bill is right about the problem. Saying "PURE procedures cannot have
general I/O" is sort of like saying "She's only a little bit pregnant".
The puzzle that we were trying to solve (when this came up in HPFF) was this:
* Fortran very carefully describes the order of output when it occurs.
* This order was ill-defined for FORALL or array assignments.
- And imposing any particular order made some implementations inefficient.
* We had decided that PUREness would be statically checkable.
* We had decided that Fortran would retain determinant execution.
The way you seem to be solving the ordering problem is to relax the
"determinant execution" constraint for standard-conforming programs.
That's reasonable, but if you do that then you open a rather large door to
nondeterministic programs.
>> I assume an elemental procedure would be called with array arguments. In
>> that case, the order in which the various calls is executed is
>> completely random. If the procedure does output, the order of the
>> output operations would be random, leading to completely different
>> output files from different runs. It is a basic function of language
>> design to avoid this sort of disaster.
>
>But this is not necessarily a disaster. If the array under
>consideration is an array of complex objects, I can give unique names
>to each instant. Then I can prefix every message with this unique
>name and the output remains useful (sort(1) and grep(1) are assumed to
>be available :-).
Funny, I don't find sort(1) and grep(1) in my Fortran standards :-)
This is a serious issue. You seem to be assuming that the messages
themselves are atomic. I've worked on parallel systems where lines printed
from different nodes interleaved their characters. Unless your errors were
one character long, sorting them out was a real mess. I'm not sure where
you are drawing the "general I/O" line that it would not allow this
pathology. (Or are you constraining the OS that Fortran is running under?)
>But returning to me second question: how _are_ you debugging your PURE
>and ELEMENTAL procedures?
>
>Cheers,
>-Thorsten
I debug them as non-PURE procedures before using them in array contexts.
Symbolic debuggers are also a great invention.
Chuck
----------------------------------------------------------------------
Charles Koelbel CRPC, MS 132
Center for Research on Parallel Computation Rice University
Rice University 6100 Main Street
[log in to unmask] Houston, TX 77005
phone: 713-285-5304 fax: 713-285-5136
----------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|