Post by n***@cam.ac.ukPost by Daniel CarreraPost by n***@cam.ac.ukThat is precisely because, as we agree, a language COULD include
that wrinkle as acceptable in pure code. I have just checked,
and Fortran 2008 doesn't do that - indeed, I don't think that it
could, because of historical baggage.
(snip)
Post by n***@cam.ac.ukPost by Daniel CarreraBut if foo() and bar() print text to a file, or to the terminal, then in
a very real sense, the two lines above have different behaviour. With
some effort, I'm sure someone in this list can think of an example where
the difference might be important. For example, the printed output might
be command instructions for some other process.
You are using a particular semantic model, which is not the only
one. I was slightly over-simplifying but, for the reasons you
give, I would distinguish 'diagnostic' from 'functional' pure
output streams if I designed a language.
Anyway, the reason that the order is irrelevant in this context
is that it cannot affect the behaviour of any other part of the
It is therefore NOT a side-effect, though I accept that it is a
potentially visible effect.
Thanks for all the comments. Indeed, I was thinking purely (pun
intended) about 'diagnostic' output; I put the print/write statements
with side effects in separate subroutines. The reason I am still
thinking about it is that my code is several layers deep, and the
innermost is the crucial one where I want these diagnostic messages.
Because of this, none of the other layers can be pure, although
otherwise they would be. What's more, I already have an
if(print_diagnostic)
in front of each such print statement, so that if this is false, the
procedure is in effect pure.
For me, an important reason for purity was that I thought it helps when
building parallel applications - which the present project is likely
going to be. However, skimming through Intel's manual and its discussion
on the various ways of parallelization, I found no mention of the PURE
keyword, although of course it's made clear that side effects might
inhibit efficient parallelization.
So it seems to me that adding PURE wouldn't help in that respect, but
that surprises me a bit. Specifically, I have a nested, performance
critical do-loop where the innermost loop performs many independent
iterations which each call several 'effectively-pure' subroutines (i.e.,
pure apart from those darned diagnostic prints). I would have expected
that telling the compiler explicitly that these are PURE would help in
parallelizing, but I might be thinking too much in terms of the
'auto-parallelization' feature of Intel's compiler.
To force my question into one line (hopefully not making it too
general/unclear): does the PURE keyword help in parallel applications?