5 ms·

Definitely a really neat set of examples. As someone not familiar with Haskell, I have two questions though: 1) What would the method signatures look like in t

Definitely a really neat set of examples. As someone not familiar with Haskell, I have two questions though: 1) What would the method signatures look like in these examples? I.e on the list example, I'm assuming getData would be () -> list(A). And then is getMoreData (A) -> (B) [which gets lifted to list(A) -> list(B)]? 2) How would you combine multiple of these approaches at once? E.g. using both a state monad and a list monad? Would you have to use nested do blocks? Or would you typically define your own custom monad that is a combination of state and list, writing your own lift method, etc.?

thomasahle 9y ago
1) I would asusme `getData :: [a]`, `getMoreData :: a -> [a]` and `getEvenMoreData :: a -> a -> [b]` Notice the type of bind: `(>>=) :: Monad m => m a -> (a -> m b) -> m b`, in our case `m` is list, so the instantiation becomes `(>>=) :: [a] -> (a -> [b]) -> [b]`. (In our case we can also deduce that `a = b`, since the output of `getMoreData` is passed back into `getMoreData`, but that's less important.) A simple example: Prelude> a = \x -> [x,x] Prelude> [1,2] >>= a [1,1,2,2] 2) There is something called Monad Transformers, which does this https://en.wikibooks.org/wiki/Haskell/Monad_transformers https://en.wikibooks.org/wiki/Haskell/Monad_transformers It's not quite as easy as just working with one Monad though, iirc.
marcosdumay 9y ago
GetData is `Maybe a` (what means it's not a function). GetMoreData is `a -> Maybe b`. And so on. What means that those variables do not do what their names are claiming they do. It's a case of an example that lost its meaning once carried to a too different context. By the way, if you are wondering how functions that actually get data would look, there's a great architecture here: http://www.parsonsmatt.org/2016/11/18/clean_alternatives_with_maybet.html http://www.parsonsmatt.org/2016/11/18/clean_alternatives_wit...
legopelle 9y ago
1) Maybe monad getData :: Maybe Data1 getMoreData :: Data1 -> Maybe Data2 Note: the monad is probably not just Maybe if it talks to the outside world but more in 2) List monad getData :: [Data1] getMoreData :: Data1 -> [Data2] Dont' know about continuations. 2) There are a few approaches but the most popular are monad transformers, building stacks to combine the effects. For example, to speak with the outside world we need 'IO'. To add failure we might use the Maybe transformer MaybeT m a to build type IOMaybe a = MaybeT IO a
- chopin 9y ago
  For the list example: I don't get why that loops over the content of the list (I don't understand this in the OP either). Wouldn't it need to be: getMoreData :: [Data1] -> [Data2] at least? As I understand the OP, wouldn't the function signature for the non-monadic example be: getMoreData :: Data1 -> [Data2] and the function body fundamentally different for that reason?

thomasahle 9y ago

1) I would asusme `getData :: [a]`, `getMoreData :: a -> [a]` and `getEvenMoreData :: a -> a -> [b]` Notice the type of bind: `(>>=) :: Monad m => m a -> (a -> m b) -> m b`, in our case `m` is list, so the instantiation becomes `(>>=) :: [a] -> (a -> [b]) -> [b]`. (In our case we can also deduce that `a = b`, since the output of `getMoreData` is passed back into `getMoreData`, but that's less important.) A simple example: Prelude> a = \x -> [x,x] Prelude> [1,2] >>= a [1,1,2,2] 2) There is something called Monad Transformers, which does this https://en.wikibooks.org/wiki/Haskell/Monad_transformers https://en.wikibooks.org/wiki/Haskell/Monad_transformers It's not quite as easy as just working with one Monad though, iirc.

marcosdumay 9y ago

GetData is `Maybe a` (what means it's not a function). GetMoreData is `a -> Maybe b`. And so on. What means that those variables do not do what their names are claiming they do. It's a case of an example that lost its meaning once carried to a too different context. By the way, if you are wondering how functions that actually get data would look, there's a great architecture here: http://www.parsonsmatt.org/2016/11/18/clean_alternatives_with_maybet.html http://www.parsonsmatt.org/2016/11/18/clean_alternatives_wit...

legopelle 9y ago

1) Maybe monad getData :: Maybe Data1 getMoreData :: Data1 -> Maybe Data2 Note: the monad is probably not just Maybe if it talks to the outside world but more in 2) List monad getData :: [Data1] getMoreData :: Data1 -> [Data2] Dont' know about continuations. 2) There are a few approaches but the most popular are monad transformers, building stacks to combine the effects. For example, to speak with the outside world we need 'IO'. To add failure we might use the Maybe transformer MaybeT m a to build type IOMaybe a = MaybeT IO a

chopin 9y ago
For the list example: I don't get why that loops over the content of the list (I don't understand this in the OP either). Wouldn't it need to be: getMoreData :: [Data1] -> [Data2] at least? As I understand the OP, wouldn't the function signature for the non-monadic example be: getMoreData :: Data1 -> [Data2] and the function body fundamentally different for that reason?