2025/03/25

Newest at the top

2025-03-25 14:35:19 +0100kuribas`(~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3))
2025-03-25 14:35:10 +0100 <EvanR> new NonDeterm a = NonDeterm { getPossibilities :: [a] }
2025-03-25 14:35:05 +0100bliminse(~bliminse@user/bliminse) bliminse
2025-03-25 14:34:51 +0100 <EvanR> gratuitous newtype
2025-03-25 14:34:29 +0100 <EvanR> lol
2025-03-25 14:34:11 +0100 <tomsmeding> just ignore the GHC warning
2025-03-25 14:34:08 +0100 <tomsmeding> EvanR: if you put the 'empty' pattern-matching case last, i.e. after the Cons case, then it does work
2025-03-25 14:32:32 +0100 <EvanR> probably for the best
2025-03-25 14:32:24 +0100 <tomsmeding> ah, no
2025-03-25 14:32:19 +0100 <EvanR> but it's being pattern matched, does it work as a pattern
2025-03-25 14:32:02 +0100 <tomsmeding> and with an Alternative instance, it could even be 'empty'
2025-03-25 14:31:49 +0100 <tomsmeding> if you define Semigroup and Monoid instances then you can type 'mempty' instead
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 +0100kh0d(~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 +0100kh0d(~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 +0100CiaoSen(~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