Newest at the top
| 2025-03-25 14:31:38 +0100 | <EvanR> | so eventually I just changed the constructor to Empty |
| 2025-03-25 14:31:34 +0100 | <tomsmeding> | ah :p |
| 2025-03-25 14:31:29 +0100 | <EvanR> | I kept typing Empty into the definitions |
| 2025-03-25 14:31:19 +0100 | <tomsmeding> | what prevented "Nil"? |
| 2025-03-25 14:31:02 +0100 | <EvanR> | I couldn't call Empty "Nil" no matter how hard I tried. And I wanted to call this type NonDeterm but it was too long and numerous |
| 2025-03-25 14:30:40 +0100 | <haskellbridge> | <Liamzee> yeah afaik, monad trans makes no sense without looking at the type definition, i don't think there's a simple rule to predict what the real construction is like until you see it |
| 2025-03-25 14:30:02 +0100 | <EvanR> | https://paste.tomsmeding.com/NAB9RiFP |
| 2025-03-25 14:29:09 +0100 | <EvanR> | but people are probably talking about the type constructors |
| 2025-03-25 14:29:06 +0100 | <tomsmeding> | just expand all the newtypes and write the underlying function directly, dispense with this discussion |
| 2025-03-25 14:28:56 +0100 | <EvanR> | more wrapping |
| 2025-03-25 14:28:53 +0100 | <EvanR> | x, [x], [[x]], [[[x]]] |
| 2025-03-25 14:28:41 +0100 | kh0d | (~kh0d@212.200.247.164) kh0d |
| 2025-03-25 14:28:35 +0100 | <EvanR> | because it sounds like values |
| 2025-03-25 14:28:29 +0100 | <EvanR> | I reject "wrapping" |
| 2025-03-25 14:28:18 +0100 | <EvanR> | MonadBaseControl would have you believe your "stack" is "based" on IO. But by the previous discussion your program underworld is hanging from the IO planetary crust! |
| 2025-03-25 14:28:15 +0100 | <tomsmeding> | IO is not special here |
| 2025-03-25 14:28:10 +0100 | <tomsmeding> | not just with IO, that goes for most (all?) monad transformers |
| 2025-03-25 14:27:53 +0100 | <haskellbridge> | <Liamzee> i guess that's why people say monad transformers are confusing, because the type wrapping of IO doesn't follow the operational wrapping |
| 2025-03-25 14:27:41 +0100 | <tomsmeding> | it's counterproductive to try to stretch it to its limits |
| 2025-03-25 14:27:27 +0100 | <tomsmeding> | the physical analogy only goes so far |
| 2025-03-25 14:27:00 +0100 | <tomsmeding> | and the "body" is on the right |
| 2025-03-25 14:26:50 +0100 | <tomsmeding> | the "right-hand side" of `let x = a in b` is in the middle |
| 2025-03-25 14:26:49 +0100 | <EvanR> | it's underneath that's for sure |
| 2025-03-25 14:26:38 +0100 | kh0d | (~kh0d@212.200.247.164) (Ping timeout: 245 seconds) |
| 2025-03-25 14:26:30 +0100 | <EvanR> | or tower |
| 2025-03-25 14:26:25 +0100 | <EvanR> | is the base inside or outside the building |
| 2025-03-25 14:26:12 +0100 | <EvanR> | (I think) |
| 2025-03-25 14:26:10 +0100 | <EvanR> | inside outside is also getting confused more when you get MonadBaseControl which calls the innermost "the base" |
| 2025-03-25 14:25:56 +0100 | <haskellbridge> | <Liamzee> sorry |
| 2025-03-25 14:25:18 +0100 | <EvanR> | the IO type wraps the product type yes, as far as the types go |
| 2025-03-25 14:25:17 +0100 | <tomsmeding> | even if, operationally, things go weirdly inside out |
| 2025-03-25 14:25:06 +0100 | <tomsmeding> | and as long as you keep the newtypes unexpanded, there's a clear outer/inner in your source text |
| 2025-03-25 14:25:03 +0100 | <EvanR> | "IO wraps the pair" ok now I'm losing it with the burrito analogy, I feel like that might be off the farm |
| 2025-03-25 14:24:52 +0100 | <tomsmeding> | Liamzee: I agree re ridiculousness of inside/outside, but the original question was about intuition about monad transformer stacks _without_ expanding their definitions |
| 2025-03-25 14:24:40 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
| 2025-03-25 14:24:33 +0100 | <haskellbridge> | <Liamzee> then IO wraps the output (a, s) pair |
| 2025-03-25 14:24:22 +0100 | <tomsmeding> | > newtype StateT s m a = StateT { runStateT :: s -> m (a,s) } |
| 2025-03-25 14:24:17 +0100 | <haskellbridge> | <Liamzee> you have a data dependency on state |
| 2025-03-25 14:24:14 +0100 | <EvanR> | s -> (a, IO s) |
| 2025-03-25 14:24:12 +0100 | <haskellbridge> | <Liamzee> how ridiculous the notion of outside and inside can be with some of these monad transformers |
| 2025-03-25 14:24:10 +0100 | <EvanR> | I guess we need to complete all the possibilities |
| 2025-03-25 14:23:54 +0100 | <haskellbridge> | <Liamzee> i just came up with some nonsense versions to try to illustrate |
| 2025-03-25 14:23:48 +0100 | <tomsmeding> | lambdabot just expands the newtypes |
| 2025-03-25 14:23:40 +0100 | <EvanR> | oh it's two versions from Liamzee |
| 2025-03-25 14:23:32 +0100 | <haskellbridge> | <Liamzee> it's lambdabot |
| 2025-03-25 14:23:29 +0100 | <tomsmeding> | to wit, neither of the options that Liamzee just gave are particularly useful in practice |
| 2025-03-25 14:23:24 +0100 | <EvanR> | is the real version of StateT s IO a more like lambdabot or more like Liamzee |
| 2025-03-25 14:22:59 +0100 | <tomsmeding> | that's up to the blog post writer |
| 2025-03-25 14:22:45 +0100 | <haskellbridge> | <Liamzee> in the case provided by lambdabot, is IO beneath state or is state beneath IO? |
| 2025-03-25 14:22:22 +0100 | <haskellbridge> | <Liamzee> IO (s -> (a, s)), s -> (IO a, s) |