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

[Brandon Allbery]

No state is modified, at least in ghc's implementation of IO. IO does carry
"state" around, but never modifies it; it exists solely to establish a data
dependency (passed to and returned from all IO actions; think s -> (a, s),
but IO uses unboxed state) that thereby enforces sequencing. Once it
reaches code generation, it discovers the runtime representation of the
"state" is nonexistent (size 0) as well as unboxed, and eliminates it and
all code related to it.

On Mon, Nov 5, 2018 at 4:54 PM Joachim Durchholz <jo at durchholz.org> wrote:

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



-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181105/68432b4a/attachment.html>