Newest at the top
2025-09-28 04:56:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:54:41 +0200 | elnegro | (elnegro@r186-50-77-161.dialup.adsl.anteldata.net.uy) elnegro |
2025-09-28 04:53:10 +0200 | remmie | (ianremsen@tilde.team) (Ping timeout: 244 seconds) |
2025-09-28 04:50:23 +0200 | td_ | (~td@i5387092C.versanet.de) td_ |
2025-09-28 04:48:07 +0200 | td_ | (~td@i53870915.versanet.de) (Ping timeout: 240 seconds) |
2025-09-28 04:46:27 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
2025-09-28 04:45:53 +0200 | <slondr> | Hmm, I agree that this approach seems rather fundamentally flawed, but I feel at the whim of the library here sadly |
2025-09-28 04:45:39 +0200 | xff0x | (~xff0x@2405:6580:b080:900:6b5a:7de1:ba67:bc14) (Ping timeout: 250 seconds) |
2025-09-28 04:45:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
2025-09-28 04:45:36 +0200 | <dcpagan> | How do I safely decrement a type-level natural number? |
2025-09-28 04:45:08 +0200 | <Leary> | Not without `unsafePerformIO`. You probably need to change your approach. |
2025-09-28 04:40:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:39:23 +0200 | <slondr> | is there maybe a way to modify external state without it affecting the return value of the function? I suppose I could rebuild the callback function into something slightly different every time if so |
2025-09-28 04:37:56 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) talismanick |
2025-09-28 04:37:43 +0200 | <slondr> | ah, ok |
2025-09-28 04:37:27 +0200 | <Leary> | If you're in a pure context, the function must do the same thing every time it's called; it can have no internal state. |
2025-09-28 04:37:18 +0200 | <Leary> | In a pure function? No, but in that case you can't do anything with channels either. |
2025-09-28 04:35:42 +0200 | Googulator17 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-28 04:35:39 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) |
2025-09-28 04:32:33 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) (Read error: Connection reset by peer) |
2025-09-28 04:32:22 +0200 | <slondr> | Hmm, can I reference IORefs in a non-IO function? |
2025-09-28 04:30:54 +0200 | trickard_ | (~trickard@cpe-50-98-47-163.wireline.com.au) |
2025-09-28 04:29:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-09-28 04:28:14 +0200 | trickard | (~trickard@cpe-50-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-28 04:27:41 +0200 | <Leary> | slondr: Close over a simple `IORef` instead? E.g. pass in a partially applied `mkCallBack :: IORef YourState -> CallBackType`. |
2025-09-28 04:24:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:21:21 +0200 | remmie | (ianremsen@tilde.team) remsense |
2025-09-28 04:18:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-09-28 04:16:00 +0200 | <slondr> | My first thought was to use forkIO to spawn a separate thread for maintaining state in a simple call/response recursive function, then build my callback function as a closure over a channel to this thread. But that seems like it might be overkill |
2025-09-28 04:14:52 +0200 | <slondr> | as in, I'm passing a callback function to a library, but I want my callback function to accumulate some context each time it's called |
2025-09-28 04:14:50 +0200 | remmie | (ianremsen@tilde.team) (Ping timeout: 248 seconds) |
2025-09-28 04:14:23 +0200 | <slondr> | What's the best way to maintain/mutate state across calls of a function where I can't modify the function signature? |
2025-09-28 04:13:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:10:16 +0200 | banner | (~banner@1.41.210.25) |
2025-09-28 04:07:13 +0200 | trickard_ | trickard |
2025-09-28 04:05:33 +0200 | op_4 | (~tslil@user/op-4/x-9116473) op_4 |
2025-09-28 04:05:04 +0200 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
2025-09-28 04:02:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
2025-09-28 03:57:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 03:56:16 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-09-28 03:51:04 +0200 | Tuplanolla | (~Tuplanoll@91-159-187-167.elisa-laajakaista.fi) (Ping timeout: 255 seconds) |
2025-09-28 03:50:11 +0200 | comonad | (~comonad@p200300d02709a80002b1d060aa1cc9d9.dip0.t-ipconnect.de) |
2025-09-28 03:50:05 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) talismanick |
2025-09-28 03:48:27 +0200 | comonad | (~comonad@p200300d027244d00b442e34853d3dae3.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
2025-09-28 03:46:31 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-09-28 03:42:58 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) (Read error: Connection reset by peer) |
2025-09-28 03:42:42 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
2025-09-28 03:41:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 03:35:41 +0200 | weary-traveler | (~user@user/user363627) user363627 |
2025-09-28 03:30:53 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) talismanick |