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

[Andrew Butterfield]

> On 3 Nov 2018, at 08:59, Joachim Durchholz <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.

Haskell I/O is referentially transparent in that if you can show that two expressions of type IO a have the same I/O side-effecting behaviour
(using the monad laws plus some IO-action semantics) then one can replace the other in any Haskell context without altering the IO behaviour of that context.
Caveat: provided you don't use "unsafeXXXX" anywhere...

(*) 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"

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


> I have not been able to verify whether this is actually true. Maybe IO is really a wart on Haskell's purity.
> I'd hate it if it were, and I think the Haskell design group would have hated that as well. OTOH IO is one of three approaches, and it happened to be the one that became usable first, so it's not part of the initial design process. Then again I like to think that SPJ wouldn't even contemplate something impure - but I don't really know.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero at TCD, Head of Foundations & Methods Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
                         http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181105/a506221d/attachment.html>