Doesn't that mean it's pure?
Edit:
I'd define pure in this sense as the same thing as referentially transparent, meaning f(x) will always return the same thing for a given x.
This is clearly the case with `println`.
(println "Hi there")
nil
Using Scheme (because I don't know Clojure that well)
(define (foo x)
(let ([y 0])
(set! y 10)
(+ x 1)))
println "Hi there"
IO nil
constantly_unit = f >> constantly_unit
If your notion of equality differentiates "println" and "constantly_unit" then we cannot call "println" pure.
Note that this is a very powerful notion of purity. It's so powerful as to render Haskell impure as if we have the function
loop x = loop x
This would mean that non-termination is not a property of the function, but of the compiler/runtime, in that they failed to notice that loop was a partial function called with an input value for which it was not defined!
loop >> constantly_unit
var a=f(0); a=f(1)
a=f(1)
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.
var a = println("Hello ")
a = println(" World")
var a = println(" World")
var a=println("Hello")
var b=println("Hello")
var a=println("Hello")
var b=aWhat 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.
In Haskell, all functions in the IO monad are by definition pure, and that includes all the println functions.
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.
A pure function always returns the same result because it only depends on its input parameters. An impure IO function does not.
Is breaking the kernel something I should actually consider likely?
Of course there is lots of code that has side effects in implementation but not in their interface. Like malloc, or a read only data structure that has an internal cache it updates.
> Doesn't that mean it's pure?
Unfortunately not because it also modifies global state (the state of the console). A pure function implies that it is referentially transparent, meaning that:
a = foo()
b = a + a
b = foo() + foo()
For a function to be pure, it must always return the same value given the same input and not modify any state that is observable outside of its definition.
Maybe a better example function is one that deletes data from your hard drive, or sens control signals to a robot that locks the doors or changes the A/C or starts some industrial process, releasing toxic chemicals.
The point is println does have a side effect, it's just not a very interesting one.
Or maybe the definition of side effect is what is causing the problem, after all - executing any function does have physical side effects - electrons move, electromagnetic styate chabnes, ambient temperature changes. Maybe the problem is where we draw the line for observable side effects.