[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.