Chuck Koelbel <[log in to unmask]> writes:
> Saying "PURE procedures cannot have general I/O" is sort of like
> saying "She's only a little bit pregnant". [...] 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 start to agree. There are still instances where I would love to
throw in a `print *' for debugging, but the door to nondeterministic
behaviour is larger than I first thought.
> You seem to be assuming that the messages themselves are atomic.
Yes. This was too naive on my part.
> I've worked on parallel systems where lines printed from different
> nodes interleaved their characters. [...] I'm not sure where you are
> drawing the "general I/O" line that it would not allow this
> pathology.
I was thinking about error messages, execution monitoring and
debugging that would better not be buffered anyway.
>> But returning to me second question: how _are_ you debugging your
>>> PURE and ELEMENTAL procedures?
> I debug them as non-PURE procedures before using them in array contexts.
If there were IMPURE ELEMENTAL procedures, one could just filter all
the PURE keywords during delevopment.
> Symbolic debuggers are also a great invention.
If they work :-(.
Cheers,
-Thorsten
--
Thorsten Ohl, Physics Department, TU Darmstadt -- [log in to unmask]
http://crunch.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|