
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.
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.)
On Sat, Nov 3, 2018 at 4:23 AM Joachim Durchholz
Am 03.11.18 um 02:46 schrieb André Popovitch:
However, I'm not extremely knowledgeable about Haskell and I wouldn't say I'm the best teacher, so if anyone is willing to skim it or provide feedback that would be much appreciated!
One kind of typo that's common enough to become annoying: comma/fullstop and subsequent space were interchanged.
Well-written overall. I'm pretty sure different people will have different ideas about what's important about Haskell, but I think your take is valid. Besides, the knowledgeable people won't know what a newbie will find most interesting or enlightening about Haskell, so you'll have to get feedback from non-Haskellers to judge how successful that site is.
Some details aren't quite right (as is to be expected with anything that goes beyond a dozen pages).
E.g. mutability does increase the number of variables you have to keep track of, it multiplies the amount of information you have to keep track of for each variable (namely the set of locations where it is changed).
Stating that Haskell does not have side effects will cause cognitive dissonance. Technically, Haskell does not have it, but there's that technique to put state into a function that you return, hiding the state not in a transparent data object but in a pretty opaque function object. This is being systematically (ab?)used in many monads, and in practice, it has exactly the same benefit as a mutable global state (you don't have to thread it through every function call, it's globally available), and the same problems (you don't know where it might be changed). And then there's IO, which is a different way to do mutability except by name. (I have never been able to find out what the concept behind IO is. My best guess is that it's a framework to set up descriptions of IO interactions, which tend to be infinite which isn't a problem since Haskell is lazy, but this may well be totally wrong. SPJ seemingly takes this for granted, and all the docs I could find just described the mechanics of using it, often with an implicit assumption that IO is a magical mutability enclave in Haskell, which I'm pretty sure is not actually the case.) I don't know enough to give good advice how to be neither wrong enough to confuse newbies with cognitive dissonance nor correct enough to confuse newbies with the full truth.
You should mention that `rem` needs to be typed including backquotes. With some fonts, they might look similar enough to normal quotes, and then be ignored. (That point in the presentation might be a good place for a side remark, explaining how Haskell allows using operators as functions, and how it allows using functions as operators.)
A sidebar notice might help to explain that Haskell's function call syntax is nearer to mathematical than programming language conventions: Mathematicians write "sin x", not "sin(x)"; they use parentheses only when precedences get in the way, e.g. they'll write "(sin x) + 1" if needed, or maybe "sin (x + 1)" but the "(x + 1)" isn't function-call syntax, it's precedence-altering syntax. (As conventions go in mathematics, it's just a common one, not a universal one. Mathematicians are horribly sloppy about their conventions. In fact they are sloppy about anything except the topic they're currently interested in. Well, programmers are obsessed about irrelevant detail because compilers force them into that habit, from their perspective, so both sides are right in a sense ;-)
Okay, enough for now.
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@gmail.com