Newest at the top
| 2025-10-15 13:32:37 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-10-15 13:32:17 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-10-15 13:31:08 +0200 | <dminuoso> | I usually use it for optparse-applicative. |
| 2025-10-15 13:30:55 +0200 | sajenim | (~sajenim@user/sajenim) (Ping timeout: 265 seconds) |
| 2025-10-15 13:30:39 +0200 | <tomsmeding> | I never use ApplicativeDo |
| 2025-10-15 13:30:21 +0200 | <dminuoso> | tomsmeding: Who knows, I've experienced so many ApplicativeDo -> Monad degradations in the past. |
| 2025-10-15 13:30:19 +0200 | <tomsmeding> | https://play.haskell.org/saved/9myEpOls |
| 2025-10-15 13:30:03 +0200 | <dminuoso> | An example like this should work more easily |
| 2025-10-15 13:30:03 +0200 | <tomsmeding> | works for me though |
| 2025-10-15 13:29:26 +0200 | <dminuoso> | Sometimes I wonder whether a `doA` with an explicit error instead of silent monad degradation would have been better. |
| 2025-10-15 13:28:46 +0200 | <dminuoso> | tomsmeding: But perfectly in line with how frequently ApplicativeDo fails. Not that it should. |
| 2025-10-15 13:28:23 +0200 | <tomsmeding> | okay that's weird |
| 2025-10-15 13:28:17 +0200 | <tomsmeding> | _right_ |
| 2025-10-15 13:28:13 +0200 | <dminuoso> | tomsmeding: Given the mention of runA I think they wanted it in the inner one. |
| 2025-10-15 13:27:51 +0200 | <tomsmeding> | I was assuming that the ApplicativeDo is supposed to apply to the outer do |
| 2025-10-15 13:27:38 +0200 | tromp | (~textual@2001:1c00:3487:1b00:cdf:654a:2a7f:261) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-10-15 13:27:35 +0200 | <dminuoso> | Lets ignore the outer do notation for a second. |
| 2025-10-15 13:27:26 +0200 | <dminuoso> | tomsmeding: That's not related. |
| 2025-10-15 13:27:10 +0200 | <tomsmeding> | how would you write that in applicative combinators? |
| 2025-10-15 13:27:04 +0200 | <tomsmeding> | do { x <- foo; y <- f x; return (g x y) } |
| 2025-10-15 13:26:47 +0200 | <dminuoso> | But because its the outer do-notation, as far as the inner do-notation is concerned is just some variable. |
| 2025-10-15 13:26:31 +0200 | <dminuoso> | I mean it may be that there is a very naive heuristic that just looks at x and sees that its bound in do-notation. |
| 2025-10-15 13:26:05 +0200 | <dminuoso> | Even then, I dont see why |
| 2025-10-15 13:26:03 +0200 | <tomsmeding> | yeah |
| 2025-10-15 13:25:56 +0200 | <tomsmeding> | I think? |
| 2025-10-15 13:25:48 +0200 | <tomsmeding> | if the 'return y' also referenced x, then we'd be in trouble |
| 2025-10-15 13:25:18 +0200 | <tomsmeding> | (\x -> ...) <$> foo |
| 2025-10-15 13:25:00 +0200 | <tomsmeding> | ... fair point |
| 2025-10-15 13:24:52 +0200 | <dminuoso> | So? |
| 2025-10-15 13:24:47 +0200 | <tomsmeding> | dminuoso: well the x is bound in the outer do |
| 2025-10-15 13:24:31 +0200 | <dminuoso> | tomsmeding: Regarding ApplicativeDo, Im not sure how `bar x` would be an issue - function application by itself is not forbidden inside ApplicativeDo. |
| 2025-10-15 13:22:12 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-10-15 13:16:13 +0200 | <tomsmeding> | (I actually have `:set prompt "\ESC[1m\STX%s>\ESC[0m\STX "` to make the prompt more visible, too) |
| 2025-10-15 13:15:26 +0200 | <tomsmeding> | also on :r it re-adds that first-module-in-the-component back into the scope list |
| 2025-10-15 13:15:00 +0200 | <tomsmeding> | in GHC 9.0 the default changed away from that and I hate it |
| 2025-10-15 13:14:48 +0200 | <tomsmeding> | also, in case it's helpful: try `:set prompt "%s> "` to always show what modules are currently in scope |
| 2025-10-15 13:14:01 +0200 | <tomsmeding> | titusg: cabal repl loads the first module listed in the cabal file for that component |
| 2025-10-15 13:09:04 +0200 | xff0x | (~xff0x@2405:6580:b080:900:3bfc:a749:138a:b4ac) |
| 2025-10-15 13:06:37 +0200 | <[exa]> | yeah I never used it but looks like you can just stuff custom commands to a local .ghci |
| 2025-10-15 13:05:25 +0200 | <titusg> | thx for finding that, I'll have a play :) |
| 2025-10-15 13:04:09 +0200 | <titusg> | fair enough. I'm usually just wanting to play around with the code I'm working on... |
| 2025-10-15 13:04:02 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-10-15 13:03:41 +0200 | <[exa]> | maybe something like this? https://discourse.haskell.org/t/define-custom-command-for-a-cabal-repl-session/12088/2 |
| 2025-10-15 13:02:39 +0200 | <[exa]> | anyway there's a way to do that iirc, I saw it somewhere |
| 2025-10-15 13:02:19 +0200 | <[exa]> | (also the modules may conflict in the namespace) |
| 2025-10-15 13:01:59 +0200 | <[exa]> | titusg: I'm usually doing it to try some stuff with the package environment, not necessarily the modules |
| 2025-10-15 13:01:42 +0200 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-10-15 12:58:27 +0200 | koz | (~koz@121.99.240.58) |
| 2025-10-15 12:58:05 +0200 | halloy7365 | (~halloy736@2404:4400:5446:4e00:b445:d572:a953:7834) (Quit: halloy7365) |
| 2025-10-15 12:54:08 +0200 | koz | (~koz@121.99.240.58) (Ping timeout: 256 seconds) |