Comments on A Neighborhood of Infinity: The Trivial Monad

Thank you! I really, really enjoyed the exercises,...

2011-07-21T01:52:56.372-07:00

Thank you! I really, really enjoyed the exercises, especially proving the Monad laws and writing "join": that was the only one where I got so stuck that I had to write the types out on paper.

Luckily I had the intuition to write out the type for bind, then try to get m (m a) on one side and m a on the other! It was fun.

ur right, and it's an awesome tutorial. sorry ...

2010-05-23T08:59:23.692-07:00

ur right, and it's an awesome tutorial. sorry I didn't say that in the first place!

Matthew, It's cool that people are now identi...

2010-05-22T16:08:09.071-07:00

Matthew,

It's cool that people are now identifying places where they can use Applicative instead of Monad. (Scroll up, you're not the first.) But this is intended as a Monad tutorial. I haven't written an Applicative tutorial yet. :-)

for the 2nd question, defining h, the use of monad...

2010-05-22T15:58:44.196-07:00

for the 2nd question, defining h, the use of monad is overkill (and cumbersome). a discussion of applicative is warranted, since making W an instance of Applicative would allow you to define h quite naturally:

h x y = (+) <$> x <*> y

which looks a lot more like simple addition ((+) x y) than any of the monadic equivalents:

h x y = x >>= \x' -> y >>= y' -> return (x' + y')

@Moritz: In this case, nothing prevents people fro...

2010-04-05T14:05:44.419-07:00

@Moritz: In this case, nothing prevents people from writing an unwrapper, but often the data constructor will not be exported from a module, and so not be visible, as it is here.

typo: We we need to provide

2009-05-27T18:58:47.983-07:00

typo:
We we need to provide

Hi, great post and very helpful in developing an i...

2009-05-19T17:05:19.067-07:00

Hi, great post and very helpful in developing an intuition. One difficulty is that at the point you introduced the exercises, you had defined 'bind' but not (>>=), yet you give the solutions in terms of (>>=).

For exercises 1 and 2, using only functions define...

2008-04-05T21:53:00.000-07:00

For exercises 1 and 2, using only functions defined up to those exercises:

exercise 1:
g x my = fmap (+x) my

exercise 2:
h w1 w2 = bind (\x -> fmap (+x) w2) w1

I have an apologetic blog entry discussing those solutions, the loquacious review process may be helpful to monad neophytes, should they be looking for an alternative approach to the solutions given here.

Thanks, this article has been a huge help. In par...

2008-01-04T18:49:00.000-08:00

Thanks, this article has been a huge help. In particular it has helped clarify the relationship between >>= and composition. I still don't like the syntax of >>= but, I can get around that now. I did suffer some frustration from not understanding that type definitions cannot be entered interactively and wasted a little time getting around that. A little note in the next revision might be of help. Anyway, I look forward to the next installment.

Moritz,

When I talk about managing tainted ...

2007-06-21T20:30:00.000-07:00

Moritz,

When I talk about managing tainted data I'm not describing some kind of secure programming, just as a 'private' member of a C++ class doesn't prevent people accessing private members through pointer trickery. The point is that if you have a block of code that uses only the monad interface you can reason about what data is 'tainted' really easily. You're free to access that data directly, rather than through the monad API. But at that point the useful theorems about monads no longer apply so it's going to be harder to figure out what is and isn't tainted.

What prevents anybody from writing an unwrapper:
2007-06-14T14:13:00.000-07:00
What prevents anybody from writing an unwrapper:

unwrap W x = x

Or something?

I took the long way around with looking up liftM2...

2007-05-01T20:26:00.000-07:00

I took the long way around with looking up liftM2's definition in 'do' syntax, untangling the 'do' notation, then smacking my head for not realizing how to unwrap that first monad. From there it was pretty simple to see how g fit in there.

Monads click with me, thanks in no small part to all these tutorials ... now to learn Monad Transformers, Arrows and Comonads. And fundeps, and GADTs and a Partridge in a Pear Tree... It's weightlifting for the brain, Haskell is.

Chuck,

I only just got around to doing my o...

2007-05-01T13:31:00.000-07:00

Chuck,

I only just got around to doing my own exercises(!!) and I have to admit that they made me pause for a bit. Here's a hint: use 'g' in the definition of 'h'. If you do that then 'h' looks a lot like 'g'.

I'll put the answers in my next blog post - mainly because I'll be using them.

I feel hopelessly stupid, as I've been stuck on de...

2007-05-01T13:26:00.000-07:00

I feel hopelessly stupid, as I've been stuck on defining h for more than an hour now. I even know that :

h = liftM2 (+)

but I'll be damned if I can actually define it from first principles.

> I guess I would be similarly confused by auto...

2007-05-01T12:50:00.000-07:00

> I guess I would be similarly confused by automatic lifting.

So would I. This is why I think it's still a challenge for programming languages. Someone needs to find a way to do this that isn't confusing and still allows explicit control when needed.

I have the paper on my desk. Had to consult it to ...

2007-05-01T12:03:00.000-07:00

I have the paper on my desk. Had to consult it to define <*>. *blush*

Applicative and Traversable are already included in GHC, but I don't know if they are included by the other compilers. It would be a shame if they weren't included in a future set of standard haskell libraries though.

I've skimmed the paper a couple of times, but haven't used the ideas in real code yet. They seem to promise very elegant code. And that, to me, is probably the most important thing with haskell.

Automatically lifted functions and values would be sweet. It could perhaps lead to some obfuscation a la operator overloading in c++. I already feel a bit confused over what >>= does sometimes since it depends on what monad I'm in at the moment. I guess I would be similarly confused by automatic lifting. Then again, perhaps both >>= and automatic lifting are things you just get used to.

Niclas,

'Applicative' is nice. If you dig o...

2007-05-01T11:00:00.000-07:00

Niclas,

'Applicative' is nice. If you dig out the original paper you'll see they propose a great syntax for applicatives, but I don't think it ever made its way into official release of Haskell.

I think the biggest thing waiting to be invented for Haskell is a way to apply things like liftM implicitly. I think 'Applicative' is a step in the right direction.

Thanks for the exercises. Defining h really got me...

2007-05-01T10:53:00.000-07:00

Thanks for the exercises. Defining h really got me to appreciate the functions in Control.Monad, especially the liftM* family =)

The problem with liftM* is, imho, the ugliness of having to use different functions depending on the arity of the lifted function. Perhaps that's what Control.Applicative is for?

instance Applicative W where
pure = return
ff <*> fx = ap ff fx

g x wy = pure (+) <*> pure x <*> wy
h wx wy = pure (+) <*> wx <*> wy

Yes! Beautiful.

Maybe he looked at the source for Control.Monad...

2007-05-01T09:25:00.000-07:00
Maybe he looked at the source for Control.Monad.Identity.

Kevin,

I hope you didn't cheat!

2007-04-30T09:17:00.000-07:00
Kevin,

I hope you didn't cheat!

join m = m >>= id

2007-04-28T13:16:00.000-07:00
join m = m >>= id