<div dir="ltr">Conceptualization of IO is difficult. One way to think about it is the result of (main :: IO a) is a program sent to an impure runtime to execute, with IO actions being compositions of instructions for the runtime… but this breaks down as soon as you discover unsafePerformIO.<div><br></div><div>The closest that you'll get to the reality for GHC is that it pretty much is a haven for impurity: that it forces all impure functions to declare that in their types. (Not necessarily for mutability as such; ST gives you that without impurity.)</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 4:23 AM Joachim Durchholz <<a href="mailto:jo@durchholz.org">jo@durchholz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 03.11.18 um 02:46 schrieb André Popovitch:<br>
> However, <br>
> I'm not extremely knowledgeable about Haskell and I wouldn't say I'm the <br>
> best teacher, so if anyone is willing to skim it or provide feedback <br>
> that would be much appreciated!<br>
<br>
One kind of typo that's common enough to become annoying:<br>
comma/fullstop and subsequent space were interchanged.<br>
<br>
Well-written overall. I'm pretty sure different people will have <br>
different ideas about what's important about Haskell, but I think your <br>
take is valid.<br>
Besides, the knowledgeable people won't know what a newbie will find <br>
most interesting or enlightening about Haskell, so you'll have to get <br>
feedback from non-Haskellers to judge how successful that site is.<br>
<br>
Some details aren't quite right (as is to be expected with anything that <br>
goes beyond a dozen pages).<br>
<br>
E.g. mutability does increase the number of variables you have to keep <br>
track of, it multiplies the amount of information you have to keep track <br>
of for each variable (namely the set of locations where it is changed).<br>
<br>
Stating that Haskell does not have side effects will cause cognitive <br>
dissonance.<br>
Technically, Haskell does not have it, but there's that technique to put <br>
state into a function that you return, hiding the state not in a <br>
transparent data object but in a pretty opaque function object. This is <br>
being systematically (ab?)used in many monads, and in practice, it has <br>
exactly the same benefit as a mutable global state (you don't have to <br>
thread it through every function call, it's globally available), and the <br>
same problems (you don't know where it might be changed).<br>
And then there's IO, which is a different way to do mutability except by <br>
name. (I have never been able to find out what the concept behind IO is. <br>
My best guess is that it's a framework to set up descriptions of IO <br>
interactions, which tend to be infinite which isn't a problem since <br>
Haskell is lazy, but this may well be totally wrong. SPJ seemingly takes <br>
this for granted, and all the docs I could find just described the <br>
mechanics of using it, often with an implicit assumption that IO is a <br>
magical mutability enclave in Haskell, which I'm pretty sure is not <br>
actually the case.)<br>
I don't know enough to give good advice how to be neither wrong enough <br>
to confuse newbies with cognitive dissonance nor correct enough to <br>
confuse newbies with the full truth.<br>
<br>
You should mention that `rem` needs to be typed including backquotes. <br>
With some fonts, they might look similar enough to normal quotes, and <br>
then be ignored.<br>
(That point in the presentation might be a good place for a side remark, <br>
explaining how Haskell allows using operators as functions, and how it <br>
allows using functions as operators.)<br>
<br>
A sidebar notice might help to explain that Haskell's function call <br>
syntax is nearer to mathematical than programming language conventions: <br>
Mathematicians write "sin x", not "sin(x)"; they use parentheses only <br>
when precedences get in the way, e.g. they'll write "(sin x) + 1" if <br>
needed, or maybe "sin (x + 1)" but the "(x + 1)" isn't function-call <br>
syntax, it's precedence-altering syntax.<br>
(As conventions go in mathematics, it's just a common one, not a <br>
universal one. Mathematicians are horribly sloppy about their <br>
conventions. In fact they are sloppy about anything except the topic <br>
they're currently interested in. Well, programmers are obsessed about <br>
irrelevant detail because compilers force them into that habit, from <br>
their perspective, so both sides are right in a sense ;-)<br>
<br>
Okay, enough for now.<br>
<br>
Regards,<br>
Jo<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>