| 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. |