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

[Brandon Allbery]

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 <jo at durchholz.org> wrote:

> 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 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181103/10df2617/attachment.html>