Newest at the top
| 2025-03-25 13:11:13 +0100 | <tomsmeding> | newtype M a = M (s -> (Either e a, s)) deriving (Functor, Applicative, Monad, MonadState s, MonadExcept e) via (ExceptT e (State s) a) |
| 2025-03-25 13:10:43 +0100 | <tomsmeding> | there's a trick I found out a while ago: if you're okay with accessing your monad through mtl classes, then you can use DerivingVia to document what you're doing |
| 2025-03-25 13:10:32 +0100 | <[exa]> | I think |
| 2025-03-25 13:10:28 +0100 | <[exa]> | technically you were right but it just does the other thing |
| 2025-03-25 13:10:03 +0100 | tomsmeding | hides in a corner |
| 2025-03-25 13:09:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-25 13:09:57 +0100 | <[exa]> | you see, it's friggin confusing |
| 2025-03-25 13:09:54 +0100 | kh0d | (~kh0d@212.200.247.164) (Remote host closed the connection) |
| 2025-03-25 13:09:53 +0100 | <tomsmeding> | disregard all that I say |
| 2025-03-25 13:09:48 +0100 | <tomsmeding> | I'm wrong |
| 2025-03-25 13:09:42 +0100 | <lambdabot> | s -> (Either e a, s) |
| 2025-03-25 13:09:42 +0100 | <tomsmeding> | @unmtl ExceptT e (State s) a |
| 2025-03-25 13:09:40 +0100 | <lambdabot> | err: `ExceptT e (State s)' is not applied to enough arguments, giving `/\A. s -> (Either e A, s)' |
| 2025-03-25 13:09:40 +0100 | <tomsmeding> | @unmtl ExceptT e (State s) |
| 2025-03-25 13:09:28 +0100 | <tomsmeding> | with ExceptT e (State s), you run the ExceptT to _maybe_ get a State out |
| 2025-03-25 13:09:04 +0100 | <tomsmeding> | this is most clear with State and Except -- with StateT s (Except e), you run the state monad and then get an Except out, i.e. you get a state irrespective of whether there was an exception |
| 2025-03-25 13:08:01 +0100 | <tomsmeding> | without having to look at the precise implementation of the monad data types |
| 2025-03-25 13:07:46 +0100 | <tomsmeding> | this indirectly tells you what the actual semantics of your stack is |
| 2025-03-25 13:07:27 +0100 | <tomsmeding> | whereas if you have a ParserT (State s), you'll run the parser and get something in the state monad back |
| 2025-03-25 13:07:16 +0100 | <tomsmeding> | it's still doing the same thing in the end, but you can think about the eliminator functions: if you have a StateT s Parser, then you'll runStateT and get something in the Parser monad |
| 2025-03-25 13:06:29 +0100 | <[exa]> | tomsmeding: yeah that's what I kinda do in head and want to have a shortcut around it |
| 2025-03-25 13:05:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-25 13:04:24 +0100 | <lambdabot> | err: Parse error: ; |
| 2025-03-25 13:04:24 +0100 | <tomsmeding> | @unmtl |
| 2025-03-25 12:59:59 +0100 | pdw | (~user@215.156.62.185.bridgefibre.net) pdw |
| 2025-03-25 12:57:16 +0100 | <[exa]> | I always have to look at the implementation to just be sure |
| 2025-03-25 12:57:02 +0100 | <[exa]> | gah, is there some easily rememberable rule of thumb for monad transformer order? I.e., how to instinctively know whether one wants `StateT s Parser` or `ParserT (State s)` |
| 2025-03-25 12:56:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-25 12:56:00 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2025-03-25 12:51:23 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-03-25 12:50:24 +0100 | kh0d | (~kh0d@212.200.247.164) kh0d |
| 2025-03-25 12:46:36 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-03-25 12:44:19 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-25 12:43:17 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 248 seconds) |
| 2025-03-25 12:36:41 +0100 | humasect | (~humasect@dyn-192-249-132-2.nexicom.net) (Quit: Leaving...) |
| 2025-03-25 12:36:06 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-03-25 12:32:08 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 268 seconds) |
| 2025-03-25 12:30:04 +0100 | orslon^ | (dehsou@c-71-199-187-173.hsd1.ga.comcast.net) |
| 2025-03-25 12:29:57 +0100 | orslon^ | (orslon@c-71-199-187-173.hsd1.ga.comcast.net) (Ping timeout: 248 seconds) |
| 2025-03-25 12:28:21 +0100 | kuribas | (~user@2a02:1808:43:dbd9:6ca7:205b:89ae:6340) (Ping timeout: 248 seconds) |
| 2025-03-25 12:26:36 +0100 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-03-25 12:24:37 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-25 12:24:02 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f588:30f2:ad44:5069) |
| 2025-03-25 12:20:03 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-25 12:17:03 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-03-25 12:16:52 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-25 12:04:41 +0100 | yaroot | (~yaroot@p3747022-ipxg13101souka.saitama.ocn.ne.jp) yaroot |
| 2025-03-25 12:04:27 +0100 | yaroot | (~yaroot@2400:4052:ac0:d901:1cf4:2aff:fe51:c04c) (Read error: Connection reset by peer) |
| 2025-03-25 12:02:16 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-25 12:00:05 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |