| 2024-10-03 00:01:09 +0200 | <haskellbridge> | <sm> "hell" on HN: https://news.ycombinator.com/item?id=41694767 |
| 2024-10-03 00:01:34 +0200 | <probie> | % let{f x=print x>>pure x;tleft=fmap($ []).foldr(\x k -> liftA2(flip(.))k(fmap(:)x))(pure$id)}in tleft $ map f [1..5] -- Probably worse than two reverses because it spills the list to the stack |
| 2024-10-03 00:01:34 +0200 | <yahb2> | 5 ; 4 ; 3 ; 2 ; 1 ; [1,2,3,4,5] |
| 2024-10-03 00:02:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 00:05:57 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-03 00:12:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 00:17:16 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) (Ping timeout: 244 seconds) |
| 2024-10-03 00:17:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 00:18:49 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-10-03 00:23:16 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-10-03 00:24:27 +0200 | codaraxis | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 00:28:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 00:33:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 00:33:44 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-10-03 00:34:33 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-10-03 00:37:12 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds) |
| 2024-10-03 00:39:31 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-10-03 00:42:03 +0200 | notzmv | (~daniel@user/notzmv) (Read error: Connection reset by peer) |
| 2024-10-03 00:43:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 00:45:31 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) (Ping timeout: 256 seconds) |
| 2024-10-03 00:48:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-10-03 00:50:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-03 00:55:08 +0200 | troojg | (~troojg@user/troojg) troojg |
| 2024-10-03 00:57:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 01:00:45 +0200 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en |
| 2024-10-03 01:00:50 +0200 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit) |
| 2024-10-03 01:02:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 01:12:43 +0200 | <c_wraith> | does STM document its consistency properties anywhere? istr it's the equivalent of read-committed, rather than fully linearizable? |
| 2024-10-03 01:13:15 +0200 | supercode | (~supercode@user/supercode) supercode |
| 2024-10-03 01:13:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 01:18:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 01:20:05 +0200 | <mauke> | what's the difference? |
| 2024-10-03 01:23:36 +0200 | <geekosaur> | I think it might be only by reference (there's a paper from Intel Research describing it) |
| 2024-10-03 01:24:38 +0200 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2024-10-03 01:24:56 +0200 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu |
| 2024-10-03 01:29:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 01:30:07 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 244 seconds) |
| 2024-10-03 01:30:56 +0200 | <c_wraith> | mauke: with read-committed you can read a set of values that never would have existed together if all transactions were serialized. |
| 2024-10-03 01:32:30 +0200 | <geekosaur> | I don't think you can get into that situation with STM; the only such sets wouldn't be observable, because anything that could observe them would be forced to `retry` and end up with a consistent set? |
| 2024-10-03 01:32:34 +0200 | xff0x | (~xff0x@2405:6580:b080:900:409b:fd54:4c14:6dc) (Ping timeout: 260 seconds) |
| 2024-10-03 01:33:15 +0200 | <c_wraith> | hmm. possibly so. I tried a few traces that typically show that, and they did all retry with STM semantics. |
| 2024-10-03 01:33:18 +0200 | <geekosaur> | something observing program state from outside could potentially see such states |
| 2024-10-03 01:33:47 +0200 | <c_wraith> | well, something observing from the outside can see all kinds of stuff with STM |
| 2024-10-03 01:33:52 +0200 | <geekosaur> | yep |
| 2024-10-03 01:34:11 +0200 | <geekosaur> | this should all be covered in the Intel paper |
| 2024-10-03 01:34:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 01:40:21 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) neuroevolutus |
| 2024-10-03 01:45:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 01:45:13 +0200 | xff0x | (~xff0x@2405:6580:b080:900:409b:fd54:4c14:6dc) |
| 2024-10-03 01:46:43 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) (Ping timeout: 256 seconds) |
| 2024-10-03 01:49:32 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-10-03 01:49:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 01:55:28 +0200 | <Lears> | c_wraith: <https://www.microsoft.com/en-us/research/wp-content/uploads/2005/01/2005-ppopp-composable.pdf> (linked indirectly from Control.Concurrent.STM) is /the/ STM paper if GHC's particular form/extension of STM is what you're interested in. I imagine it has the answer you're looking for, though I'd be very surprised if such states were observable. |
| 2024-10-03 01:55:48 +0200 | <dolio> | c_wraith: Yeah, that's true. |
| 2024-10-03 01:56:06 +0200 | <c_wraith> | ugh, why did my irc client think the > is part of the link? bad client! |
| 2024-10-03 01:56:26 +0200 | <dolio> | This is discussed in Revisting Software Transactional Memory in Haskell. |
| 2024-10-03 01:56:31 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3118-adab-ad64-111d-10db-8d9d.rev.sfr.net) (Remote host closed the connection) |
| 2024-10-03 01:57:42 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3118-adab-f186-fae0-9a30-1276.rev.sfr.net) alexherbo2 |
| 2024-10-03 02:00:09 +0200 | <dolio> | Oh, I guess unless the implementation in that paper has since replaced the original implementation in GHC, because the one in that paper does ensure every transaction sees a consistent memory state (I think). |
| 2024-10-03 02:00:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 02:01:14 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3118-adab-f186-fae0-9a30-1276.rev.sfr.net) (Remote host closed the connection) |
| 2024-10-03 02:01:46 +0200 | <dolio> | They call the property that ensures that, 'opacity.' |
| 2024-10-03 02:03:57 +0200 | <c_wraith> | I'm just getting there in the paper... |
| 2024-10-03 02:04:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 02:04:55 +0200 | <c_wraith> | it would be nice to know if GHC switched inplemrntations |
| 2024-10-03 02:05:04 +0200 | <dolio> | Yeah. That I don't know. |
| 2024-10-03 02:08:51 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 276 seconds) |
| 2024-10-03 02:12:23 +0200 | supercode | (~supercode@user/supercode) (Quit: Client closed) |
| 2024-10-03 02:15:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 02:22:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-10-03 02:27:52 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-03 02:32:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 02:37:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 02:43:00 +0200 | nkatte | (~nkatte@191.177.174.42) (Quit: nkatte) |
| 2024-10-03 02:44:11 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-03 02:45:41 +0200 | xff0x | (~xff0x@2405:6580:b080:900:409b:fd54:4c14:6dc) (Ping timeout: 248 seconds) |
| 2024-10-03 02:48:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 02:50:03 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb85cd0cf194bbc9b0a3.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2024-10-03 02:55:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 02:55:12 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-10-03 03:01:32 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 272 seconds) |
| 2024-10-03 03:06:11 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2024-10-03 03:06:17 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 03:06:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 03:11:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 03:12:07 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-10-03 03:21:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 03:27:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 03:33:06 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 246 seconds) |
| 2024-10-03 03:38:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 03:42:13 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-10-03 03:42:24 +0200 | shailangsa | (~shailangs@host86-182-139-82.range86-182.btcentralplus.com) shailangsa |
| 2024-10-03 03:43:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 03:47:05 +0200 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2024-10-03 03:50:10 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) athan |
| 2024-10-03 03:54:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 03:58:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 04:09:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 04:14:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 04:19:25 +0200 | td_ | (~td@i5387093C.versanet.de) (Ping timeout: 265 seconds) |
| 2024-10-03 04:20:56 +0200 | td_ | (~td@i5387091A.versanet.de) td_ |
| 2024-10-03 04:25:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 04:26:46 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 04:29:40 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-10-03 04:29:54 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2024-10-03 04:29:54 +0200 | Digit | (~user@user/digit) (Ping timeout: 260 seconds) |
| 2024-10-03 04:29:54 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (Ping timeout: 260 seconds) |
| 2024-10-03 04:30:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 04:31:17 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) lambdabot |
| 2024-10-03 04:31:17 +0200 | ChanServ | +v lambdabot |
| 2024-10-03 04:34:48 +0200 | identity | (~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-10-03 04:36:07 +0200 | Digitteknohippie | Digit |
| 2024-10-03 04:40:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 04:43:35 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-10-03 04:45:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 04:49:26 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-10-03 04:51:07 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) neuroevolutus |
| 2024-10-03 04:51:29 +0200 | komikat | (~user@218.185.248.66) (Ping timeout: 260 seconds) |
| 2024-10-03 04:56:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 04:56:33 +0200 | neuroevolutus | (~neuroevol@37.19.200.152) (Ping timeout: 256 seconds) |
| 2024-10-03 04:56:46 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) neuroevolutus |
| 2024-10-03 05:01:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 05:06:13 +0200 | zmt01 | (~zmt00@user/zmt00) zmt00 |
| 2024-10-03 05:10:13 +0200 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 248 seconds) |
| 2024-10-03 05:12:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 05:17:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 05:19:32 +0200 | aforemny_ | (~aforemny@i59F4C77A.versanet.de) aforemny |
| 2024-10-03 05:20:48 +0200 | aforemny | (~aforemny@2001:9e8:6cd7:c200:342e:20f9:8752:4727) (Ping timeout: 265 seconds) |
| 2024-10-03 05:26:03 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-10-03 05:28:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 05:32:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 05:41:39 +0200 | billchenchina- | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) billchenchina |
| 2024-10-03 05:43:18 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2024-10-03 05:43:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 05:44:18 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-10-03 05:45:47 +0200 | <haskellbridge> | <thirdofmay18081814goya> can all problems regarding whether or not a computable function terminates be reduced to a logic program? |
| 2024-10-03 05:47:00 +0200 | <EvanR> | is it even a computable function if it doesn't terminate |
| 2024-10-03 05:47:09 +0200 | <EvanR> | for some inputs |
| 2024-10-03 05:47:39 +0200 | <EvanR> | if not, that makes some undecidable problems computable |
| 2024-10-03 05:48:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-10-03 05:49:49 +0200 | <haskellbridge> | <thirdofmay18081814goya> EvanR: yeah I think termination and computability are distinct things |
| 2024-10-03 05:50:00 +0200 | <EvanR> | :thonk: |
| 2024-10-03 05:50:13 +0200 | <EvanR> | not saying they are the same |
| 2024-10-03 05:51:54 +0200 | pavonia | (~user@user/siracusa) siracusa |
| 2024-10-03 05:51:59 +0200 | <haskellbridge> | <thirdofmay18081814goya> i mean i think they are independent from one another, and termination or non-termination is a property of computable functions |
| 2024-10-03 05:52:56 +0200 | <EvanR> | a mathematical function from integers to integers is computable if there's an algorithm which can implement this function, so non-termination wouldn't come up here because of the codomain in the premise |
| 2024-10-03 05:53:16 +0200 | <EvanR> | these functions wouldn't be missing any answers, and so an non-termination would be a failure to implement |
| 2024-10-03 05:53:42 +0200 | <EvanR> | any* non-termination |
| 2024-10-03 05:54:21 +0200 | <Lears> | thirdofmay: Computable functions are mathematical functions; they have no inherent notion of implementation or termination; they're defined at every argument. |
| 2024-10-03 05:54:34 +0200 | <Lears> | You probably want the "general recursive functions". |
| 2024-10-03 05:55:50 +0200 | <Lears> | "reduced to a logic program" is also unclear. |
| 2024-10-03 05:55:54 +0200 | <EvanR> | you could posit a mathematical function into a space that includes an additional bottom value |
| 2024-10-03 05:56:07 +0200 | <EvanR> | but I figured that'd be weird |
| 2024-10-03 05:56:48 +0200 | <EvanR> | and use a convention that "computing the bottom" means the algorithm provably freezes up xD |
| 2024-10-03 05:57:12 +0200 | <EvanR> | haskell maths |
| 2024-10-03 05:58:30 +0200 | <haskellbridge> | <thirdofmay18081814goya> ty for ref |
| 2024-10-03 05:58:50 +0200 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2024-10-03 05:59:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:00:48 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 246 seconds) |
| 2024-10-03 06:01:10 +0200 | cyphase | (~cyphase@user/cyphase) cyphase |
| 2024-10-03 06:02:30 +0200 | mud | (~mud@user/kadoban) kadoban |
| 2024-10-03 06:03:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 06:06:56 +0200 | mud | (~mud@user/kadoban) (Client Quit) |
| 2024-10-03 06:08:21 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-03 06:10:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:10:25 +0200 | mud | (~mud@user/kadoban) kadoban |
| 2024-10-03 06:12:45 +0200 | Tisoxin | (~Ikosit@user/ikosit) Ikosit |
| 2024-10-03 06:14:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-10-03 06:15:59 +0200 | amano | (amano@gateway/vpn/airvpn/amano) amano |
| 2024-10-03 06:16:36 +0200 | <amano> | Let's assume StateT (DataType a) m a. Can StateT replace DataType a with DataType b? |
| 2024-10-03 06:17:10 +0200 | <amano> | I mean StateT (DataType a) m () |
| 2024-10-03 06:20:37 +0200 | <Lears> | :t StateT |
| 2024-10-03 06:20:38 +0200 | <lambdabot> | (s -> m (a, s)) -> StateT s m a |
| 2024-10-03 06:20:41 +0200 | <c_wraith> | nothing in mtl/transformers provides that. mmorph doesn't seem to provide that. lens *does*, as part of the Zoom interface. |
| 2024-10-03 06:21:20 +0200 | <c_wraith> | the trick, and why it appears in lens, is that the transformation needs to be bidirectional |
| 2024-10-03 06:21:51 +0200 | <amano> | Then, I have to use existential typeclass in a data type? |
| 2024-10-03 06:22:19 +0200 | <c_wraith> | uh, not sure what you mean by that. |
| 2024-10-03 06:22:32 +0200 | <Lears> | StateT uses the same type for the input state as the output state; so not unless you change both. If you lift this restriction with your own StateT', then you cannot make it a Monad, though you can make it an indexed monad. |
| 2024-10-03 06:23:01 +0200 | <Lears> | If the type parameter to `DataType` is recoverable, then yes, it's simplest just to hide it with `Some DataType`. |
| 2024-10-03 06:23:23 +0200 | <c_wraith> | I just mean that in (s -> m (a, s)), s appears in both positive and negative position. This means it's not covariant or contravariant - you can't map it simply. |
| 2024-10-03 06:23:42 +0200 | <c_wraith> | Lens is all about bidirectional mapping, so it handles that case relatively easily. |
| 2024-10-03 06:25:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:26:29 +0200 | <amano> | I mean data SomeType = forall a. TypeClass a => SomeType a |
| 2024-10-03 06:26:33 +0200 | <amano> | This is existential typeclass |
| 2024-10-03 06:27:11 +0200 | <c_wraith> | and it's kinda useless. |
| 2024-10-03 06:27:16 +0200 | <amano> | Why? |
| 2024-10-03 06:27:41 +0200 | <amano> | This is the only way I know to use multiple typeclass instances in StateT. |
| 2024-10-03 06:27:44 +0200 | <c_wraith> | it's no different from just passing around a function, or a record of them. |
| 2024-10-03 06:28:03 +0200 | <amano> | I know it can be represented as a record of functions.... |
| 2024-10-03 06:28:11 +0200 | <amano> | But, I prefer existential typeclass... |
| 2024-10-03 06:28:48 +0200 | <Lears> | I don't know why there's a class involved here at all? All you need is `data Some f = forall a. Some (f a)`. |
| 2024-10-03 06:29:20 +0200 | <dmj`> | * uses existential to solve problem, now has two problems * |
| 2024-10-03 06:29:21 +0200 | <amano> | What is f? |
| 2024-10-03 06:29:31 +0200 | <Lears> | `DataType` |
| 2024-10-03 06:29:58 +0200 | <amano> | I need `a` to be a typeclass instance. |
| 2024-10-03 06:30:17 +0200 | <amano> | I need to call a few functions on `a`. |
| 2024-10-03 06:30:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 06:30:36 +0200 | <amano> | You can write functions without a typeclass, but a typeclass makes it formal. |
| 2024-10-03 06:30:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:34:32 +0200 | <amano> | Sometimes, existential typeclass seems to be the right way. |
| 2024-10-03 06:34:46 +0200 | <c_wraith> | It's only ever added complexity when I've used it |
| 2024-10-03 06:35:09 +0200 | <amano> | But, polymorphism can split a giant case statement into tiny ones. |
| 2024-10-03 06:35:30 +0200 | <amano> | StateT is involved, so I have to hide polymorphism in an existential data type. |
| 2024-10-03 06:35:49 +0200 | <amano> | Right now, I have a big sum type.... |
| 2024-10-03 06:35:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 06:36:07 +0200 | <amano> | A big sum type requires a giant case statement or a long list of pattern match statements. |
| 2024-10-03 06:36:25 +0200 | <amano> | Polymorphism splits a giant case statement into multiple modules. |
| 2024-10-03 06:37:00 +0200 | <amano> | Polymorphism unentangles a giant sum type. |
| 2024-10-03 06:37:08 +0200 | <jackdk> | Would you be able to help me take a step back from the Haskell features you're considering to solve your problem, and help me understand the problem you're trying to solve? |
| 2024-10-03 06:37:12 +0200 | <dmj`> | sounds like you're using existentials to avoid more typing |
| 2024-10-03 06:37:14 +0200 | <amano> | Simplicity results from pulling things apart. |
| 2024-10-03 06:37:16 +0200 | <c_wraith> | When you're taking an operation-oriented viewpoint, I prefer to focus on the operations. Not some fake data type designed to hide them. |
| 2024-10-03 06:37:39 +0200 | <amano> | dmj`: There is no other type that allows polymorphism in StateT. |
| 2024-10-03 06:37:59 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-10-03 06:38:11 +0200 | <amano> | I can't eliminate StateT because I'm using someone else's library which is used by many people. |
| 2024-10-03 06:38:57 +0200 | <dmj`> | amano: why do you need to abstract over StateT |
| 2024-10-03 06:38:59 +0200 | <amano> | You are stuck with existential typeclass, a giant case statement, a giant record type, or a giant list of pattern match statements. |
| 2024-10-03 06:39:11 +0200 | <amano> | dmj`: I didn't need. StateT is used by brick TUI library. |
| 2024-10-03 06:39:12 +0200 | <dmj`> | amano: paste code |
| 2024-10-03 06:39:58 +0200 | <amano> | data EventM n s a = ... StateT s ... |
| 2024-10-03 06:40:08 +0200 | <amano> | I need polymorphism in EventM. |
| 2024-10-03 06:40:18 +0200 | <amano> | polymorphism for s in EventM. |
| 2024-10-03 06:41:03 +0200 | <amano> | s is application state which consists of many modes... |
| 2024-10-03 06:41:19 +0200 | <amano> | It can be a typeclass or a sum type or a giant record type which carries state for all modes. |
| 2024-10-03 06:42:26 +0200 | <dmj`> | yea why not just use a giant record, use lenses to get and set stuff |
| 2024-10-03 06:42:47 +0200 | <amano> | That's not elegant. |
| 2024-10-03 06:42:57 +0200 | <amano> | The author of brick uses a giant record. |
| 2024-10-03 06:43:00 +0200 | <amano> | I have used a giant sum type. |
| 2024-10-03 06:43:41 +0200 | <dmj`> | well I'm sure its a mix of both |
| 2024-10-03 06:44:01 +0200 | <amano> | I want to unentangle my application design. |
| 2024-10-03 06:44:18 +0200 | <dmj`> | what is the application you're trying to design |
| 2024-10-03 06:44:35 +0200 | <amano> | I already finished writing it months ago. |
| 2024-10-03 06:45:10 +0200 | <dmj`> | well it's hard to discuss tradeoffs w/o knowing what it does |
| 2024-10-03 06:45:35 +0200 | <amano> | https://codeberg.org/amano.kenji/brick-trading-journal |
| 2024-10-03 06:46:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:48:03 +0200 | <amano> | It is a program that can be written with existential typeclass. |
| 2024-10-03 06:48:10 +0200 | <dmj`> | so you do have a big sum for BrickEvent and a big product |
| 2024-10-03 06:48:39 +0200 | <dmj`> | what benefit do you so in doing that? |
| 2024-10-03 06:48:40 +0200 | <c_wraith> | I mean, you could just do a tagless final encoding. |
| 2024-10-03 06:48:53 +0200 | <amano> | What is tagless final encoding? |
| 2024-10-03 06:48:56 +0200 | <dmj`> | do you see* (exist. typeclass approach) |
| 2024-10-03 06:49:31 +0200 | <dmj`> | no shiny things yet, why use an existential typeclass |
| 2024-10-03 06:49:52 +0200 | <amano> | I don't like giant case statements. |
| 2024-10-03 06:49:55 +0200 | <dmj`> | are you trying to "componentize" your application |
| 2024-10-03 06:49:55 +0200 | <c_wraith> | Divide your functionality up into a set of classes and write all your code as polymorphic over the set of classes it needs on the state. Only choose a concrete type that implements all those classes in one spot. |
| 2024-10-03 06:50:55 +0200 | <c_wraith> | no need for an existential at all. |
| 2024-10-03 06:51:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 06:51:09 +0200 | <amano> | c_wraith: I'm afraid that StateT is compatible with that. |
| 2024-10-03 06:51:22 +0200 | <amano> | I can't just ditch StateT which comes from brick which I have no control over. |
| 2024-10-03 06:51:30 +0200 | <c_wraith> | StateT works fine with it |
| 2024-10-03 06:51:39 +0200 | <amano> | Can you show me an example code? |
| 2024-10-03 06:51:40 +0200 | <c_wraith> | Foo s => StateT s m a |
| 2024-10-03 06:52:07 +0200 | <amano> | But, state transformations can't replace Foo s1 with Foo s2. |
| 2024-10-03 06:52:19 +0200 | <c_wraith> | Write your class so they don't need to |
| 2024-10-03 06:52:48 +0200 | <amano> | You mean a giant sum type or a giant record as a typeclass instance? |
| 2024-10-03 06:52:51 +0200 | <dmj`> | amano: well then you can make a nested sum type, data Event = EventFoo FooEvent | EventBar BarEvent, so you'd have smaller case statements for each part of the app, then you can use "zoom" on each |
| 2024-10-03 06:53:20 +0200 | <haskellbridge> | <sm> interesting app |
| 2024-10-03 06:53:48 +0200 | <dmj`> | amano: are you familiar with zoom |
| 2024-10-03 06:53:54 +0200 | <amano> | dmj`: zoom zoom yes. |
| 2024-10-03 06:54:10 +0200 | <amano> | I have used zoom extensively in my application. |
| 2024-10-03 06:54:56 +0200 | <c_wraith> | Having an existential over the state type requires runtime checking identical to what just being concrete does. |
| 2024-10-03 06:55:16 +0200 | <amano> | c_wraith: I want to see an example or a description. |
| 2024-10-03 06:55:32 +0200 | <amano> | Your suggestion seems no different than a giant case statement that I already have now. |
| 2024-10-03 06:55:45 +0200 | <amano> | or a giant record |
| 2024-10-03 06:56:26 +0200 | <amano> | You are telling me to hide a giant case statement behind one typeclass intance, correct? |
| 2024-10-03 06:56:40 +0200 | <c_wraith> | you were talking about modularization. I'm telling you how to modularize it. |
| 2024-10-03 06:57:03 +0200 | <amano> | How would I modularize https://codeberg.org/amano.kenji/brick-trading-journal/src/branch/master/app/Main.hs ? |
| 2024-10-03 06:57:21 +0200 | <amano> | I just can't envision what you said. |
| 2024-10-03 06:58:06 +0200 | <haskellbridge> | <sm> do you mean, big cases like this one ? modehttps://codeberg.org/amano.kenji/brick-trading-journal/src/commit/2111a0b66bfe51a31dc818b4a0592a90… |
| 2024-10-03 06:58:10 +0200 | <amano> | Does tagless final mean erasing typeclass constraints later? |
| 2024-10-03 06:58:15 +0200 | <haskellbridge> | <sm> * https://codeberg.org/amano.kenji/brick-trading-journal/src/commit/2111a0b66bfe51a31dc818b4a0592a90… |
| 2024-10-03 06:58:32 +0200 | <amano> | Yes |
| 2024-10-03 06:58:33 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-10-03 06:59:24 +0200 | <amano> | Next time, I design a haskell application, I want to be free of a giant sum type or a giant record. |
| 2024-10-03 07:00:05 +0200 | <dmj`> | amano: zoom solves your problem for giant record, but giant sum make a tree of the sum types (as I posted above), then case on the sums and pass the action to the zoomed part of the state |
| 2024-10-03 07:00:10 +0200 | <haskellbridge> | <sm> in https://github.com/simonmichael/hledger/blob/master/hledger-ui/Hledger/UI/Main.hs#L300 you can see I broke it up into a separate module for each type of screen.. but there's so much boilerplate, I'm not sure that your way isn't better |
| 2024-10-03 07:00:22 +0200 | <c_wraith> | this seems like the perfect case for a record of functions. |
| 2024-10-03 07:00:35 +0200 | <c_wraith> | You can easily split it into lots of related parts |
| 2024-10-03 07:01:45 +0200 | <c_wraith> | (If you see an event type you don't know how to handle, pass it along to the next handler) |
| 2024-10-03 07:01:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:02:49 +0200 | <amano> | sm: That just looks like a sum type. |
| 2024-10-03 07:03:41 +0200 | <amano> | Your case statement just uses different functions for each mode. |
| 2024-10-03 07:04:13 +0200 | <haskellbridge> | <sm> yes, it's still a big case statement, but split up into per-screen modules |
| 2024-10-03 07:05:01 +0200 | <haskellbridge> | <sm> and each module still has a fairly big case. I think it's the natural shape of this type of code, really |
| 2024-10-03 07:05:20 +0200 | <amano> | Except my application has more modes.... |
| 2024-10-03 07:05:24 +0200 | <haskellbridge> | <sm> I mean: a long list of possible events and state code to handle each |
| 2024-10-03 07:05:32 +0200 | <amano> | I don't really want to see a bigger case statement. |
| 2024-10-03 07:05:35 +0200 | <haskellbridge> | <sm> * states, and |
| 2024-10-03 07:05:51 +0200 | <amano> | Your design is basically the same as mine. |
| 2024-10-03 07:05:59 +0200 | <haskellbridge> | <sm> yup |
| 2024-10-03 07:06:23 +0200 | <c_wraith> | there's no way to escape from "I have all these cases that need to do different things" |
| 2024-10-03 07:06:29 +0200 | <c_wraith> | that's... what the code does. |
| 2024-10-03 07:06:34 +0200 | <c_wraith> | There are a lot of different things. |
| 2024-10-03 07:06:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 07:06:42 +0200 | <dmj`> | yea the state has got to live somewhere |
| 2024-10-03 07:06:43 +0200 | <amano> | Polymorphism, help me. |
| 2024-10-03 07:06:54 +0200 | <c_wraith> | That just splits the code apart. |
| 2024-10-03 07:07:03 +0200 | <c_wraith> | You can do that by writing functions, too |
| 2024-10-03 07:07:21 +0200 | <haskellbridge> | <sm> now how does it look different in OO code ? The logic must be the same but maybe it looks more tidy ? |
| 2024-10-03 07:07:26 +0200 | <amano> | Existential typeclass unentangles the code cleanly. |
| 2024-10-03 07:08:31 +0200 | <dmj`> | amano: how does an existential type class remove the number of constructors have you have to pattern match on? |
| 2024-10-03 07:08:37 +0200 | <haskellbridge> | <sm> c_wraith: this sounds interesting. I am wary of records of functions though, they make introspection and debugging hard |
| 2024-10-03 07:08:50 +0200 | <amano> | In a presentation called simple made easy by rich hickey, he said switch statement and pattern matching entangle multiple who/what pairs.... |
| 2024-10-03 07:09:02 +0200 | <amano> | Polymorphism unentangles such things... |
| 2024-10-03 07:09:13 +0200 | <c_wraith> | Rich Hickey is mostly wrong about Haskell |
| 2024-10-03 07:09:16 +0200 | <c_wraith> | I wouldn't trust him |
| 2024-10-03 07:09:29 +0200 | <amano> | dmj`: There is no pattern matching if you use existential type class... |
| 2024-10-03 07:09:36 +0200 | <amano> | There is only polymorphic dispatch. |
| 2024-10-03 07:09:50 +0200 | <c_wraith> | You mean the same as if you have a function? |
| 2024-10-03 07:10:00 +0200 | <dmj`> | amano: you still have to dispatch on all constructors though, it just moves the logic somewhere else |
| 2024-10-03 07:10:16 +0200 | <amano> | c_wraith: He may be the wrong about haskell types, but he is right about simplicity. |
| 2024-10-03 07:10:24 +0200 | <haskellbridge> | <sm> well I for one would like to see any other method of organising brick code |
| 2024-10-03 07:10:34 +0200 | <c_wraith> | By the way: it's 100% fine to have a record with one function and one string value for "how to display this" |
| 2024-10-03 07:10:46 +0200 | <haskellbridge> | <sm> maybe check the other brick apps ? |
| 2024-10-03 07:10:53 +0200 | <amano> | Existential typeclass is the new way of organizing brick code... |
| 2024-10-03 07:11:05 +0200 | <dmj`> | amano: do you have an example you can show |
| 2024-10-03 07:11:09 +0200 | <c_wraith> | Which is a simpler way of doing the same thing as the existential typeclass antipattern |
| 2024-10-03 07:11:24 +0200 | <amano> | c_wraith: Why is it an antipattern? |
| 2024-10-03 07:11:42 +0200 | <amano> | It is just said to be an antipattern by a few people, but they didn't really explain much.... |
| 2024-10-03 07:11:50 +0200 | <c_wraith> | Because it's lots of extra indirection around just having a function |
| 2024-10-03 07:11:56 +0200 | <amano> | Just saying it is an antipattern doesn't make it an anti-pattern. |
| 2024-10-03 07:11:57 +0200 | <c_wraith> | You could just write direct code instead |
| 2024-10-03 07:12:16 +0200 | <amano> | There is not a lot of extra indirection. |
| 2024-10-03 07:12:27 +0200 | <amano> | It's just polymorphic dispatch. |
| 2024-10-03 07:12:57 +0200 | <haskellbridge> | <sm> why not write a small prototype and show us |
| 2024-10-03 07:12:59 +0200 | <probie> | amano: `data T = forall a . C a => T a` and `data T = forall a . T (R a) a` are "the same" |
| 2024-10-03 07:13:31 +0200 | <Lears> | @where existential-antipattern |
| 2024-10-03 07:13:32 +0200 | <lambdabot> | "Haskell Antipattern: Existential Typeclass" by Luke Palmer at <https://web.archive.org/web/20220121105027/https://lukepalmer.wordpress.com/2010/01/24/haskell-ant…> |
| 2024-10-03 07:13:37 +0200 | <dmj`> | amano: you can remove your giant case if you make your sum type more granular |
| 2024-10-03 07:14:19 +0200 | <Lears> | amano: ^ I think this is the origin of the notion, though it's been echoed far more loudly than is merited. |
| 2024-10-03 07:14:24 +0200 | <amano> | sm: data AppState = forall n. UIState ui => AppState { uiState :: ui, ... } |
| 2024-10-03 07:15:08 +0200 | <amano> | You can put multiple different UIState instances in uiState. |
| 2024-10-03 07:15:25 +0200 | <amano> | UIState type class has draw function and handleEvent function.... |
| 2024-10-03 07:15:32 +0200 | <amano> | You call draw and handleEvent on ui. |
| 2024-10-03 07:15:41 +0200 | <haskellbridge> | <sm> I mean, a working prototype. When it comes to this stuff that's all I trust |
| 2024-10-03 07:15:57 +0200 | <amano> | sm: I don't have a working prototype, but that should work.... That's the idea. |
| 2024-10-03 07:16:22 +0200 | <amano> | That's existential typeclass... |
| 2024-10-03 07:16:46 +0200 | <amano> | dmj`: A more granular sum type would require a bigger case statement.... |
| 2024-10-03 07:16:48 +0200 | <haskellbridge> | <sm> you said Existential typeclass is the new way of organizing brick code, and dmj asked for an example.. I'd like to see that too |
| 2024-10-03 07:16:49 +0200 | <amano> | Granular means more... |
| 2024-10-03 07:16:57 +0200 | <probie> | If `R` is a record with every element being a function which takes `a` as the first argument (and doesn't not take `a` anywhere else), then there's a function `R a -> a -> R ()` (i.e you can drop the existential) |
| 2024-10-03 07:17:05 +0200 | <amano> | sm: That's the only example I have for now... |
| 2024-10-03 07:17:12 +0200 | <monochrom> | Yeah I am wondering what's the purpose of all this hour of hot air is about. If you already have a stance, just do it, why "argue". |
| 2024-10-03 07:17:18 +0200 | <haskellbridge> | <sm> ok. I thought maybe you had seen it used. |
| 2024-10-03 07:17:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:18:15 +0200 | <probie> | then you can come up with a new type `R'` which is `R`, but simply "removes" the first argument of every function in the record, and there's also a function from `R () -> R'` at which point it seems like you don't even need polymorphism |
| 2024-10-03 07:18:19 +0200 | <amano> | monochrom: I thought maybe other people had an idea that's better in all aspects.... |
| 2024-10-03 07:18:41 +0200 | <amano> | sm: Can you understand my example? |
| 2024-10-03 07:18:56 +0200 | <monochrom> | Huh, all aspects? Look up the "expression problem" already. There is none. |
| 2024-10-03 07:18:58 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-10-03 07:19:17 +0200 | <amano> | Okay, anybody know something better? |
| 2024-10-03 07:20:26 +0200 | <haskellbridge> | <sm> https://hackage.haskell.org/package/matterhorn-90000.0.1/docs/src/Matterhorn.Events.html#onEvent has split up the giant case statement into separate functions... |
| 2024-10-03 07:20:55 +0200 | <dmj`> | ^ what sm posted is what I'm referring to |
| 2024-10-03 07:20:59 +0200 | <dmj`> | amano: |
| 2024-10-03 07:21:00 +0200 | <haskellbridge> | <sm> amano: no I can't, or if I did I wouldn't trust my understanding till I saw it working |
| 2024-10-03 07:21:48 +0200 | <amano> | sm: Look up haskell existential typeclass. |
| 2024-10-03 07:21:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-10-03 07:22:14 +0200 | <amano> | That's just pattern matching.... |
| 2024-10-03 07:22:27 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-10-03 07:22:37 +0200 | <amano> | I was trying to avoid a huge list of pattern match statements, too. |
| 2024-10-03 07:22:42 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Ping timeout: 246 seconds) |
| 2024-10-03 07:23:00 +0200 | <dmj`> | amano: you don't need it to be an existential typeclass if you split up the case into separate functions, can just use a regular typeclass |
| 2024-10-03 07:23:28 +0200 | <dmj`> | but the logic has to live somewhere, be it in a case, a function, or an instance |
| 2024-10-03 07:23:29 +0200 | <amano> | dmj`: StateT doesn't allow replacing one typeclass instance with another. |
| 2024-10-03 07:24:03 +0200 | <amano> | JuanDaugherty: Are you brick author? |
| 2024-10-03 07:24:14 +0200 | <dmj`> | amano: that doesn't matter, it doesn't have to |
| 2024-10-03 07:24:17 +0200 | <JuanDaugherty> | amano, no. |
| 2024-10-03 07:24:30 +0200 | <monochrom> | I feel like this is religiously avoiding pattern matching at all costs, not rationally avoiding pattern matching under an informed decision on a case-by-case basis, just because a celebrity said to. |
| 2024-10-03 07:24:33 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) (Ping timeout: 245 seconds) |
| 2024-10-03 07:24:50 +0200 | <amano> | monochrom: I just want polymorphism... That's all... |
| 2024-10-03 07:24:53 +0200 | <monochrom> | s/informed/weighed/ even |
| 2024-10-03 07:25:05 +0200 | <JuanDaugherty> | google's 'generative AI' gives an amusing result for "ghc major version timeline" |
| 2024-10-03 07:25:09 +0200 | aforemny_ | (~aforemny@i59F4C77A.versanet.de) (Ping timeout: 246 seconds) |
| 2024-10-03 07:25:15 +0200 | <JuanDaugherty> | apparently stack versions |
| 2024-10-03 07:25:23 +0200 | <monochrom> | OK s/avoiding pattern matching/going for polymorphism/ same difference. |
| 2024-10-03 07:25:45 +0200 | <amano> | And, I actually like splitting up each mode into different files... |
| 2024-10-03 07:25:55 +0200 | <monochrom> | BTW do you like my pun with "on a case-by-case basis"? >:) |
| 2024-10-03 07:26:11 +0200 | <amano> | I haven't seen any roadblock for using existential typeclass in my application. |
| 2024-10-03 07:26:59 +0200 | aforemny | (~aforemny@i59F4C77A.versanet.de) aforemny |
| 2024-10-03 07:27:57 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) |
| 2024-10-03 07:28:05 +0200 | <probie> | amano: Can you give me a toy example of what "needs" existential typeclasses, and I'll attempt to give an example that doesn't use them _and_ meets your requirement of not being a giant case statement? |
| 2024-10-03 07:28:28 +0200 | <amano> | I don't need anything technically. |
| 2024-10-03 07:28:43 +0200 | <amano> | I just prefer existential typeclasses in my application. |
| 2024-10-03 07:29:06 +0200 | <amano> | probie: No giant case statement. No giant list of pattern matching function statements. |
| 2024-10-03 07:29:17 +0200 | <amano> | probie: https://codeberg.org/amano.kenji/brick-trading-journal/src/branch/master/app/Main.hs#L108 |
| 2024-10-03 07:30:09 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-10-03 07:32:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:33:20 +0200 | <probie> | That's not a toy example though :p Hang on, let me write something |
| 2024-10-03 07:35:47 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) (Ping timeout: 256 seconds) |
| 2024-10-03 07:37:37 +0200 | <JuanDaugherty> | "timeline of ghc major versions" is an irritating rabbit hole but "when was ghc 6.4 released" does the right thing |
| 2024-10-03 07:37:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 07:39:42 +0200 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-10-03 07:40:23 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-03 07:40:41 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Ping timeout: 252 seconds) |
| 2024-10-03 07:41:55 +0200 | <haskellbridge> | <thirdofmay18081814goya> for any total hylomorphism is time complexity decidable? |
| 2024-10-03 07:43:42 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds) |
| 2024-10-03 07:43:56 +0200 | hueso | (~root@user/hueso) (Ping timeout: 255 seconds) |
| 2024-10-03 07:44:06 +0200 | hueso | (~root@user/hueso) hueso |
| 2024-10-03 07:45:52 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2024-10-03 07:48:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:52:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 08:00:09 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 246 seconds) |
| 2024-10-03 08:01:52 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) adanwan |
| 2024-10-03 08:02:11 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 260 seconds) |
| 2024-10-03 08:03:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:03:58 +0200 | <probie> | amano: https://play.haskell.org/saved/Lcwk9WaE for a boring record solution that may still allow you to do what you want |
| 2024-10-03 08:06:42 +0200 | araujo | (~araujo@216.73.163.154) araujo |
| 2024-10-03 08:08:53 +0200 | <amano> | That's not how I am going to organize brick code. |
| 2024-10-03 08:09:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 08:11:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:11:11 +0200 | <haskellbridge> | <sm> It's a nice example but I have doubts about this when it grows into a real world app. I used to use records-of-functions in mine, and it made debugging very difficult. |
| 2024-10-03 08:11:33 +0200 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2024-10-03 08:13:00 +0200 | <amano> | sm: I don't even know how to debug a haskell application. |
| 2024-10-03 08:13:39 +0200 | <haskellbridge> | <sm> haven't you had a bug in yours yet ? |
| 2024-10-03 08:13:49 +0200 | <probie> | sm: I don't think it scales either, but I posit it is _no worse_ for that than `data SomeType = forall a. TypeClass a => SomeType a` |
| 2024-10-03 08:13:53 +0200 | <amano> | sm: Not yet. |
| 2024-10-03 08:13:58 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) neuroevolutus |
| 2024-10-03 08:14:35 +0200 | <amano> | probie: Your example is more convoluted than existential typeclass... |
| 2024-10-03 08:14:42 +0200 | <haskellbridge> | <sm> amano: I think your giant case statement might be helping - it's simple and clear! |
| 2024-10-03 08:15:17 +0200 | <amano> | At least, existential typeclass is easy to reason about. |
| 2024-10-03 08:15:37 +0200 | <amano> | Its drawback is type information loss. |
| 2024-10-03 08:15:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 08:18:47 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2024-10-03 08:19:03 +0200 | benjaminl | (~benjaminl@user/benjaminl) benjaminl |
| 2024-10-03 08:22:33 +0200 | <amano> | Why do people want to avoid existential typeclass when it seems easy and simple? |
| 2024-10-03 08:25:52 +0200 | <amano> | I'm not going to rewrite my application with existential typeclass, but my next application will attempt existential typeclass. |
| 2024-10-03 08:26:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:27:02 +0200 | amano | (amano@gateway/vpn/airvpn/amano) (Quit: amano) |
| 2024-10-03 08:29:58 +0200 | <probie> | Is a record of functions actually more convoluted than an existential typeclass? |
| 2024-10-03 08:31:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 08:31:30 +0200 | <Lears> | It kinda is when e.g. `click :: a -> a` becomes `data Widget = Widget{ click :: Widget, ... }`. |
| 2024-10-03 08:35:21 +0200 | <probie> | The type is more generic, since `click :: Widget -> Widget` is really modelling `click :: Widget a => a -> SomeWidget` |
| 2024-10-03 08:37:07 +0200 | <Lears> | In any case, the "existential antipattern" is given vastly more weight by the Haskell community than it deserves. The worst misuses of existentials cut themselves off with dead ends, while the lesser ones merely leave your code base a little clunkier than it needs to be. |
| 2024-10-03 08:37:16 +0200 | <Lears> | They just aren't something that needs to be so desperately avoided. |
| 2024-10-03 08:42:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:43:33 +0200 | <probie> | I still don't really buy that a record of functions is more convoluted; there's one less layer of indirection. I think it just "feels" more different from what you'd do in an OO language. |
| 2024-10-03 08:45:25 +0200 | <geekosaur> | I suppose that depends on what you're doing with it. I really wouldn't want to have to shoehorn xmonad's `LayoutClass` into a record of functions, given that constructors are (`State`-style) "mutable" |
| 2024-10-03 08:45:55 +0200 | <Lears> | I'm pretty much a Haskell native, just BTW. |
| 2024-10-03 08:46:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-10-03 08:47:03 +0200 | amano | (amano@gateway/vpn/airvpn/amano) amano |
| 2024-10-03 08:47:17 +0200 | <amano> | Okay. No more debate. I'm just going to use existential typeclass without asking a question like a man. |
| 2024-10-03 08:47:42 +0200 | <amano> | Next time I write something, use existential typeclass... without a question like a real man. |
| 2024-10-03 08:48:14 +0200 | <amano> | Asking questions about existential typeclass without using it is autistic. |
| 2024-10-03 08:48:26 +0200 | <geekosaur> | watch your language |
| 2024-10-03 08:48:48 +0200 | <probie> | I'm pretty sure it's a thing neurotypical people do as well tbh |
| 2024-10-03 08:49:08 +0200 | <amano> | Autism' |
| 2024-10-03 08:49:20 +0200 | <amano> | The characteristic of autism is obsession over details. |
| 2024-10-03 08:49:31 +0200 | <amano> | Masculine competitive men don't obsess over details. |
| 2024-10-03 08:49:38 +0200 | <amano> | They don't think too much. |
| 2024-10-03 08:49:45 +0200 | <geekosaur> | common but not characteristic |
| 2024-10-03 08:49:46 +0200 | <dibblego> | remember when #haskell was interesting |
| 2024-10-03 08:50:14 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-10-03 08:50:25 +0200 | <probie> | dibblego: the early days of lenses? |
| 2024-10-03 08:50:35 +0200 | <dibblego> | haha, before then even |
| 2024-10-03 08:51:02 +0200 | <amano> | A ahracteristic of autism is inflexible patterns of behavior. Lack of flexibility. |
| 2024-10-03 08:51:09 +0200 | <amano> | * characteristic |
| 2024-10-03 08:51:36 +0200 | <geekosaur> | actually, I figured out early on that that didn't work and flipped it on its head |
| 2024-10-03 08:53:00 +0200 | <geekosaur> | not that anyone had a clue about high-cog autism back then |
| 2024-10-03 08:53:05 +0200 | <geekosaur> | (myself included) |
| 2024-10-03 08:54:44 +0200 | <amano> | Inflexibility leads to obsession over details... |
| 2024-10-03 08:55:04 +0200 | <amano> | If you are willing to adapt, you don't pay too much attention to details. |
| 2024-10-03 08:55:15 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) (Quit: Client closed) |
| 2024-10-03 08:55:25 +0200 | <geekosaur> | I'm not the one who seems to be obsessing here |
| 2024-10-03 08:55:36 +0200 | <amano> | geekosaur: Right. I was obsessing. |
| 2024-10-03 08:55:42 +0200 | <amano> | I am trying to become a real man. |
| 2024-10-03 08:55:48 +0200 | <amano> | overcome my autism. |
| 2024-10-03 08:56:58 +0200 | <probie> | I'm trying to overcome my blue eyes. No luck so far |
| 2024-10-03 08:57:04 +0200 | <amano> | Oh, I have to use this. I have to. I have to compare pros and cons because I have to make sure it is the best option. |
| 2024-10-03 08:57:21 +0200 | <amano> | Shut up. You are autistic. Become a man. Adapt. |
| 2024-10-03 08:57:35 +0200 | <Lears> | Setting aside this overly divergent tangent, I should point out that the actual loss of type information is not necessary so long as the set of alternatives is statically known. |
| 2024-10-03 08:57:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:57:53 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2024-10-03 08:58:14 +0200 | <Lears> | You can replace the existential with a sum GADT that allows you to recover the type within. |
| 2024-10-03 08:58:27 +0200 | <amano> | Lears: That's what I'm already doing. A giant sum type. |
| 2024-10-03 08:58:40 +0200 | <amano> | Next time, I want to try existential typeclass and gather direct experiences. |
| 2024-10-03 08:59:00 +0200 | <Lears> | I mean that, you can use e.g. `data Sum f xs = forall x. Sum (Index x xs) (f x)`. |
| 2024-10-03 08:59:43 +0200 | <amano> | What is that type? |
| 2024-10-03 09:00:04 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-10-03 09:00:18 +0200 | <Lears> | (where e.g. `data Index x xs where { Z :: Index x (x:xs); S :: Index x xs -> Index x (y:xs) }`) |
| 2024-10-03 09:00:41 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2024-10-03 09:00:49 +0200 | <Lears> | The `f` can hold a constraint on `x`, if you need one. |
| 2024-10-03 09:02:09 +0200 | <Lears> | Then `Sum f [X, Y, Z]` can be any one of `f X`, `f Y` or `f Z`, the type being recoverable by matching on the index. When you don't care, you just use `f x`. |
| 2024-10-03 09:02:16 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-03 09:02:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-10-03 09:04:06 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 265 seconds) |
| 2024-10-03 09:06:25 +0200 | <probie> | And you can also write helpful functions like `All p xs => (p x => x -> y) -> Sum I xs -> Sum (K y) xs` à la generics-sop? :p |
| 2024-10-03 09:06:35 +0200 | <amano> | Lears: Wait. Does that type have to have all relevant types in the type signature? |
| 2024-10-03 09:06:40 +0200 | <amano> | That's ugly. |
| 2024-10-03 09:07:07 +0200 | <Lears> | amano: You'd only declare them in one place, then put it either in a type synonym or under a newtype. |
| 2024-10-03 09:07:26 +0200 | <amano> | I still prefer existential typeclass. |
| 2024-10-03 09:07:43 +0200 | <amano> | I actually don't care type information loss... |
| 2024-10-03 09:07:47 +0200 | <amano> | I shouldn't care about internal details.... |
| 2024-10-03 09:08:10 +0200 | <amano> | My specific application doesn't care about details like a real man. |
| 2024-10-03 09:08:28 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 09:09:22 +0200 | billchenchina- | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection) |
| 2024-10-03 09:10:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 09:15:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 09:16:19 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-10-03 09:17:27 +0200 | <jackdk> | My experience is that things all seem to be fine initially but then at some point in the future I wound up having to use higher-powered tools from packages like `constraints` and ended up regretting my choices. But I don't have that code any more so I can't make the example concrete. |
| 2024-10-03 09:17:27 +0200 | AWizzArd | (~code@user/awizzard) (Read error: Connection reset by peer) |
| 2024-10-03 09:20:49 +0200 | <jackdk> | It also dovetails nicely with my stance on typeclasses, which I think are justified only when one wants (commonly) to abstract over a bunch of related types, _using laws_, or (less commonly) needs to do type-directed dispatch in something like `servant`. Otherwise, I tend to find they obscure more than they help (`data-default`), or invite silent changes where you don't expect them (any serialisation typeclass ever), or |
| 2024-10-03 09:21:27 +0200 | <jackdk> | , or you have to invent `newtype`s just to make things line up, or start playing around with dark magic like `reflection` because you _only_ have access to a typeclassy interface. |
| 2024-10-03 09:22:16 +0200 | <amano> | That's not a good reason to avoid existential typeclasses when they seem to make sense. |
| 2024-10-03 09:22:56 +0200 | <amano> | For self-contained end-user applications, existential typeclasses don't really hurt much. |
| 2024-10-03 09:23:09 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-10-03 09:23:12 +0200 | <amano> | Libraries may need to pay more attention because they affect other people. |
| 2024-10-03 09:23:28 +0200 | AWizzArd | (~code@gehrels.uberspace.de) |
| 2024-10-03 09:24:23 +0200 | <jackdk> | Another example: the amount of (cool) machinery that `constraints-extras` uses to prove things like "given GADT tag x, we have `Show (f a)` for every possible `x` in `tag`" is much greater than just being able to accept a function `(tag x -> f x -> String)` |
| 2024-10-03 09:24:42 +0200 | <amano> | My types are simple, and my existential typeclasses will be simple, too. |
| 2024-10-03 09:25:01 +0200 | <jackdk> | *shrug* you do you, man |
| 2024-10-03 09:26:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 09:26:19 +0200 | synchromesh | (~john@2406:5a00:241a:5600:cddc:9175:fad4:c3aa) (Read error: Connection reset by peer) |
| 2024-10-03 09:26:24 +0200 | <jackdk> | The heuristic I outlined has worked well for me across multiple contexts, and came from some painful and frustrating lessons. |
| 2024-10-03 09:26:41 +0200 | synchromesh | (~john@2406:5a00:241a:5600:c4f0:795f:9391:8816) synchromesh |
| 2024-10-03 09:27:16 +0200 | <amano> | I just aim for orthogonal design which is totally compatible with existential typeclasses. |
| 2024-10-03 09:27:26 +0200 | <amano> | When different typeclasses need to know each other, they break down. |
| 2024-10-03 09:27:41 +0200 | <amano> | When things are disentangled, existential typeclasses don't hurt. |
| 2024-10-03 09:27:55 +0200 | <amano> | They don't need to know each other, and everything is fine. |
| 2024-10-03 09:28:42 +0200 | <amano> | In my application, ui mode is totally independent from ui state. Thus, I can have an existential typeclass for ui mode and another for ui state. |
| 2024-10-03 09:28:57 +0200 | <jackdk> | When I have been that confident in how I expect my code to evolve, I have often been humbled N < 10 months down the line. |
| 2024-10-03 09:29:46 +0200 | <amano> | If I fail to predict module boundaries, then existential typeclasses break down. |
| 2024-10-03 09:30:27 +0200 | xff0x_ | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-10-03 09:30:32 +0200 | <amano> | My application is largely finished and will probably not change.... |
| 2024-10-03 09:30:32 +0200 | alioguzhan | (~Thunderbi@78.173.89.238) (Remote host closed the connection) |
| 2024-10-03 09:30:43 +0200 | <amano> | until my death probably. |
| 2024-10-03 09:30:49 +0200 | alioguzhan | (~Thunderbi@78.173.89.238) |
| 2024-10-03 09:30:59 +0200 | <jackdk> | I believe that one must be clairvoyant to reliably predict module boundaries. Applying modus ponens, we then conclude... |
| 2024-10-03 09:31:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-03 09:31:56 +0200 | <jackdk> | Anyway, not my code, not my problem if the design hits trouble. I wish you the very best of luck and I genuinely hope that it succeeds. |
| 2024-10-03 09:32:20 +0200 | <amano> | The code is not the problem. The problem is the pilot that uses the program. |
| 2024-10-03 09:32:53 +0200 | <probie> | I've given up attempting any sort of predication and (for personal projects) just start by dumping everything in a single module to be pulled apart as it becomes clearer how to do so |
| 2024-10-03 09:33:38 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2024-10-03 09:33:46 +0200 | <amano> | probie: My application is already complete. |
| 2024-10-03 09:34:38 +0200 | amano | (amano@gateway/vpn/airvpn/amano) (Quit: amano) |
| 2024-10-03 09:35:15 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-10-03 09:38:10 +0200 | polyphem | (~rod@p4fc2c55e.dip0.t-ipconnect.de) polyphem |
| 2024-10-03 09:39:52 +0200 | arahael | (~arahael@user/arahael) (Remote host closed the connection) |
| 2024-10-03 09:41:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 09:42:47 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod |
| 2024-10-03 09:42:52 +0200 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-10-03 09:46:43 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-10-03 09:46:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 09:48:30 +0200 | raym | (~ray@user/raym) (Quit: updating server) |
| 2024-10-03 09:54:35 +0200 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-10-03 09:57:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 10:02:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 10:12:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 10:17:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 10:25:57 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-03 10:26:05 +0200 | Inst_ | (~Inst@user/Inst) Inst |
| 2024-10-03 10:27:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 10:28:41 +0200 | Inst | (~Inst@user/Inst) (Ping timeout: 265 seconds) |
| 2024-10-03 10:32:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 10:39:19 +0200 | mari-estel | (~mari-este@dynamic-176-000-160-069.176.0.pool.telefonica.de) |
| 2024-10-03 10:39:56 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3207-288e-206f-9822-5a5d-6079.rev.sfr.net) alexherbo2 |
| 2024-10-03 10:43:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 10:44:07 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3207-288e-206f-9822-5a5d-6079.rev.sfr.net) (Remote host closed the connection) |
| 2024-10-03 10:46:58 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb63d87029be15e343a0.dip0.t-ipconnect.de) acidjnk |
| 2024-10-03 10:47:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 10:50:44 +0200 | feetwind | (~mike@user/feetwind) (Quit: WeeChat 4.1.2) |
| 2024-10-03 10:52:35 +0200 | liamzy__ | (~Inst@user/Inst) Inst |
| 2024-10-03 10:55:01 +0200 | Inst_ | (~Inst@user/Inst) (Ping timeout: 252 seconds) |
| 2024-10-03 10:58:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 11:03:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 11:12:14 +0200 | yoneda | (~mike@193.206.102.122) |
| 2024-10-03 11:13:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 11:14:19 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2024-10-03 11:17:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 11:19:11 +0200 | raym | (~ray@user/raym) raym |
| 2024-10-03 11:26:41 +0200 | leah2 | (~leah@vuxu.org) (Ping timeout: 255 seconds) |
| 2024-10-03 11:28:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 11:32:48 +0200 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-10-03 11:33:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-03 11:39:56 +0200 | leah2 | (~leah@vuxu.org) leah2 |
| 2024-10-03 11:43:49 +0200 | xff0x_ | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2024-10-03 11:44:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 11:44:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-03 11:46:34 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 272 seconds) |
| 2024-10-03 11:48:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 11:55:23 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 245 seconds) |
| 2024-10-03 11:55:25 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Remote host closed the connection) |
| 2024-10-03 11:55:39 +0200 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-10-03 11:59:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 11:59:56 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-10-03 12:00:30 +0200 | Digit | (~user@user/digit) (Ping timeout: 272 seconds) |
| 2024-10-03 12:02:58 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-10-03 12:04:04 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-10-03 12:04:17 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2024-10-03 12:04:42 +0200 | Digitteknohippie | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2024-10-03 12:06:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 12:09:32 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-10-03 12:09:34 +0200 | mari-estel | (~mari-este@dynamic-176-000-160-069.176.0.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-10-03 12:10:13 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2024-10-03 12:14:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 12:16:38 +0200 | hueso | (~root@user/hueso) (Ping timeout: 245 seconds) |
| 2024-10-03 12:17:36 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 272 seconds) |
| 2024-10-03 12:18:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 12:19:51 +0200 | <probie> | I remember last time I tried to use llvm as a library with Haskell (which was probably ~5 years ago) it was a bit of a headache making versions line up. Are there any other reasonable alternatives with some Haskell support for a JIT compiler (that works on aarch64)? |
| 2024-10-03 12:23:18 +0200 | araujo | (~araujo@216.73.163.154) (Remote host closed the connection) |
| 2024-10-03 12:29:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 12:33:03 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Remote host closed the connection) |
| 2024-10-03 12:33:27 +0200 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-10-03 12:34:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-03 12:41:46 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1c0c:a36e:c661:24b2) |
| 2024-10-03 12:41:48 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-10-03 12:45:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 12:46:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-10-03 12:48:21 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-10-03 12:49:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 12:56:15 +0200 | alp_ | (~alp@2001:861:e3d6:8f80:ae1f:5c06:1786:e17) (Ping timeout: 246 seconds) |
| 2024-10-03 12:56:55 +0200 | Digit | (~user@user/digit) Digit |
| 2024-10-03 13:00:04 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-10-03 13:00:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 13:02:16 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2024-10-03 13:05:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-10-03 13:15:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 13:16:31 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) smalltalkman |
| 2024-10-03 13:19:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 13:24:03 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) libertyprime |
| 2024-10-03 13:30:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 13:35:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 13:38:35 +0200 | codaraxis | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 13:41:32 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 265 seconds) |
| 2024-10-03 13:43:27 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 13:46:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 13:47:34 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2024-10-03 13:48:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-03 13:51:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 13:52:00 +0200 | identity | (~identity@user/ZharMeny) identity |
| 2024-10-03 14:01:02 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Ping timeout: 255 seconds) |
| 2024-10-03 14:01:10 +0200 | <tomsmeding> | the llvm problem is still there |
| 2024-10-03 14:01:46 +0200 | <tomsmeding> | probie: consider llvm-pretty, which is just an LLVM IR pretty-printer but you can pass that to the `clang` command-line program to compile it |
| 2024-10-03 14:01:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 14:01:54 +0200 | <tomsmeding> | LLVM version issues mostly disappear |
| 2024-10-03 14:02:09 +0200 | <probie> | tomsmeding: That works as pretty well for an AOT compiler, but not for a JIT |
| 2024-10-03 14:02:19 +0200 | <tomsmeding> | what's the difference, really? |
| 2024-10-03 14:03:23 +0200 | <tomsmeding> | if you need to call back and forth between the compiled code and functions in your own executable, compile the LLVM IR to a .so and dlopen() that |
| 2024-10-03 14:04:01 +0200 | <tomsmeding> | sure, clang takes a while to compile code, but then most (admittedly not all) of that time is in LLVM anyway |
| 2024-10-03 14:04:38 +0200 | <tomsmeding> | if you feel this LLVMIR-to-clang approach is too slow for JIT, then you'll not have much more luck binding to LLVM directly |
| 2024-10-03 14:06:13 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-10-03 14:07:12 +0200 | <probie> | That's fair. If I'm going that route, I might also play around with QBE and see how that works out |
| 2024-10-03 14:07:27 +0200 | <tomsmeding> | (I was just going to mention QBE as well :P) |
| 2024-10-03 14:16:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 14:20:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 14:23:09 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds) |
| 2024-10-03 14:26:32 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 14:31:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 14:36:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 14:41:57 +0200 | aforemny | (~aforemny@i59F4C77A.versanet.de) (Ping timeout: 248 seconds) |
| 2024-10-03 14:47:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 14:50:09 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2024-10-03 14:52:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-10-03 14:56:17 +0200 | nckhexen | (nckx@libera/staff/owl/nckx) (Ping timeout: 608 seconds) |
| 2024-10-03 14:57:28 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-10-03 14:57:55 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2024-10-03 15:02:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 15:05:26 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 272 seconds) |
| 2024-10-03 15:05:28 +0200 | hueso | (~root@user/hueso) hueso |
| 2024-10-03 15:07:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 15:17:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 15:22:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-03 15:22:15 +0200 | alp_ | (~alp@2001:861:e3d6:8f80:a9cc:355d:4963:1655) |
| 2024-10-03 15:31:34 +0200 | identity | (~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-10-03 15:32:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 15:35:57 +0200 | identity | (~identity@user/ZharMeny) identity |
| 2024-10-03 15:37:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-10-03 15:42:09 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-03 15:44:36 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) alexherbo2 |
| 2024-10-03 15:48:11 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 15:49:55 +0200 | identity | (~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-10-03 15:50:28 +0200 | identity | (~identity@user/ZharMeny) identity |
| 2024-10-03 15:52:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 15:55:54 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-03 15:57:05 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-10-03 15:57:05 +0200 | ljdarj1 | ljdarj |
| 2024-10-03 16:03:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 16:08:15 +0200 | codaraxis | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 16:08:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-10-03 16:09:59 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) Codaraxis |
| 2024-10-03 16:11:00 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Max SendQ exceeded) |
| 2024-10-03 16:13:47 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 265 seconds) |
| 2024-10-03 16:15:49 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-10-03 16:18:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 16:19:21 +0200 | crazazy | (~user@mail.wibeco.nl) crazazy |
| 2024-10-03 16:22:19 +0200 | Leonard26 | (~Leonard26@49.236.57.54) |
| 2024-10-03 16:24:53 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-10-03 16:25:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 16:26:14 +0200 | <Leonard26> | Hello! I wanted to know how I could get a list of type [0.00,0.05,0.1,0.15,0.2,0.25,0.3,0.35..1.0]. I am trying with [i+0.05 | i<-[0.0..1.0]] but I just get [5.0e-2,1.05] :( |
| 2024-10-03 16:28:01 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 248 seconds) |
| 2024-10-03 16:28:12 +0200 | <geekosaur> | welcome to IEEE floating point. use Data.Scientific (Scientific), Data.CReal (numbers), or some other exact-representation package. Or use Rational instead of Float/Double |
| 2024-10-03 16:32:09 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 16:32:14 +0200 | KicksonButt | (~quassel@2804:14d:7e52:809e:22e6:a05b:6e89:899e) |
| 2024-10-03 16:33:12 +0200 | <__monty__> | > take 21 $ iterate (+ 0.05) 0 -- If you must have Doubles/Floats |
| 2024-10-03 16:33:15 +0200 | <lambdabot> | [0.0,5.0e-2,0.1,0.15000000000000002,0.2,0.25,0.3,0.35,0.39999999999999997,0.... |
| 2024-10-03 16:33:59 +0200 | <crazazy> | > [0.0,0.05..1.0] |
| 2024-10-03 16:34:01 +0200 | <lambdabot> | [0.0,5.0e-2,0.1,0.15000000000000002,0.2,0.25,0.30000000000000004,0.350000000... |
| 2024-10-03 16:34:30 +0200 | <__monty__> | > last [0.0,0.05..1.0] |
| 2024-10-03 16:34:31 +0200 | <lambdabot> | 1.0 |
| 2024-10-03 16:34:50 +0200 | <__monty__> | Thought it'd be excluded but I suppose that makes sense. |
| 2024-10-03 16:34:59 +0200 | <crazazy> | :) |
| 2024-10-03 16:35:46 +0200 | <__monty__> | Why does [0.0..1.0] only enum integer(?) values though? Is it defaulted to [Integer]? |
| 2024-10-03 16:36:00 +0200 | crazazy | (~user@mail.wibeco.nl) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-10-03 16:36:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 16:38:44 +0200 | <Leonard26> | Thank you :] |
| 2024-10-03 16:39:59 +0200 | <int-e> | > [0.5..10] |
| 2024-10-03 16:40:01 +0200 | <lambdabot> | [0.5,1.5,2.5,3.5,4.5,5.5,6.5,7.5,8.5,9.5,10.5] |
| 2024-10-03 16:40:15 +0200 | <int-e> | __monty__: no, it defaults to 1 as the difference between elements |
| 2024-10-03 16:40:27 +0200 | <int-e> | > succ 0.5 |
| 2024-10-03 16:40:29 +0200 | <lambdabot> | 1.5 |
| 2024-10-03 16:41:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 16:42:43 +0200 | <__monty__> | int-e: Ah, of course. >.< |
| 2024-10-03 16:43:35 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Remote host closed the connection) |
| 2024-10-03 16:44:01 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) manwithluck |
| 2024-10-03 16:45:02 +0200 | crazazy | (~crazazy@tilde.town) crazazy |
| 2024-10-03 16:51:15 +0200 | Leonard26 | (~Leonard26@49.236.57.54) (Quit: Client closed) |
| 2024-10-03 16:51:25 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-10-03 16:51:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 16:53:08 +0200 | <geekosaur> | __monty__, no, it's not defaulting, it's the (considered by many to be broken) Enum instance for Double/Float |
| 2024-10-03 16:53:42 +0200 | <geekosaur> | (combined with the fact that the general behavior for "ticking" a floating point number doesn't do anything at all intuitive) |
| 2024-10-03 16:56:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-10-03 17:00:13 +0200 | rosco | (~rosco@183.171.106.209) rosco |
| 2024-10-03 17:00:58 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2024-10-03 17:01:57 +0200 | fireking04 | (~user@36-227-74-59.dynamic-ip.hinet.net) |
| 2024-10-03 17:07:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 17:09:46 +0200 | Leonard26 | (~Leonard26@49.236.57.54) |
| 2024-10-03 17:10:46 +0200 | <Leonard26> | [0.0,0.05..1.0] this seems to work well, but is there any way to turn that 5.0e-2 into 0.05? |
| 2024-10-03 17:12:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 17:13:56 +0200 | KicksonButt | (~quassel@2804:14d:7e52:809e:22e6:a05b:6e89:899e) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-10-03 17:14:26 +0200 | <geekosaur> | use a number formatter |
| 2024-10-03 17:14:31 +0200 | <int-e> | > Numeric.showFFloat Nothing 0.05 "" |
| 2024-10-03 17:14:33 +0200 | <lambdabot> | "0.05" |
| 2024-10-03 17:14:54 +0200 | <int-e> | (read the documentation too) |
| 2024-10-03 17:15:04 +0200 | Leonard26 | (~Leonard26@49.236.57.54) (Quit: Client closed) |
| 2024-10-03 17:19:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 17:19:11 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2024-10-03 17:28:13 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 17:28:36 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 276 seconds) |
| 2024-10-03 17:32:46 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 17:39:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 17:39:35 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-03 17:43:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 17:48:34 +0200 | vhs | (~vhs@d149-67-186-245.col.wideopenwest.com) vhs |
| 2024-10-03 17:50:14 +0200 | vhs | (~vhs@d149-67-186-245.col.wideopenwest.com) (Client Quit) |
| 2024-10-03 17:54:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 17:57:15 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) athan |
| 2024-10-03 17:57:54 +0200 | <haskellbridge> | <sm> I tend to use printf just for convenience |
| 2024-10-03 17:59:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 18:04:50 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-10-03 18:06:48 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-10-03 18:08:50 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-03 18:10:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 18:15:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 18:15:51 +0200 | <geekosaur> | I tend to avoid it because (a) very not-Haskell (b) subject to extremely weird type errors if you make a mistake or especially if you try to partially apply it |
| 2024-10-03 18:20:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 18:21:29 +0200 | billchenchina- | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) billchenchina |
| 2024-10-03 18:21:38 +0200 | <Franciman> | :t printf |
| 2024-10-03 18:21:39 +0200 | <lambdabot> | PrintfType r => String -> r |
| 2024-10-03 18:22:32 +0200 | <haskellbridge> | <sm> for me, having one versatile and familiar display-hammer usually outweighs those |
| 2024-10-03 18:22:51 +0200 | rosco | (~rosco@183.171.106.209) (Quit: Lost terminal) |
| 2024-10-03 18:24:05 +0200 | <geekosaur> | yeh but I always expect partial applicsation to work |
| 2024-10-03 18:24:34 +0200 | <geekosaur> | need an explicit type signature to do that with printf |
| 2024-10-03 18:25:17 +0200 | <ghoulguy> | printf can be a much more readable replacement for the code you'd need to replace it even with the extra type ascription |
| 2024-10-03 18:25:26 +0200 | <haskellbridge> | <sm> yes I wish it did with printf |
| 2024-10-03 18:25:52 +0200 | <haskellbridge> | <sm> (that's interesting, I never managed to get it working even with a type signature) |
| 2024-10-03 18:26:07 +0200 | <ghoulguy> | DSLs can be pretty great |
| 2024-10-03 18:26:22 +0200 | <haskellbridge> | <sm> indeed |
| 2024-10-03 18:26:48 +0200 | <haskellbridge> | <sm> regexps are another example |
| 2024-10-03 18:26:50 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-03 18:27:14 +0200 | <ghoulguy> | > let date = printf "%d/%d/%d" :: Int -> Int -> Int -> String in date 12 25 2024 |
| 2024-10-03 18:27:16 +0200 | <lambdabot> | "12/25/2024" |
| 2024-10-03 18:27:33 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2024-10-03 18:27:33 +0200 | ljdarj1 | ljdarj |
| 2024-10-03 18:28:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 18:35:22 +0200 | <EvanR> | that's a lot of code for what it's doing |
| 2024-10-03 18:35:39 +0200 | <EvanR> | oh, it's glguy again |
| 2024-10-03 18:37:07 +0200 | <geekosaur> | and it's demonstrating my point |
| 2024-10-03 18:38:24 +0200 | <ghoulguy> | it's demonstrating your prefernces |
| 2024-10-03 18:38:45 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-10-03 18:39:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 18:42:24 +0200 | <EvanR> | formatTime defaultTimeLocale "%Y/%m/%d" (fromGregorian 2024 25 12) |
| 2024-10-03 18:42:33 +0200 | <EvanR> | now it's a DSL and also shorter xD |
| 2024-10-03 18:42:38 +0200 | <ghoulguy> | yeah, that would also look worse without the DSL |
| 2024-10-03 18:43:31 +0200 | <EvanR> | and lambdabot can give me the type of this but can't evaluate it xD |
| 2024-10-03 18:43:44 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) (Remote host closed the connection) |
| 2024-10-03 18:43:50 +0200 | <EvanR> | that's against natural law |
| 2024-10-03 18:44:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-03 18:46:45 +0200 | <haskellbridge> | <sm> > printf "%.2f" 0.123 |
| 2024-10-03 18:46:53 +0200 | <haskellbridge> | <sm> ... |
| 2024-10-03 18:46:53 +0200 | <haskellbridge> | > printf "%.2f" 0.123 |
| 2024-10-03 18:46:55 +0200 | <lambdabot> | error: |
| 2024-10-03 18:46:55 +0200 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M404553957665... |
| 2024-10-03 18:46:55 +0200 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2024-10-03 18:47:20 +0200 | <haskellbridge> | <sm> bah. |
| 2024-10-03 18:47:20 +0200 | <haskellbridge> | > printf "%.2f" (0.123::Float) |
| 2024-10-03 18:47:22 +0200 | <lambdabot> | error: |
| 2024-10-03 18:47:22 +0200 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M344862853565... |
| 2024-10-03 18:47:22 +0200 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2024-10-03 18:47:38 +0200 | <ghoulguy> | geekosaur: Why is the bridge talking as itself? |
| 2024-10-03 18:47:44 +0200 | <EvanR> | > printf "%.2f" 0.123 :: String |
| 2024-10-03 18:47:46 +0200 | <lambdabot> | "0.12" |
| 2024-10-03 18:47:54 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-10-03 18:48:25 +0200 | <EvanR> | you can't use lambdabot through the bridge? yet? xD |
| 2024-10-03 18:48:26 +0200 | <geekosaur> | when sending multiline messages to IRC, only the first has a user prefix by default |
| 2024-10-03 18:48:26 +0200 | <haskellbridge> | <sm> sigh thank you EvanR! printf is still a bit of a pain but usually better than digging for type specific display functions and imports IMHO |
| 2024-10-03 18:48:36 +0200 | <haskellbridge> | <sm> * IME |
| 2024-10-03 18:48:36 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-10-03 18:48:51 +0200 | <geekosaur> | which is convenient if you want to use lambdabot across the bridge |
| 2024-10-03 18:49:47 +0200 | <haskellbridge> | <sm> so you need to write a nonempty first line, newline, then lambdabot command |
| 2024-10-03 18:52:45 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
| 2024-10-03 18:53:16 +0200 | <EvanR> | show (floor x) ++ "." ++ leftPad 2 '0' (show (floor (x * 100 `mod` 100))) |
| 2024-10-03 18:53:23 +0200 | <EvanR> | cabal install leftPad |
| 2024-10-03 18:53:32 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds) |
| 2024-10-03 18:55:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 18:57:34 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) raehik |
| 2024-10-03 18:58:36 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 18:59:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-10-03 19:01:34 +0200 | polyphem | (~rod@p4fc2c55e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-10-03 19:04:56 +0200 | <gentauro> | Hey all. Having a discussion with the author of https://discourse.haskell.org/t/question-on-a-simple-repl-example-for-side-effects/10459 about if `e = print 5` in `ghci` is not triggering `print 5` on binding due to `IO` effects (his claim) or due to Haskells lazy nature (my claim). Which is it? |
| 2024-10-03 19:05:03 +0200 | <gentauro> | Thx in advance :-) |
| 2024-10-03 19:05:37 +0200 | <geekosaur> | both to some extent, but the major omne is that `e` is bound to an IO action |
| 2024-10-03 19:07:06 +0200 | <geekosaur> | `:set -fprint-bind-result` will allow `let`s to show results but I think you'd just get a type error because `IO` actions don't have `Show` instances |
| 2024-10-03 19:07:11 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-10-03 19:07:29 +0200 | <gentauro> | geekosaur: my example for Ocaml/F# is: `let e = System.Console.WriteLine 5` would print 5. However: `let el () = System.Console.WriteLine 5` would not (this is how you tend to mimic Haskell lazyness in F# for example) |
| 2024-10-03 19:08:33 +0200 | <geekosaur> | right, but the way it's being mimicked will affect the result |
| 2024-10-03 19:09:19 +0200 | <geekosaur> | `e = print 5` binds `e` to an IO action. you need to sequence the IO action to have it do anything |
| 2024-10-03 19:10:03 +0200 | <geekosaur> | okay, I'm in count, must go, sorry |
| 2024-10-03 19:10:17 +0200 | <gentauro> | geekosaur: No probs and tx. |
| 2024-10-03 19:10:20 +0200 | <gentauro> | thx I mean |
| 2024-10-03 19:10:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 19:11:13 +0200 | <geekosaur> | I think with `-fprint-bind-result` you'll see it because ghci detects things that are in `MonadIO` and sequences them for you |
| 2024-10-03 19:11:45 +0200 | <geekosaur> | otherwise you'd need to evaluate `e` separately |
| 2024-10-03 19:11:53 +0200 | <gentauro> | λ> :set -fprint-bind-result |
| 2024-10-03 19:12:01 +0200 | <EvanR> | % print 5 |
| 2024-10-03 19:12:01 +0200 | <yahb2> | 5 |
| 2024-10-03 19:12:04 +0200 | <gentauro> | λ> e = print 5 |
| 2024-10-03 19:12:12 +0200 | <gentauro> | (0.01 secs, 114,280 bytes) |
| 2024-10-03 19:12:20 +0200 | <gentauro> | % e = print 5 |
| 2024-10-03 19:12:21 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:12:28 +0200 | <gentauro> | % !e = print 5 |
| 2024-10-03 19:12:28 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:12:34 +0200 | <gentauro> | hmmmm |
| 2024-10-03 19:12:38 +0200 | <c_wraith> | Yeah, seems to me that the best answer is "IO values aren't executed simply for existing" |
| 2024-10-03 19:12:48 +0200 | <EvanR> | except in ghci |
| 2024-10-03 19:13:03 +0200 | <c_wraith> | even simply *existing* doesn't cause them to execute in ghci |
| 2024-10-03 19:13:11 +0200 | <c_wraith> | seq (print 5) () |
| 2024-10-03 19:13:26 +0200 | <EvanR> | true, existence is an act of mental construction |
| 2024-10-03 19:13:30 +0200 | <c_wraith> | it's just that ghci binds IO actions that are entered at the top level |
| 2024-10-03 19:13:32 +0200 | <EvanR> | you actually have to type it in ghci |
| 2024-10-03 19:13:47 +0200 | <EvanR> | on top of that |
| 2024-10-03 19:14:06 +0200 | <EvanR> | gentauro was asking about ghci's behavior I thought |
| 2024-10-03 19:14:14 +0200 | <EvanR> | which is weird |
| 2024-10-03 19:14:51 +0200 | <c_wraith> | ghci's behavior is "you are entering lines in a do block that makes up the entry point of the program". Nice and simple. |
| 2024-10-03 19:14:57 +0200 | <gentauro> | EvanR: Yes and no. My guess for what author is experiencing was the lazy nature of Haskell and hereby `ghci` |
| 2024-10-03 19:15:07 +0200 | <c_wraith> | well, it was until people started demanding the ability to add declarations in ghci |
| 2024-10-03 19:15:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 19:15:12 +0200 | <c_wraith> | that made it complicated for no value |
| 2024-10-03 19:15:14 +0200 | <gentauro> | but I think that the behavior might have to due solely to `ghci` |
| 2024-10-03 19:15:51 +0200 | <EvanR> | ^ |
| 2024-10-03 19:16:00 +0200 | <c_wraith> | I mean, no |
| 2024-10-03 19:16:04 +0200 | <c_wraith> | seq (print 5) () |
| 2024-10-03 19:16:14 +0200 | <c_wraith> | that strictly evaluates (print 5) |
| 2024-10-03 19:16:22 +0200 | <geekosaur> | % :set -fprint-bind-result |
| 2024-10-03 19:16:22 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:16:27 +0200 | <c_wraith> | No relevant laziness |
| 2024-10-03 19:16:27 +0200 | <geekosaur> | % !e = print 5 |
| 2024-10-03 19:16:27 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:16:30 +0200 | <EvanR> | if the expression is an IO action it executes, otherwise no |
| 2024-10-03 19:16:36 +0200 | <geekosaur> | % !e <- print 5 |
| 2024-10-03 19:16:36 +0200 | <yahb2> | 5 |
| 2024-10-03 19:16:50 +0200 | <geekosaur> | okay, so print-bind-result doens't apply to let I guess |
| 2024-10-03 19:16:57 +0200 | <gentauro> | geekosaur: yeah, I noticed that |
| 2024-10-03 19:17:06 +0200 | <EvanR> | simulating being inside a do block theory has its wheels fall off sometimes |
| 2024-10-03 19:17:27 +0200 | <c_wraith> | EvanR: it used to be correct, before people insisted ghci become complicated for no reason |
| 2024-10-03 19:18:19 +0200 | <c_wraith> | (though you did have to accept that sometimes it inserts implicit uses of print) |
| 2024-10-03 19:18:27 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2024-10-03 19:19:02 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:20:42 +0200 | <c_wraith> | ah, here's an even better example of "not laziness" |
| 2024-10-03 19:20:54 +0200 | <c_wraith> | % evaluate (print 5) |
| 2024-10-03 19:20:54 +0200 | <yahb2> | <interactive>:47:1: error: [GHC-88464] ; Variable not in scope: evaluate :: IO () -> t |
| 2024-10-03 19:21:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 19:21:12 +0200 | <c_wraith> | % :m + Control.Exception |
| 2024-10-03 19:21:12 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:21:14 +0200 | <c_wraith> | % evaluate (print 5) |
| 2024-10-03 19:21:14 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:21:30 +0200 | <c_wraith> | that absolutely 100% evaluates the IO action. |
| 2024-10-03 19:21:53 +0200 | <gentauro> | %:t evaluate |
| 2024-10-03 19:21:56 +0200 | <gentauro> | % :t evaluate |
| 2024-10-03 19:21:56 +0200 | <yahb2> | evaluate :: a -> IO a |
| 2024-10-03 19:22:21 +0200 | <EvanR> | evaluates the argument to WHNF |
| 2024-10-03 19:22:39 +0200 | <EvanR> | only works in IO though |
| 2024-10-03 19:22:49 +0200 | <EvanR> | very useful |
| 2024-10-03 19:23:08 +0200 | <EvanR> | e.g. when the argument is something that might explode when evaluated and you want it to explode now |
| 2024-10-03 19:23:45 +0200 | <EvanR> | or would take up gratuitous resources to delay evaluation |
| 2024-10-03 19:24:19 +0200 | <c_wraith> | which is why it's hidden away inside Control.Exception - it was originally intended for turning bottoms into exceptions at a predictable point in the IO action |
| 2024-10-03 19:25:26 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-10-03 19:25:28 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) alexherbo2 |
| 2024-10-03 19:27:14 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:30:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-03 19:30:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 19:37:17 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-10-03 19:38:45 +0200 | fireking04 | (~user@36-227-74-59.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2024-10-03 19:39:53 +0200 | <EvanR> | it's not in prelude because people would be putting evaluate everywhere for no reason? xD |
| 2024-10-03 19:40:14 +0200 | <EvanR> | import Control.Exception signals your intentionality |
| 2024-10-03 19:41:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 19:45:24 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 246 seconds) |
| 2024-10-03 19:45:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 19:47:35 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:50:24 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-03 19:54:45 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-10-03 19:55:56 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:56:30 +0200 | vanishingideal | vanishing |
| 2024-10-03 19:56:37 +0200 | vanishing | vanishingideal |
| 2024-10-03 19:56:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 19:59:25 +0200 | <dolio> | Pretty sure ghci always allowed stuff like `5 + 5`. |
| 2024-10-03 20:03:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 20:03:07 +0200 | <dmj`> | > do do do 2 + 2 |
| 2024-10-03 20:03:09 +0200 | <lambdabot> | 4 |
| 2024-10-03 20:07:09 +0200 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2024-10-03 20:08:32 +0200 | gawen | (~gawen@user/gawen) gawen |
| 2024-10-03 20:09:14 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Remote host closed the connection) |
| 2024-10-03 20:13:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 20:14:03 +0200 | AWizzArd | (~code@gehrels.uberspace.de) (Changing host) |
| 2024-10-03 20:14:03 +0200 | AWizzArd | (~code@user/awizzard) AWizzard |
| 2024-10-03 20:18:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-10-03 20:20:37 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2024-10-03 20:21:04 +0200 | <c_wraith> | yeah, that's the "implicit print" case |
| 2024-10-03 20:22:38 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 20:23:11 +0200 | <dolio> | Oh, I see. |
| 2024-10-03 20:27:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-03 20:36:14 +0200 | noctux | (~noctux@user/noctux) (Read error: Connection reset by peer) |
| 2024-10-03 20:37:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 20:38:33 +0200 | noctux | (~noctux@user/noctux) noctux |
| 2024-10-03 20:38:39 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-10-03 20:38:46 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 252 seconds) |
| 2024-10-03 20:39:43 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-03 20:42:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-10-03 20:44:17 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-10-03 20:44:34 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
| 2024-10-03 20:51:14 +0200 | son0p | (~ff@190.69.124.252) (Ping timeout: 252 seconds) |
| 2024-10-03 20:51:43 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-10-03 20:52:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 20:55:35 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-10-03 20:55:54 +0200 | califax | (~califax@user/califx) califx |
| 2024-10-03 20:56:13 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds) |
| 2024-10-03 20:57:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-03 20:59:08 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-10-03 21:00:00 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-10-03 21:00:36 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2024-10-03 21:04:19 +0200 | TMA | (tma@twin.jikos.cz) (Ping timeout: 264 seconds) |
| 2024-10-03 21:04:35 +0200 | TMA | (tma@twin.jikos.cz) TMA |
| 2024-10-03 21:06:56 +0200 | visilii | (~visilii@46.61.242.109) |
| 2024-10-03 21:08:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 21:10:20 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 255 seconds) |
| 2024-10-03 21:10:55 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-10-03 21:11:46 +0200 | AlexZenon | (~alzenon@178.34.162.53) (Ping timeout: 252 seconds) |
| 2024-10-03 21:13:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-10-03 21:19:45 +0200 | AlexZenon | (~alzenon@178.34.162.53) |
| 2024-10-03 21:22:50 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-10-03 21:23:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |