Newest at the top
| 2024-05-31 14:21:37 +0200 | <sshine> | lxsameer, https://play.haskell.org/saved/nnUbuaAA -- I don't know if this is a good example. |
| 2024-05-31 14:14:19 +0200 | xff0x | (~xff0x@2405:6580:b080:900:75ce:7dd6:5a9:4d8a) |
| 2024-05-31 14:12:39 +0200 | <lxsameer> | thanks for you time and clarifications |
| 2024-05-31 14:12:29 +0200 | <lxsameer> | I have to read it more |
| 2024-05-31 14:12:22 +0200 | <lxsameer> | I think I got it :P |
| 2024-05-31 14:12:14 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 256 seconds) |
| 2024-05-31 14:12:13 +0200 | <lxsameer> | ah got it |
| 2024-05-31 14:12:02 +0200 | <ncf> | m :: ((->) XConf) XConf |
| 2024-05-31 14:11:40 +0200 | <lxsameer> | and the compiler would know what implementation of `ask` to use because `m :: XConf` right? |
| 2024-05-31 14:11:30 +0200 | <ncf> | runX is just doing this with a few newtype wrappers in between (and more monads in the stack) |
| 2024-05-31 14:11:03 +0200 | <ncf> | the actual value of c isn't determined until i actually run m by applying it to an XConf |
| 2024-05-31 14:10:35 +0200 | <ncf> | so, if i write something like `m = (do c <- ask; return c) :: XConf -> XConf`, i am describing a computation that takes an XConf and just returns it unchanged |
| 2024-05-31 14:09:25 +0200 | <ncf> | ask :: XConf -> XConf is just the identity function |
| 2024-05-31 14:09:06 +0200 | <ncf> | (>>=) :: (XConf -> a) -> (a -> XConf -> b) -> XConf -> b chains computations together by duplicating the environment |
| 2024-05-31 14:08:59 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2024-05-31 14:08:27 +0200 | <ncf> | return :: a -> XConf -> a is just the `const` function that ignores the XConf argument |
| 2024-05-31 14:08:21 +0200 | zer0bitz_ | (~zer0bitz@user/zer0bitz) |
| 2024-05-31 14:08:01 +0200 | <ncf> | this is a monad that describes computations that *depend* on a global environment value of type XConf, i.e. aren't fully determined until you give them an XConf |
| 2024-05-31 14:07:28 +0200 | <ncf> | maybe it would help to think about the native reader monad, ((->) XConf) |
| 2024-05-31 14:06:15 +0200 | <lxsameer> | so that's why I'm confused then |
| 2024-05-31 14:06:08 +0200 | <lxsameer> | ahhhhhh |
| 2024-05-31 14:05:47 +0200 | <ncf> | no! |
| 2024-05-31 14:05:44 +0200 | <lxsameer> | runX in the catchX? |
| 2024-05-31 14:05:25 +0200 | <ncf> | the environment provided to runX |
| 2024-05-31 14:05:01 +0200 | <lxsameer> | but where does ask takes the value from? |
| 2024-05-31 14:04:49 +0200 | <lxsameer> | getChar reads from stdin for example |
| 2024-05-31 14:04:34 +0200 | <lxsameer> | ncf: i understand that part but |
| 2024-05-31 14:04:11 +0200 | <ncf> | this is only determined when you actually run the catchX call, so when you call runX on some action that uses catchX |
| 2024-05-31 14:03:48 +0200 | <ncf> | so in the same way, the value of c here is the result of the "ask" action |
| 2024-05-31 14:03:34 +0200 | <ncf> | right |
| 2024-05-31 14:03:28 +0200 | <lxsameer> | ther result of getChar action |
| 2024-05-31 14:03:11 +0200 | <ncf> | lxsameer: think about IO; if i write `do c <- getChar; print c`, what value does c have? |
| 2024-05-31 14:02:51 +0200 | <ncf> | or irrelevant |
| 2024-05-31 14:02:47 +0200 | <lxsameer> | I don't understand how `c` can have a value here |
| 2024-05-31 14:02:47 +0200 | <Leary> | The `runX` in `catchX` is an inner, nested call; it's irrelevant. The greater X action is executed by some outer `runX` that supplies the `XConf` argument. |
| 2024-05-31 14:02:46 +0200 | <ncf> | oh, there's a runX on the next line. ignore that, that's irreleveant |
| 2024-05-31 14:02:30 +0200 | <lxsameer> | execution order i mean |
| 2024-05-31 14:02:24 +0200 | <lxsameer> | ncf: I guess I'm confused with the order here |
| 2024-05-31 14:01:05 +0200 | <ncf> | i am not sure what you mean by that |
| 2024-05-31 14:00:32 +0200 | <lxsameer> | ncf: I read runReaderT. The c <- ask runs before the runX in this example, am i correct? |
| 2024-05-31 14:00:31 +0200 | <ncf> | lxsameer: ask is used in an X computation so m gets resolved to X, and it returns an XConf so r gets resolved to XConf |
| 2024-05-31 14:00:00 +0200 | <ncf> | (well, runX) |
| 2024-05-31 13:59:11 +0200 | <lxsameer> | ncf: is it because of an specialization ? I mean X XConf |
| 2024-05-31 13:59:08 +0200 | <ncf> | see runReaderT |
| 2024-05-31 13:58:59 +0200 | <ncf> | ...at runtime, when you actually run the X action |
| 2024-05-31 13:58:37 +0200 | <lxsameer> | and where does the value of XConf resolved here |
| 2024-05-31 13:58:33 +0200 | <ncf> | since you have MonadReader XConf X |
| 2024-05-31 13:58:27 +0200 | <ncf> | so in this case ask :: X XConf |
| 2024-05-31 13:58:12 +0200 | <lxsameer> | how does that translates to XConf here |
| 2024-05-31 13:58:10 +0200 | <ncf> | the ask used there is ask :: MonadReader r m => m r |