How so? println returns `Unit` so certainly, what you say above doesn't hold.
Even if `println` returned a value, it would still be considered pure as long as that value is strictly calculated from its input parameter and that parameter alone (say, the size of the string).
Another often used criterion to determine purity of a function is whether inlining it everywhere in your program produces a similar program. There again, `println` passes this test.
The only way `println` could not be pure is if you call it with the same string twice and it returns a different value.
My (quite possibly wrong) understanding is that purity has nothing to say about side effects. It's simply concerned with the inputs and outputs of functions, specifically whether the function will always return the same value given the same input.
What zak_mc_kracken is saying is that under this definition println is obviously and trivially pure because it returns the same value for every input.
You're correct that it won't have the proper side effects when optimized but under this definition that doesn't have anything to do with purity.
Edit:
If you want the "side effects" of the println statement to be considered part of the "output" then you want something like Haskell's semantics where the println statements are IO actions.
You are correct under this particular interpretation of purity, there are just competing ways to assess said purity. Wikipedia only lists two (the one you just showed and the one I described) but is missing the third one (the inlining approach).
In Haskell, all functions in the IO monad are by definition pure, and that includes all the println functions.
That would be discarding the effect of print, since inputs aren't just ignored, but used to modify the system somehow somewhere. Replace print* by set!, `:=` if that helps.
Yes the relationship between input and output is clearly defined, though. Your point of view raises a good point about precision when talking about purity and functions.
Comments
How so? println returns `Unit` so certainly, what you say above doesn't hold.
Even if `println` returned a value, it would still be considered pure as long as that value is strictly calculated from its input parameter and that parameter alone (say, the size of the string).
Another often used criterion to determine purity of a function is whether inlining it everywhere in your program produces a similar program. There again, `println` passes this test.
The only way `println` could not be pure is if you call it with the same string twice and it returns a different value.
Consider the following program.
This should output "Hello \n World\n" However, assuming println is pure, we can optimize this to just Which produces a different output. We could also convert: intoMy (quite possibly wrong) understanding is that purity has nothing to say about side effects. It's simply concerned with the inputs and outputs of functions, specifically whether the function will always return the same value given the same input.
What zak_mc_kracken is saying is that under this definition println is obviously and trivially pure because it returns the same value for every input.
You're correct that it won't have the proper side effects when optimized but under this definition that doesn't have anything to do with purity.
Edit: If you want the "side effects" of the println statement to be considered part of the "output" then you want something like Haskell's semantics where the println statements are IO actions.
Edit: zak_mc_kracken beat me to it.
You are correct under this particular interpretation of purity, there are just competing ways to assess said purity. Wikipedia only lists two (the one you just showed and the one I described) but is missing the third one (the inlining approach).
In Haskell, all functions in the IO monad are by definition pure, and that includes all the println functions.
That would be discarding the effect of print, since inputs aren't just ignored, but used to modify the system somehow somewhere. Replace print* by set!, `:=` if that helps.
Yes the relationship between input and output is clearly defined, though. Your point of view raises a good point about precision when talking about purity and functions.