

Tackling the Awkward Squad: Interaction with the world in Haskell (2010) [pdf] - sksk
http://research.microsoft.com/en-us/um/people/simonpj/Papers/marktoberdorf/mark.pdf

======
sksk
I have been reading Haskell, The Craft of Functional Programming. I have
played around with Haskell for a bit now and going from understanding Monad
laws to using them in real life has been a challenge. Often real world library
Monads are stacked multiple levels and debugging has been particularly
difficult.

Since the Monads chapter in the book was pretty light, I thought I will check
out this paper that was referenced. Re-learning the Monad laws from this paper
inspired me to look at the implementation details of some basic transformers,
which has been very helpful. That said, the paper quickly went over my head
after he started discussing denotational semantics!

I sometimes feel learning Haskell is like learning algebra but just that the
laws are not obvious _to me_. I wish there are more materials that walk you
through more complex implementation (like 3-level stacked Monads) step by step
on how certain things work. I guess once you understand how something works,
it is hard to explain to a beginner who doesn't have much of an understanding
-- much like riding a bike or swimming.

~~~
chadaustin
Personally, I've found monad transformer stacks are more trouble than they're
worth. They're interesting, and probably worth understanding, but in practice
I rarely use much beyond a single ReaderT or StateT.

------
amelius
This passage in section 2.8 must have raised some eyebrows:

> I have to say that I think the GHC approach is a bit of a hack. Why? Because
> it relies for its correctness on the fact that the compiler never duplicates
> a redex.

~~~
ky3
An astute observation, thanks.

It can be restated as: The world-token-state-monad approach to compiling IO
depends on lazy operational semantics to never duplicate redexes.

One consequence is that WTSM makes it more difficult to optimize for space
rather than speed. A program optimized for space might resort to repeating
work. That is, it might duplicate redexes, rather than store the voluminous
results of that work for later sharing.

(If you talk to Oleg Kiselyov he's got HPC war stories about how this form of
DRY-ness isn't the right default. That accounts for his present anti-laziness
bent.)

~~~
tome
AIUI Oleg's complaint is more about the compiler removing redexes or moving
them about, rather than not duplicating them.

~~~
ky3
Redexes are elided for 2 reasons:

1\. Redundant calculation: the result of the redex isn't used. Get rid of it.

2\. The same redex occurs elsewhere. Reuse the result of that instead. Stay
DRY.

Oleg has no problems with 1. Oleg has a beef with 2 because in HPC, the time-
space tradeoff runs counter to ordinary intuition.

