2024/10/03

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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 00:05:57 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-10-03 00:12:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 00:17:16 +0200codaraxis___(~codaraxis@user/codaraxis) (Ping timeout: 244 seconds)
2024-10-03 00:17:24 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 00:18:49 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2024-10-03 00:23:16 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2024-10-03 00:24:27 +0200codaraxis(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 00:28:20 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 00:33:04 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 00:33:44 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2024-10-03 00:34:33 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2024-10-03 00:37:12 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds)
2024-10-03 00:39:31 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!)
2024-10-03 00:42:03 +0200notzmv(~daniel@user/notzmv) (Read error: Connection reset by peer)
2024-10-03 00:43:56 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 00:45:31 +0200neuroevolutus(~neuroevol@37.19.200.152) (Ping timeout: 256 seconds)
2024-10-03 00:48:47 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2024-10-03 00:50:00 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-10-03 00:55:08 +0200troojg(~troojg@user/troojg) troojg
2024-10-03 00:57:53 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 01:00:45 +0200ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en
2024-10-03 01:00:50 +0200ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit)
2024-10-03 01:02:42 +0200merijn(~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 +0200supercode(~supercode@user/supercode) supercode
2024-10-03 01:13:19 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 01:18:45 +0200merijn(~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 +0200Katarushisu(~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Quit: Ping timeout (120 seconds))
2024-10-03 01:24:56 +0200Katarushisu(~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu
2024-10-03 01:29:39 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 01:30:07 +0200sawilagar(~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 +0200xff0x(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 01:40:21 +0200neuroevolutus(~neuroevol@37.19.200.152) neuroevolutus
2024-10-03 01:45:04 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 01:45:13 +0200xff0x(~xff0x@2405:6580:b080:900:409b:fd54:4c14:6dc)
2024-10-03 01:46:43 +0200neuroevolutus(~neuroevol@37.19.200.152) (Ping timeout: 256 seconds)
2024-10-03 01:49:32 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2024-10-03 01:49:41 +0200merijn(~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 +0200alexherbo2(~alexherbo@2a02-8440-3118-adab-ad64-111d-10db-8d9d.rev.sfr.net) (Remote host closed the connection)
2024-10-03 01:57:42 +0200alexherbo2(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 02:01:14 +0200alexherbo2(~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 +0200merijn(~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 +0200troojg(~troojg@user/troojg) (Ping timeout: 276 seconds)
2024-10-03 02:12:23 +0200supercode(~supercode@user/supercode) (Quit: Client closed)
2024-10-03 02:15:55 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 02:22:16 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2024-10-03 02:27:52 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: JuanDaugherty)
2024-10-03 02:32:32 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 02:37:06 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 02:43:00 +0200nkatte(~nkatte@191.177.174.42) (Quit: nkatte)
2024-10-03 02:44:11 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-10-03 02:45:41 +0200xff0x(~xff0x@2405:6580:b080:900:409b:fd54:4c14:6dc) (Ping timeout: 248 seconds)
2024-10-03 02:48:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 02:50:03 +0200acidjnk(~acidjnk@p200300d6e72cfb85cd0cf194bbc9b0a3.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2024-10-03 02:55:04 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 02:55:12 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2024-10-03 03:01:32 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 272 seconds)
2024-10-03 03:06:11 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2024-10-03 03:06:17 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 03:06:18 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 03:11:16 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 03:12:07 +0200weary-traveler(~user@user/user363627) user363627
2024-10-03 03:21:45 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 03:27:42 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 03:33:06 +0200tomboy64(~tomboy64@user/tomboy64) (Ping timeout: 246 seconds)
2024-10-03 03:38:27 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 03:42:13 +0200xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2024-10-03 03:42:24 +0200shailangsa(~shailangs@host86-182-139-82.range86-182.btcentralplus.com) shailangsa
2024-10-03 03:43:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 03:47:05 +0200tomboy64(~tomboy64@user/tomboy64) tomboy64
2024-10-03 03:50:10 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) athan
2024-10-03 03:54:11 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 03:58:59 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 04:09:42 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 04:14:35 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 04:19:25 +0200td_(~td@i5387093C.versanet.de) (Ping timeout: 265 seconds)
2024-10-03 04:20:56 +0200td_(~td@i5387091A.versanet.de) td_
2024-10-03 04:25:24 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 04:26:46 +0200codaraxis__(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 04:29:40 +0200Digitteknohippie(~user@user/digit) Digit
2024-10-03 04:29:54 +0200codaraxis(~codaraxis@user/codaraxis) (Ping timeout: 260 seconds)
2024-10-03 04:29:54 +0200Digit(~user@user/digit) (Ping timeout: 260 seconds)
2024-10-03 04:29:54 +0200lambdabot(~lambdabot@haskell/bot/lambdabot) (Ping timeout: 260 seconds)
2024-10-03 04:30:02 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 04:31:17 +0200lambdabot(~lambdabot@haskell/bot/lambdabot) lambdabot
2024-10-03 04:31:17 +0200ChanServ+v lambdabot
2024-10-03 04:34:48 +0200identity(~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4))
2024-10-03 04:36:07 +0200DigitteknohippieDigit
2024-10-03 04:40:50 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 04:43:35 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds)
2024-10-03 04:45:39 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 04:49:26 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2024-10-03 04:51:07 +0200neuroevolutus(~neuroevol@37.19.200.152) neuroevolutus
2024-10-03 04:51:29 +0200komikat(~user@218.185.248.66) (Ping timeout: 260 seconds)
2024-10-03 04:56:26 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 04:56:33 +0200neuroevolutus(~neuroevol@37.19.200.152) (Ping timeout: 256 seconds)
2024-10-03 04:56:46 +0200neuroevolutus(~neuroevol@146.70.211.46) neuroevolutus
2024-10-03 05:01:34 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 05:06:13 +0200zmt01(~zmt00@user/zmt00) zmt00
2024-10-03 05:10:13 +0200zmt00(~zmt00@user/zmt00) (Ping timeout: 248 seconds)
2024-10-03 05:12:46 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 05:17:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 05:19:32 +0200aforemny_(~aforemny@i59F4C77A.versanet.de) aforemny
2024-10-03 05:20:48 +0200aforemny(~aforemny@2001:9e8:6cd7:c200:342e:20f9:8752:4727) (Ping timeout: 265 seconds)
2024-10-03 05:26:03 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2024-10-03 05:28:11 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 05:32:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 05:41:39 +0200billchenchina-(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) billchenchina
2024-10-03 05:43:18 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds)
2024-10-03 05:43:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 05:44:18 +0200Lord_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 +0200merijn(~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 +0200pavonia(~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 +0200mud(~mud@user/kadoban) (Quit: quit)
2024-10-03 05:59:09 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 06:00:48 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 246 seconds)
2024-10-03 06:01:10 +0200cyphase(~cyphase@user/cyphase) cyphase
2024-10-03 06:02:30 +0200mud(~mud@user/kadoban) kadoban
2024-10-03 06:03:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-10-03 06:06:56 +0200mud(~mud@user/kadoban) (Client Quit)
2024-10-03 06:08:21 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-10-03 06:10:07 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 06:10:25 +0200mud(~mud@user/kadoban) kadoban
2024-10-03 06:12:45 +0200Tisoxin(~Ikosit@user/ikosit) Ikosit
2024-10-03 06:14:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-03 06:15:59 +0200amano(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 +0200merijn(~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 +0200merijn(~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 +0200merijn(~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 +0200merijn(~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 +0200michalz(~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 +0200merijn(~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 +0200merijn(~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 +0200Smiles(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 +0200merijn(~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 +0200merijn(~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 +0200merijn(~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 +0200takuan(~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 +0200merijn(~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 +0200JuanDaugherty(~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 +0200ThePenguin(~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 +0200sand-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 +0200aforemny_(~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 +0200aforemny(~aforemny@i59F4C77A.versanet.de) aforemny
2024-10-03 07:27:57 +0200sand-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 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-10-03 07:32:51 +0200merijn(~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 +0200neuroevolutus(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 07:39:42 +0200tzh_(~tzh@c-76-115-131-146.hsd1.or.comcast.net)
2024-10-03 07:40:23 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: JuanDaugherty)
2024-10-03 07:40:41 +0200tzh(~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 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds)
2024-10-03 07:43:56 +0200hueso(~root@user/hueso) (Ping timeout: 255 seconds)
2024-10-03 07:44:06 +0200hueso(~root@user/hueso) hueso
2024-10-03 07:45:52 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) TheCoffeMaker
2024-10-03 07:48:23 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 07:52:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 08:00:09 +0200m5zs7k(aquares@web10.mydevil.net) (Ping timeout: 246 seconds)
2024-10-03 08:01:52 +0200adanwan_(~adanwan@gateway/tor-sasl/adanwan) adanwan
2024-10-03 08:02:11 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 260 seconds)
2024-10-03 08:03:51 +0200merijn(~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 +0200araujo(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-10-03 08:11:07 +0200merijn(~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 +0200m5zs7k(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 +0200neuroevolutus(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 08:18:47 +0200benjaminl(~benjaminl@user/benjaminl) (Read error: Connection reset by peer)
2024-10-03 08:19:03 +0200benjaminl(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 08:27:02 +0200amano(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 +0200merijn(~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 +0200merijn(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2024-10-03 08:47:03 +0200amano(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 +0200lortabac(~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 +0200neuroevolutus(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 08:57:53 +0200ThePenguin(~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 +0200caconym(~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 +0200caconym(~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 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 09:02:27 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-03 09:04:06 +0200paddymahoney(~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 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 09:09:22 +0200billchenchina-(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection)
2024-10-03 09:10:55 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 09:15:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-10-03 09:16:19 +0200peterbecich(~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 +0200AWizzArd(~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 +0200lxsameer(~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 +0200AWizzArd(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 09:26:19 +0200synchromesh(~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 +0200synchromesh(~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 +0200xff0x_(~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 +0200alioguzhan(~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 +0200alioguzhan(~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 +0200merijn(~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 +0200xff0x(~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 +0200amano(amano@gateway/vpn/airvpn/amano) (Quit: amano)
2024-10-03 09:35:15 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2024-10-03 09:38:10 +0200polyphem(~rod@p4fc2c55e.dip0.t-ipconnect.de) polyphem
2024-10-03 09:39:52 +0200arahael(~arahael@user/arahael) (Remote host closed the connection)
2024-10-03 09:41:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 09:42:47 +0200machinedgod(~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod
2024-10-03 09:42:52 +0200tzh_(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-10-03 09:46:43 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2024-10-03 09:46:49 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 09:48:30 +0200raym(~ray@user/raym) (Quit: updating server)
2024-10-03 09:54:35 +0200misterfish(~misterfis@84.53.85.146) misterfish
2024-10-03 09:57:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 10:02:24 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 10:12:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 10:17:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 10:25:57 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-10-03 10:26:05 +0200Inst_(~Inst@user/Inst) Inst
2024-10-03 10:27:42 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 10:28:41 +0200Inst(~Inst@user/Inst) (Ping timeout: 265 seconds)
2024-10-03 10:32:17 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 10:39:19 +0200mari-estel(~mari-este@dynamic-176-000-160-069.176.0.pool.telefonica.de)
2024-10-03 10:39:56 +0200alexherbo2(~alexherbo@2a02-8440-3207-288e-206f-9822-5a5d-6079.rev.sfr.net) alexherbo2
2024-10-03 10:43:08 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 10:44:07 +0200alexherbo2(~alexherbo@2a02-8440-3207-288e-206f-9822-5a5d-6079.rev.sfr.net) (Remote host closed the connection)
2024-10-03 10:46:58 +0200acidjnk(~acidjnk@p200300d6e72cfb63d87029be15e343a0.dip0.t-ipconnect.de) acidjnk
2024-10-03 10:47:54 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 10:50:44 +0200feetwind(~mike@user/feetwind) (Quit: WeeChat 4.1.2)
2024-10-03 10:52:35 +0200liamzy__(~Inst@user/Inst) Inst
2024-10-03 10:55:01 +0200Inst_(~Inst@user/Inst) (Ping timeout: 252 seconds)
2024-10-03 10:58:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 11:03:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 11:12:14 +0200yoneda(~mike@193.206.102.122)
2024-10-03 11:13:06 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 11:14:19 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) kuribas
2024-10-03 11:17:45 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 11:19:11 +0200raym(~ray@user/raym) raym
2024-10-03 11:26:41 +0200leah2(~leah@vuxu.org) (Ping timeout: 255 seconds)
2024-10-03 11:28:38 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 11:32:48 +0200sawilagar(~sawilagar@user/sawilagar) sawilagar
2024-10-03 11:33:26 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2024-10-03 11:39:56 +0200leah2(~leah@vuxu.org) leah2
2024-10-03 11:43:49 +0200xff0x_(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds)
2024-10-03 11:44:04 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 11:44:35 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 11:46:34 +0200misterfish(~misterfis@84.53.85.146) (Ping timeout: 272 seconds)
2024-10-03 11:48:56 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 11:55:23 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 245 seconds)
2024-10-03 11:55:25 +0200sawilagar(~sawilagar@user/sawilagar) (Remote host closed the connection)
2024-10-03 11:55:39 +0200sawilagar(~sawilagar@user/sawilagar) sawilagar
2024-10-03 11:59:40 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 11:59:56 +0200Digitteknohippie(~user@user/digit) Digit
2024-10-03 12:00:30 +0200Digit(~user@user/digit) (Ping timeout: 272 seconds)
2024-10-03 12:02:58 +0200lortabac(~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 +0200pointlessslippe1(~pointless@62.106.85.17) (Read error: Connection reset by peer)
2024-10-03 12:04:42 +0200Digitteknohippie(~user@user/digit) (Ping timeout: 252 seconds)
2024-10-03 12:06:54 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 12:09:32 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2024-10-03 12:09:34 +0200mari-estel(~mari-este@dynamic-176-000-160-069.176.0.pool.telefonica.de) (Ping timeout: 260 seconds)
2024-10-03 12:10:13 +0200pointlessslippe1(~pointless@62.106.85.17) pointlessslippe1
2024-10-03 12:14:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 12:16:38 +0200hueso(~root@user/hueso) (Ping timeout: 245 seconds)
2024-10-03 12:17:36 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 272 seconds)
2024-10-03 12:18:53 +0200merijn(~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 +0200araujo(~araujo@216.73.163.154) (Remote host closed the connection)
2024-10-03 12:29:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 12:33:03 +0200sawilagar(~sawilagar@user/sawilagar) (Remote host closed the connection)
2024-10-03 12:33:27 +0200sawilagar(~sawilagar@user/sawilagar) sawilagar
2024-10-03 12:34:11 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2024-10-03 12:41:46 +0200xff0x(~xff0x@2405:6580:b080:900:1c0c:a36e:c661:24b2)
2024-10-03 12:41:48 +0200morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net)
2024-10-03 12:45:00 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 12:46:19 +0200morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds)
2024-10-03 12:48:21 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-10-03 12:49:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 12:56:15 +0200alp_(~alp@2001:861:e3d6:8f80:ae1f:5c06:1786:e17) (Ping timeout: 246 seconds)
2024-10-03 12:56:55 +0200Digit(~user@user/digit) Digit
2024-10-03 13:00:04 +0200caconym(~caconym@user/caconym) (Quit: bye)
2024-10-03 13:00:32 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 13:02:16 +0200caconym(~caconym@user/caconym) caconym
2024-10-03 13:05:00 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-03 13:15:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 13:16:31 +0200smalltalkman(uid545680@id-545680.hampstead.irccloud.com) smalltalkman
2024-10-03 13:19:52 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 13:24:03 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) libertyprime
2024-10-03 13:30:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 13:35:54 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 13:38:35 +0200codaraxis(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 13:41:32 +0200codaraxis__(~codaraxis@user/codaraxis) (Ping timeout: 265 seconds)
2024-10-03 13:43:27 +0200codaraxis__(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 13:46:17 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 13:47:34 +0200codaraxis(~codaraxis@user/codaraxis) (Ping timeout: 260 seconds)
2024-10-03 13:48:21 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-10-03 13:51:12 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 13:52:00 +0200identity(~identity@user/ZharMeny) identity
2024-10-03 14:01:02 +0200libertyprime(~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 +0200merijn(~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 +0200merijn(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 14:20:37 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-10-03 14:23:09 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds)
2024-10-03 14:26:32 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 14:31:36 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 14:36:38 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 14:41:57 +0200aforemny(~aforemny@i59F4C77A.versanet.de) (Ping timeout: 248 seconds)
2024-10-03 14:47:04 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 14:50:09 +0200pointlessslippe1(~pointless@62.106.85.17) (Read error: Connection reset by peer)
2024-10-03 14:52:36 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-10-03 14:56:17 +0200nckhexen(nckx@libera/staff/owl/nckx) (Ping timeout: 608 seconds)
2024-10-03 14:57:28 +0200weary-traveler(~user@user/user363627) user363627
2024-10-03 14:57:55 +0200pointlessslippe1(~pointless@62.106.85.17) pointlessslippe1
2024-10-03 15:02:41 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 15:05:26 +0200codaraxis__(~codaraxis@user/codaraxis) (Ping timeout: 272 seconds)
2024-10-03 15:05:28 +0200hueso(~root@user/hueso) hueso
2024-10-03 15:07:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 15:17:06 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 15:22:02 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2024-10-03 15:22:15 +0200alp_(~alp@2001:861:e3d6:8f80:a9cc:355d:4963:1655)
2024-10-03 15:31:34 +0200identity(~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4))
2024-10-03 15:32:39 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 15:35:57 +0200identity(~identity@user/ZharMeny) identity
2024-10-03 15:37:27 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2024-10-03 15:42:09 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2024-10-03 15:44:36 +0200alexherbo2(~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) alexherbo2
2024-10-03 15:48:11 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 15:49:55 +0200identity(~identity@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4))
2024-10-03 15:50:28 +0200identity(~identity@user/ZharMeny) identity
2024-10-03 15:52:59 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 15:55:54 +0200ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2024-10-03 15:57:05 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2024-10-03 15:57:05 +0200ljdarj1ljdarj
2024-10-03 16:03:40 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 16:08:15 +0200codaraxis(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 16:08:18 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds)
2024-10-03 16:09:59 +0200codaraxis__(~codaraxis@user/codaraxis) Codaraxis
2024-10-03 16:11:00 +0200codaraxis__(~codaraxis@user/codaraxis) (Max SendQ exceeded)
2024-10-03 16:13:47 +0200codaraxis(~codaraxis@user/codaraxis) (Ping timeout: 265 seconds)
2024-10-03 16:15:49 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2)
2024-10-03 16:18:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 16:19:21 +0200crazazy(~user@mail.wibeco.nl) crazazy
2024-10-03 16:22:19 +0200Leonard26(~Leonard26@49.236.57.54)
2024-10-03 16:24:53 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2024-10-03 16:25:02 +0200merijn(~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 +0200paddymahoney(~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 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 16:32:14 +0200KicksonButt(~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 +0200crazazy(~user@mail.wibeco.nl) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4))
2024-10-03 16:36:27 +0200merijn(~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 +0200merijn(~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 +0200manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck) (Remote host closed the connection)
2024-10-03 16:44:01 +0200manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck) manwithluck
2024-10-03 16:45:02 +0200crazazy(~crazazy@tilde.town) crazazy
2024-10-03 16:51:15 +0200Leonard26(~Leonard26@49.236.57.54) (Quit: Client closed)
2024-10-03 16:51:25 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) (Ping timeout: 252 seconds)
2024-10-03 16:51:52 +0200merijn(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2024-10-03 17:00:13 +0200rosco(~rosco@183.171.106.209) rosco
2024-10-03 17:00:58 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds)
2024-10-03 17:01:57 +0200fireking04(~user@36-227-74-59.dynamic-ip.hinet.net)
2024-10-03 17:07:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 17:09:46 +0200Leonard26(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-10-03 17:13:56 +0200KicksonButt(~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 +0200Leonard26(~Leonard26@49.236.57.54) (Quit: Client closed)
2024-10-03 17:19:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 17:19:11 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) marinelli
2024-10-03 17:28:13 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 17:28:36 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 276 seconds)
2024-10-03 17:32:46 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 17:39:24 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 17:39:35 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2024-10-03 17:43:49 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-10-03 17:48:34 +0200vhs(~vhs@d149-67-186-245.col.wideopenwest.com) vhs
2024-10-03 17:50:14 +0200vhs(~vhs@d149-67-186-245.col.wideopenwest.com) (Client Quit)
2024-10-03 17:54:49 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 17:57:15 +0200athan(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 18:04:50 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2024-10-03 18:06:48 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2024-10-03 18:08:50 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 18:10:17 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 18:15:19 +0200merijn(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 18:21:29 +0200billchenchina-(~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 +0200rosco(~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 +0200ljdarj1(~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 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds)
2024-10-03 18:27:33 +0200ljdarj1ljdarj
2024-10-03 18:28:05 +0200merijn(~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 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2024-10-03 18:39:32 +0200merijn(~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 +0200alexherbo2(~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 +0200merijn(~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 +0200euphores(~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 +0200tzh(~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 +0200euphores(~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 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
2024-10-03 18:55:02 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 18:57:34 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) raehik
2024-10-03 18:58:36 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 18:59:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds)
2024-10-03 19:01:34 +0200polyphem(~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 +0200ash3en(~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 +0200merijn(~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 +0200merijn(~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 +0200machinedgod(~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 276 seconds)
2024-10-03 19:19:02 +0200vanishingideal(~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 +0200merijn(~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 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 252 seconds)
2024-10-03 19:25:28 +0200alexherbo2(~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) alexherbo2
2024-10-03 19:27:14 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 19:30:07 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-10-03 19:30:30 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 19:37:17 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla
2024-10-03 19:38:45 +0200fireking04(~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 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 19:45:24 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 246 seconds)
2024-10-03 19:45:58 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 19:47:35 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 19:50:24 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 19:54:45 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 252 seconds)
2024-10-03 19:55:56 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 19:56:30 +0200vanishingidealvanishing
2024-10-03 19:56:37 +0200vanishingvanishingideal
2024-10-03 19:56:43 +0200merijn(~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 +0200merijn(~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 +0200gawen(~gawen@user/gawen) (Quit: cya)
2024-10-03 20:08:32 +0200gawen(~gawen@user/gawen) gawen
2024-10-03 20:09:14 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Remote host closed the connection)
2024-10-03 20:13:58 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 20:14:03 +0200AWizzArd(~code@gehrels.uberspace.de) (Changing host)
2024-10-03 20:14:03 +0200AWizzArd(~code@user/awizzard) AWizzard
2024-10-03 20:18:18 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-03 20:20:37 +0200vanishingideal(~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 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 20:23:11 +0200 <dolio> Oh, I see.
2024-10-03 20:27:36 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-10-03 20:36:14 +0200noctux(~noctux@user/noctux) (Read error: Connection reset by peer)
2024-10-03 20:37:30 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 20:38:33 +0200noctux(~noctux@user/noctux) noctux
2024-10-03 20:38:39 +0200Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2024-10-03 20:38:46 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 252 seconds)
2024-10-03 20:39:43 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-10-03 20:42:22 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2024-10-03 20:44:17 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en
2024-10-03 20:44:34 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit)
2024-10-03 20:51:14 +0200son0p(~ff@190.69.124.252) (Ping timeout: 252 seconds)
2024-10-03 20:51:43 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2024-10-03 20:52:55 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 20:55:35 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-10-03 20:55:54 +0200califax(~califax@user/califx) califx
2024-10-03 20:56:13 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
2024-10-03 20:57:30 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 20:59:08 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 21:00:00 +0200caconym(~caconym@user/caconym) (Quit: bye)
2024-10-03 21:00:36 +0200caconym(~caconym@user/caconym) caconym
2024-10-03 21:04:19 +0200TMA(tma@twin.jikos.cz) (Ping timeout: 264 seconds)
2024-10-03 21:04:35 +0200TMA(tma@twin.jikos.cz) TMA
2024-10-03 21:06:56 +0200visilii(~visilii@46.61.242.109)
2024-10-03 21:08:22 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 21:10:20 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 255 seconds)
2024-10-03 21:10:55 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-10-03 21:11:46 +0200AlexZenon(~alzenon@178.34.162.53) (Ping timeout: 252 seconds)
2024-10-03 21:13:30 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-10-03 21:19:45 +0200AlexZenon(~alzenon@178.34.162.53)
2024-10-03 21:22:50 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!)
2024-10-03 21:23:06 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 21:27:31 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 21:28:34 +0200lystra(~lystra@208.59.105.41) (Ping timeout: 260 seconds)
2024-10-03 21:31:49 +0200lystra(~lystra@208.59.105.41) lystra
2024-10-03 21:38:31 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 21:42:06 +0200ljdarj(~Thunderbi@user/ljdarj) (Quit: ljdarj)
2024-10-03 21:42:34 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 260 seconds)
2024-10-03 21:43:18 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 21:44:00 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 21:44:44 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds)
2024-10-03 21:47:47 +0200paddymahoney(~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com)
2024-10-03 21:54:05 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 21:56:51 +0200alexherbo2(~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) (Remote host closed the connection)
2024-10-03 21:58:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2024-10-03 22:02:22 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-10-03 22:09:28 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 22:10:34 +0200Digitteknohippie(~user@user/digit) Digit
2024-10-03 22:10:48 +0200Digit(~user@user/digit) (Ping timeout: 252 seconds)
2024-10-03 22:13:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-03 22:13:54 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-10-03 22:16:52 +0200DigitteknohippieDigit
2024-10-03 22:18:48 +0200billchenchina-(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection)
2024-10-03 22:23:43 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 245 seconds)
2024-10-03 22:24:06 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 22:25:50 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en
2024-10-03 22:25:55 +0200michalz(~michalz@185.246.207.203) (Remote host closed the connection)
2024-10-03 22:27:49 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit)
2024-10-03 22:28:46 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 22:29:08 +0200ubert(~Thunderbi@178.165.166.66.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
2024-10-03 22:29:37 +0200TonyStone(~TonyStone@user/TonyStone) (Remote host closed the connection)
2024-10-03 22:32:56 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-10-03 22:33:10 +0200califax(~califax@user/califx) califx
2024-10-03 22:35:38 +0200machinedgod(~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod
2024-10-03 22:36:07 +0200dyniec(~dyniec@dybiec.info) dyniec
2024-10-03 22:36:27 +0200mvk(~mvk@2607:fea8:5c96:5800::e590) mvk
2024-10-03 22:39:31 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 22:39:53 +0200mvk(~mvk@2607:fea8:5c96:5800::e590) (Client Quit)
2024-10-03 22:44:10 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 22:46:03 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2024-10-03 22:46:42 +0200morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net)
2024-10-03 22:51:14 +0200morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds)
2024-10-03 22:54:56 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 22:59:47 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 23:00:14 +0200son0p(~ff@186.121.100.73) son0p
2024-10-03 23:00:54 +0200ghodawalaaman(~thelounge@user/thelounge8234) (Read error: Connection reset by peer)
2024-10-03 23:01:40 +0200ephilalethes(~noumenon@113.51-175-156.customer.lyse.net) noumenon
2024-10-03 23:01:49 +0200ghodawalaaman(~thelounge@user/thelounge8234) ghodawalaaman
2024-10-03 23:08:56 +0200gmg(~user@user/gehmehgeh) gehmehgeh
2024-10-03 23:10:27 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 23:10:30 +0200leah2(~leah@vuxu.org) (Ping timeout: 276 seconds)
2024-10-03 23:10:46 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2024-10-03 23:14:42 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2024-10-03 23:19:33 +0200L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2024-10-03 23:22:31 +0200shailangsa(~shailangs@host86-182-139-82.range86-182.btcentralplus.com) (Remote host closed the connection)
2024-10-03 23:22:34 +0200leah2(~leah@vuxu.org) leah2
2024-10-03 23:25:53 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 23:30:02 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 23:30:12 +0200_d0t(~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 272 seconds)
2024-10-03 23:30:35 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit)
2024-10-03 23:30:43 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-10-03 23:32:12 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-10-03 23:33:19 +0200_d0t(~{-d0t-}@user/-d0t-/x-7915216) {-d0t-}
2024-10-03 23:33:23 +0200ephilalethes(~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer)
2024-10-03 23:39:33 +0200ephilalethes(~noumenon@113.51-175-156.customer.lyse.net) noumenon
2024-10-03 23:40:19 +0200identity(~identity@user/ZharMeny) (Ping timeout: 264 seconds)
2024-10-03 23:41:28 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 23:46:08 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-03 23:47:33 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) libertyprime
2024-10-03 23:48:23 +0200supercode(~supercode@user/supercode) supercode
2024-10-03 23:49:47 +0200identity(~identity@user/ZharMeny) identity
2024-10-03 23:52:58 +0200Angelz(Angelz@Angelz.oddprotocol.org) (Changing host)
2024-10-03 23:52:58 +0200Angelz(Angelz@user/angelz) angelz
2024-10-03 23:56:54 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 23:57:19 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) athan