[nimish]

The io monad is fully pure.

The interpretation of the io monad? That's another story.

Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#)

For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.

[nendroid]

I never said it's not pure. Just like how a SQL string in haskell is fully pure. Doesn't change the fact that you're using pure primitives to control a process that is fundamentally unpure. The concept leaks across the boundary.

[nimish]

It doesn't. That's the whole point of the io monad.

Outside of the io monad you cannot (modulo some exceptions) indicate io.

[nendroid]

It does. You're completely and utterly wrong. You don't understand.

I'll reiterate my example a SQL string is pure. Just like the IO monad is pure. However when you're coding the sql string in your "pure" haskell program you have to account for imperative side effects related to the SQL itself.

   sqlString = "UPDATE X SET X.Y=2 WHERE X.Z = 1"

sqlString is technically "pure" but that doesn't mean you can treat the UPDATE command in the string as a pure concept.

It doesn't matter how "pure" your language or sqlString is... the concept of a mutation leaks over into the language and the programmer still has to deal with the concept.

Like you're original post said. The interpretation of the monad is different, and the programmer still needs to account for this in how he composes things together. The concept leaks across boundaries.

edit>>this whole karma thing is unfair. Posters can't vote down responses. I simply state my opinion the person responds then votes me down because he disagrees. What's the point of even having a discussion?

[nimish]

You can make your point without the theatrics.

This is a philosophical distinction, not an objective fact.

I do not consider sqlString to be impure. It’s a perfectly valid string. I consider `executeQuery sqlString :: IO Result` to be an indication of impurity, since I can do `let x = executeQuery sqlString in “bar”` as a valid bit of Haskell but it’s clearly 100% pure.

If you want to think that sqlString is “impure” outside of the context of execution (i.o.w. a Monad...) then sure, that’s valid, but so is my assertion that it is pure since it is referentially transparent. It exists in the void as just another string until the programmer decides to make it into an IO value that’s executed for its impure side effects (the only reason we do anything in computing, right?)

I think you’re getting downvoted (I can’t) because of your first statement.

[nendroid]

>I think you’re getting downvoted (I can’t) because of your first statement.

nobody is reading this stuff anymore. It's just you and me. You have over 800 karma. You CAN downvote and you ARE. There is no theatrics, you're just voting me down, stop.

>I do not consider sqlString to be impure.

It's not "impure." But it doesn't change the fact the way you you write your SQL has imperative side effects within the database. You can trigger a deadlock in the database from within your pure haskell code if you wanted to.

It's not a philosophical thing. You absolutely have to consider imperative side effects even in your pure program.

That is reality. The philosophical part is whether you can call it "pure" or "impure."

>If you want to think that sqlString is “impure” outside of the context of execution (i.o.w. a Monad...) then sure, that’s valid, but so is my assertion that it is pure since it is referentially transparent. It exists in the void as just another string until the programmer decides to make it into an IO value that’s executed for its impure side effects (the only reason we do anything in computing, right?)

Yeah so? I never said your assertion was wrong. I never said that it was "impure." But I did say that you have to account for side effects in your program. Example:

   sqlString = "SELECT * FROM ASKDLSADSA DFLDSJFL DLSKFJSDLKFD SDLFKSDJF DSLKFJSDF SDFKLSDFJ "

Is a valid "pure" string, but will trigger a syntax error in your database. You have to account for all of this within your "pure" program. Haskell eliminates side effects in the category Hask but does not actually eliminate the need for YOU to deal with those side effects. This part is an objective fact.

Here's a better way to put it. For this specific example, the impurity of the real world leaks into your pure haskell program by affecting the contents of the string. The type itself can be seperate from the real world but the contents of the string reflects knowledge and impurity from the real world.

[AnimalMuppet]

I have over 14,000 karma. I can't downvote (direct) replies to my posts. So as far as HN mechanics go, you are falsely accusing nimish.

Other people - not nimish - are downvoting you. And they're doing so because you're starting to cross the line from "disagreeing" to "aggressive and rude".

Now for what it's worth, I'm kind of on your side of the actual dispute. I just think you're pushing the line in trying to be more, um, "expressive".