Talk:Haskell/Advanced monads

Signature of lookup
The signature of function lookup is given as: lookup :: a       -- a key -> [(a, b)] -- the lookup table to use -> Maybe b -- the result of the lookup

I don't want to be picky here, but perhaps it could be pointed out that 'a' actually has to be an equality type. Furthermore, a simple implementation of lookup could serve a better understanding of that particular example. --Xian 15:43, 18 March 2007 (UTC)

List monad example
I think there is something wrong with this example: getNextConfigs :: Board -> [Board] getNextConfigs = ... -- details not important tick :: [Board] -> [Board] tick bds = concatMap getNextConfigs bd find3rdConfig :: Board -> [Board] find3rdConfig bd = tick $ tick $ tick bd First, tick has an argument "bds" but uses "bd". Second, find3rdConfig calls tick with a Board, but tick needs an argument of type [Board]. Or am I missing something here? --Stw 21:21, 13 August 2006 (UTC)

Possible answer
I would guess that that the example should be corrected as follows:

tick :: [Board] -> [Board] tick bds = concatMap getNextConfigs bds find3rdConfig :: Board -> [Board] find3rdConfig bd = tick $ tick $ tick [bd]

Thanks for pointing this out -- Kowey 07:20, 15 August 2006 (UTC)

Problem with list monad example do-notation implementation of find3rdConfig?
Something doesn't feel right with the do-notation implementation of find3rdConfig. It seems like after each call to getNextConfigs, some kind of flattening (e.g. using concatMap) is necessary.

That is exactly what the list monad does: instance Monad [] where return a = [a] xs >>= f = concat (map f xs) -- Felix C. Stegerman 21:46, 15 June 2007 (UTC)

State Monad
This page implies both that the State monad has "side effects" (which I suppose it does, but not in the traditional sense) and that IO is a special case of State (which, of course, it is not. IO can't even be expressed properly in Haskell, because it has actual, classical side-effects)