[Haskell-cafe] Looking for feedback on my beginner's Haskell resource

[Joachim Durchholz]

Am 05.11.18 um 11:40 schrieb Andrew Butterfield:
> 
>> On 3 Nov 2018, at 08:59, Joachim Durchholz <jo at durchholz.org 
>> <mailto:jo at durchholz.org>> wrote:
>> If Haskell is truly pure, then IO must be pure as well.
>> That's why I think that IO functions are just describing impure 
>> activity, not doing it.
> 
> I think that is exactly the best way to think about it (thanks!).  Right 
> now I am teaching "Introduction to Functional Programming"
> here, and have just introduced IO last week, so this is all in my head 
>   right now.
> 
> A Haskell IO program is just a description of a sequence of IO actions 
> (IO a), which *when evaluated* will produce side-.effects
> A function evaluation that produces side-effects when evaluated is a 
> dangerous thing if used in an arbitrary fashion, but the IO abstraction(*)
> prevents danger by (i) having a fixed sequence of such actions, and (ii) 
> never allowing a Haskell program to have a direct reference to the part
> of I/O state that gets modified.

I'm not sure how this model explains the sequencing that happens in IO.
Haskell's evaluation model for function calls is lazy, i.e. it doesn't 
impose an order (and it does not even trigger evaluation).
AFAIK the one strict thing in Haskell is pattern matching, so I'd look 
how pattern matching drives IO's sequencing - but I don't see it.

> Caveat: provided you don't use "unsafeXXXX" anywhere...

Sure, that's just the loophole.
Another red herring I think.

> (*) the IO abstraction happens to be an instance of a class called 
> "Monad" that captures an interesting and useful pattern of sequential 
> behaviour,
> but this is really a bit of a red-herring when it come to understanding 
> how Haskell has both side-effecting IO and "purity"

I like to say that "'monadic IO' is akin to saying 'associative 
arithmetic'."
I.e. associativity is an important aspect of arithmetic just like 
monadicity for IO, but it's not what it was made for.

I am not sure how far this analogy holds water.

> PS - "purity" and "referential transparency" are slippy concepts, quite 
> hard to pin down, so it is unwise to put too much value into those terms...

The definition I've been using is that an expression and its value are 
interchangeable without changing the semantics.
I never ran into trouble with this - either because of my ignorance, or 
because that definition has the exactly right kind of vagueness, neither 
implying too much nor too little.

Just my 2c.

Regards,
Jo