Home liberachat/#haskell: Logs Calendar

Logs on 2024-06-20 (liberachat/#haskell)

00:00:20 × hgolden_ quits (~hgolden@syn-172-251-233-141.res.spectrum.com) (Remote host closed the connection)
00:09:38 × peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
00:10:01 → peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
00:10:11 × euleritian quits (~euleritia@dynamic-176-001-131-134.176.1.pool.telefonica.de) (Ping timeout: 252 seconds)
00:12:19 × peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Client Quit)
00:12:42 → peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
00:15:37 → euleritian joins (~euleritia@dynamic-176-002-140-016.176.2.pool.telefonica.de)
00:22:44 × whatsupdoc quits (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
00:23:41 × falafel quits (~falafel@2a0c:5a87:3103:ec01::62b8) (Ping timeout: 240 seconds)
00:24:44 × euleritian quits (~euleritia@dynamic-176-002-140-016.176.2.pool.telefonica.de) (Ping timeout: 256 seconds)
00:26:01 → euleritian joins (~euleritia@dynamic-176-000-200-205.176.0.pool.telefonica.de)
00:37:47 × henry40408 quits (~henry4040@175.182.111.183) (Quit: Ping timeout (120 seconds))
00:38:15 → henry40408 joins (~henry4040@175.182.111.183)
00:38:33 × machinedgod quits (~machinedg@d173-183-246-216.abhsia.telus.net) (Quit: Lost terminal)
00:38:53 → machinedgod joins (~machinedg@d173-183-246-216.abhsia.telus.net)
00:42:35 × euleritian quits (~euleritia@dynamic-176-000-200-205.176.0.pool.telefonica.de) (Ping timeout: 264 seconds)
00:43:29 × CrunchyFlakes quits (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer)
00:44:36 → euleritian joins (~euleritia@dynamic-176-006-000-101.176.6.pool.telefonica.de)
00:45:51 → CrunchyFlakes joins (~CrunchyFl@146.52.130.128)
00:47:10 × kyborg2011 quits (~kyborg201@host-176-36-215-61.b024.la.net.ua) (Ping timeout: 246 seconds)
00:50:10 × segfaultfizzbuzz quits (~segfaultf@23-93-189-95.fiber.dynamic.sonic.net) (Remote host closed the connection)
00:53:28 → kyborg2011 joins (~kyborg201@host-176-36-215-61.b024.la.net.ua)
01:00:03 × machinedgod quits (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds)
01:05:39 × euleritian quits (~euleritia@dynamic-176-006-000-101.176.6.pool.telefonica.de) (Ping timeout: 260 seconds)
01:07:02 → euleritian joins (~euleritia@dynamic-176-006-011-015.176.6.pool.telefonica.de)
01:09:40 × peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
01:14:16 × bionade24 quits (~quassel@2a03:4000:33:45b::1) (Remote host closed the connection)
01:15:25 → bionade24 joins (~quassel@2a03:4000:33:45b::1)
01:23:39 × danza quits (~francesco@151.37.122.33) (Ping timeout: 264 seconds)
01:26:54 × talismanick quits (~user@2601:644:937c:ed10::ae5) (Remote host closed the connection)
01:32:47 × ChaiTRex quits (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
01:36:10 → hgolden joins (~hgolden@2603:8000:9d00:3ed1:2678:8497:aa5c:7fa9)
01:41:01 → madhavanmiui joins (~madhavanm@2409:40f4:ae:dd09:8000::)
01:42:31 × madhavanmiui quits (~madhavanm@2409:40f4:ae:dd09:8000::) (Client Quit)
01:50:59 × kyborg2011 quits (~kyborg201@host-176-36-215-61.b024.la.net.ua) (Ping timeout: 264 seconds)
01:51:30 → talismanick joins (~user@2601:644:937c:ed10::ae5)
01:53:11 × emmanuelux quits (~emmanuelu@user/emmanuelux) (Quit: au revoir)
01:53:56 → kyborg2011 joins (~kyborg201@host-176-36-215-61.b024.la.net.ua)
02:01:41 × euleritian quits (~euleritia@dynamic-176-006-011-015.176.6.pool.telefonica.de) (Ping timeout: 240 seconds)
02:02:06 × petrichor quits (~znc-user@user/petrichor) (Quit: ZNC 1.8.2 - https://znc.in)
02:03:29 → petrichor joins (~znc-user@user/petrichor)
02:04:11 × xff0x quits (~xff0x@ai068022.d.east.v6connect.net) (Ping timeout: 264 seconds)
02:06:31 → euleritian joins (~euleritia@dynamic-176-007-145-030.176.7.pool.telefonica.de)
02:12:22 <monochrom> Intent requires true AI (not even today's LLM). But if type checking succeeds, it's sound, i.e., as correct as the type system can tell.
02:13:47 <geekosaur> right, that warning says that you may get unexpected type checking failures because type inference might not work
02:13:59 <geekosaur> but if it does typecheck, you're fine
02:14:15 <geekosaur> (or you can just give everything explicit types)
02:25:10 × zzz quits (~yin@user/zero) (Ping timeout: 268 seconds)
02:29:48 <probie> Re give everything explicit types: I sometimes wish I had some way to say "should be inferred as having type [α-equivalent to] τ"
02:33:08 <probie> That way I could write something like `stutter ::[inferred] [a] -> [a]; stutter = foldr (\x xs -> x:x:xs) []` and the compiler can warn me that I've picked a type more specific than what would have been inferred
02:38:33 → causal joins (~eric@50.35.88.207)
02:44:53 × euleritian quits (~euleritia@dynamic-176-007-145-030.176.7.pool.telefonica.de) (Ping timeout: 240 seconds)
02:46:07 → euleritian joins (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de)
02:53:43 → xff0x joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
02:56:00 × td_ quits (~td@i53870921.versanet.de) (Ping timeout: 268 seconds)
02:57:43 → td_ joins (~td@i5387090C.versanet.de)
02:58:53 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
03:02:10 × Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
03:08:59 × sam113101 quits (~sam@24.157.253.231) (Remote host closed the connection)
03:15:38 × xdminsy quits (~xdminsy@117.147.70.231) (Quit: Konversation terminated!)
03:33:40 → sam113101 joins (~sam@24.157.253.231)
03:43:17 → aforemny_ joins (~aforemny@i59F516D3.versanet.de)
03:44:39 × aforemny quits (~aforemny@2001:9e8:6cc0:df00:949a:33df:9d68:3e31) (Ping timeout: 264 seconds)
04:07:21 × Square2 quits (~Square4@user/square) (Read error: Connection reset by peer)
04:08:23 × waleee quits (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds)
04:09:07 × iqubic quits (~sophia@2601:602:9502:c70:f6b8:a053:cf21:deda) (Ping timeout: 246 seconds)
04:27:49 → philopsos1 joins (~caecilius@user/philopsos)
04:31:42 × sam113101 quits (~sam@24.157.253.231) (Remote host closed the connection)
04:34:27 → sam113101 joins (~sam@24.157.253.231)
04:42:57 → michalz joins (~michalz@185.246.207.221)
04:45:10 × euleritian quits (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de) (Read error: Connection reset by peer)
04:45:27 → euleritian joins (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
04:50:50 → xdminsy joins (~xdminsy@117.147.70.231)
04:51:56 × L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
04:58:17 → wlhn joins (~wenzel@dl46fx8hbfttwvhb-h1ly-3.rev.dnainternet.fi)
05:00:32 → darmario joins (~MrFox___@user/darmario)
05:07:49 → rosco joins (~rosco@175.136.155.137)
05:09:58 → takuan joins (~takuan@178-116-218-225.access.telenet.be)
05:12:45 × riatre quits (~quassel@2001:310:6000:f::5198:1) (Quit: http://quassel-irc.org)
05:13:04 × darmario quits (~MrFox___@user/darmario) (Quit: Leaving)
05:21:18 × simendsjo quits (~user@84.209.170.3) (Ping timeout: 255 seconds)
05:34:32 × michalz quits (~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in)
05:37:17 → michalz joins (~michalz@185.246.207.218)
05:44:37 → acidjnk_new3 joins (~acidjnk@p200300d6e714dc085da20c6dea9e24be.dip0.t-ipconnect.de)
05:45:16 × euleritian quits (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
05:46:05 → euleritian joins (~euleritia@77.22.252.56)
05:51:08 × philopsos1 quits (~caecilius@user/philopsos) (Ping timeout: 268 seconds)
06:16:31 → madhavanmiui joins (~madhavanm@2409:40f4:ae:dd09:8000::)
06:18:03 × madhavanmiui quits (~madhavanm@2409:40f4:ae:dd09:8000::) (Client Quit)
06:18:53 → iqubic joins (~sophia@2601:602:9502:c70:6afe:7af5:5891:b32f)
06:22:02 → riatre joins (~quassel@2001:310:6000:f::5198:1)
06:27:16 × joeyadams quits (~joeyadams@2603:6010:5100:2ed:be5c:bfac:9926:c006) (Quit: Leaving)
06:32:03 × rvalue quits (~rvalue@user/rvalue) (Ping timeout: 264 seconds)
06:32:03 → andrei_n joins (~andrei_n@user/andrei-n:62396)
06:33:52 → sord937 joins (~sord937@gateway/tor-sasl/sord937)
06:36:27 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
06:38:33 × Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer)
06:40:13 → rvalue joins (~rvalue@user/rvalue)
06:40:29 → lortabac joins (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
06:43:13 × euleritian quits (~euleritia@77.22.252.56) (Ping timeout: 256 seconds)
06:45:38 → euleritian joins (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de)
06:46:02 × euleritian quits (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de) (Read error: Connection reset by peer)
06:46:04 → madhavanmiui joins (~madhavanm@2409:40f4:ae:dd09:8000::)
06:47:46 → euleritian joins (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de)
06:49:47 × euleritian quits (~euleritia@dynamic-176-007-156-210.176.7.pool.telefonica.de) (Read error: Connection reset by peer)
06:50:05 → euleritian joins (~euleritia@77.22.252.56)
06:52:11 × ft quits (~ft@p3e9bcb39.dip0.t-ipconnect.de) (Quit: leaving)
06:54:26 × euleritian quits (~euleritia@77.22.252.56) (Ping timeout: 252 seconds)
06:55:05 → euleritian joins (~euleritia@77.22.252.56)
07:08:31 × jle` quits (~jle`@2603:8001:3b02:84d4:309b:a5ab:1320:adb2) (Ping timeout: 268 seconds)
07:09:54 × kyborg2011 quits (~kyborg201@host-176-36-215-61.b024.la.net.ua) (Ping timeout: 256 seconds)
07:09:55 → jle` joins (~jle`@2603:8001:3b02:84d4:89e:9b05:41f1:3af8)
07:13:43 → kyborg2011 joins (~kyborg201@host-176-36-215-61.b024.la.net.ua)
07:15:18 × madhavanmiui quits (~madhavanm@2409:40f4:ae:dd09:8000::) (Quit: Quit)
07:30:02 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
07:38:40 → danse-nr3 joins (~danse-nr3@151.57.10.250)
07:44:00 → manwithluck joins (manwithluc@gateway/vpn/protonvpn/manwithluck)
07:48:00 × dcoutts__ quits (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 255 seconds)
07:52:11 → Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542)
07:55:59 <tomsmeding> a tag to check that this is not only a valid type, but is actually a _most general_ type for the definition?
07:56:01 <tomsmeding> interesting
07:58:47 → machinedgod joins (~machinedg@d173-183-246-216.abhsia.telus.net)
08:02:28 → cfricke joins (~cfricke@user/cfricke)
08:04:43 × rosco quits (~rosco@175.136.155.137) (Quit: Lost terminal)
08:12:33 × lortabac quits (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2)
08:16:21 → lxsameer joins (~lxsameer@Serene/lxsameer)
08:17:21 <dminuoso> That seems a bit weird. Isn't the goal of Damas Milner type inference to already give you "the most general type"?
08:17:59 × Miroboru quits (~myrvoll@178-164-114.82.3p.ntebredband.no) (Ping timeout: 264 seconds)
08:18:16 → rosco joins (~rosco@175.136.155.137)
08:18:31 <dminuoso> How would the type checker know of "a more general type" to begin with?
08:19:00 × andrei_n quits (~andrei_n@user/andrei-n:62396) (Quit: Leaving)
08:19:28 <dminuoso> I mean "should be inferred as having type [α-equivalent to] τ" can be stated by `x :: τ`
08:20:24 → ChrisTrac joins (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net)
08:21:15 <dminuoso> Ohh I think as I was writing about it, I understood.
08:22:21 <dminuoso> So a kind of `x :: τ; x :: _` as if it were?
08:22:28 <ncf> they want an synthesized-then-checked type ascription, presumably
08:22:53 → __monty__ joins (~toonn@user/toonn)
08:24:01 → Luj joins (~Luj@2a01:e0a:de4:a0e1:be24:11ff:febc:b5b5)
08:24:50 → Miroboru joins (~myrvoll@178-164-114.82.3p.ntebredband.no)
08:24:56 <ncf> Γ ⊢ x => τ Γ ⊢ x <= τ
08:24:57 <ncf> ----------------- as opposed to -----------------
08:24:58 <ncf> Γ ⊢ (x :: τ) => τ Γ ⊢ (x :: τ) => τ
08:26:48 <ChrisTrac> hi, I'm playing with GHC.Exts.withDict and am wondering if there's a way to instantiate a class with multiple methods? I'm using QuickCheck, and want to define `Gen a` values rather than instantiating `Arbitrary`; but lots of existing generators have `Arbitrary a` constraints that I can't satisfy.
08:29:09 <ChrisTrac> (the usual alternative is to define a load of newtypes, but I've got LOTS of nested datatypes that makes that a pain; but they're Generic so I can auto-generate a lot of Gen values easily)
08:30:28 <tomsmeding> dminuoso: they want that `x ::[inferred] Int ; x = 42` would fail because that's less general than `x :: Num a => a`
08:31:06 <tomsmeding> ChrisTrac: have you considered using hedgehog instead? :)
08:31:28 <tomsmeding> it's designed around providing explicit generators, instead of relying on an Arbitrary type class
08:32:17 <ChrisTrac> heh, I'm actually more of a fan of falsify; this project already uses QuickCheck in parts, so I'm after a path of least-resistance
08:32:44 <tomsmeding> generating type class evidence out of thin air is always a dangerous endeavour
08:33:17 <ChrisTrac> yeah, unsafeCoerce can do it; but that's worse than just writing a mountain of instances IMHO
08:33:23 <tomsmeding> I don't think there's a supported way apart from withDict
08:33:33 <tomsmeding> (which only works for single-method classes)
08:33:55 <tomsmeding> (and even withDict is not meant to be used lightly)
08:34:53 <ChrisTrac> I tried making my own single-method `class Arb a where arb :: Gen a`, which works fine for withDict; but I can't use that to satisfy an existing Arbitrary constraint :(
08:36:45 × euleritian quits (~euleritia@77.22.252.56) (Read error: Connection reset by peer)
08:37:08 → euleritian joins (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
08:39:31 × euleritian quits (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
08:40:01 <Leary> ChrisTrac: You can if you get nasty. If you write `newtype FromArb a = FromArb a; instance Arb a => Arbitrary (FromArb a)`, then you can turn `Gen a ->` into `Arb a =>` with `withDict`, which gives you `Arbitrary (FromArb a)`, which you can capture with `data Dict c = c => Dict`, and safely `unsafeCoerce` to `Dict (Arbitrary a)`.
08:40:21 → euleritian joins (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
08:40:59 <danse-nr3> hmm "safely unsafeCoerce"
08:41:44 <ChrisTrac> Leary: Yeah, it seems like there's inevitably an `unsafeCoerce` (whether directly, or indirectly via a library like `constraints`)
08:42:33 <Leary> In my opinion, `withDict` is actually more dangerous than `unsafeCoerce` where you know the representation matches.
08:44:09 <tomsmeding> and how do we all know that ghc will pick the Arbitrary constraint we're trying to pass, and not some other floating around?
08:44:11 <ChrisTrac> Leary: how so? I thought withDict just fails to find an instance (a compile error), whilst unsafeCoerce can cause segfaults, etc.
08:44:47 → dcoutts__ joins (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net)
08:45:27 <ChrisTrac> tomsmeding: in this case it's "morally coherent", in that I don't care which is picked (I just want one, any one)
08:46:54 <Leary> I'll re-emphasise: /where you know the representation matches/
08:47:43 <danse-nr3> `withDict` seems an advanced function indeed, was not familiar with it
08:47:57 <Leary> Using it to erase a newtype obviously cannot cause a segfault; it's more like reaching for internals that weren't exposed.
08:48:58 <tomsmeding> and "knowing that the representation matches" is not? :p
08:49:52 <tomsmeding> (I'm not saying that you can't do what you're suggesting -- I'm just saying that depending on knowledge about internal representation, for which you can't even explicitly tell the compiler that you're depending on it, is dangerous)
08:52:43 <Leary> `newtype`s are language-guaranteed to share the same representation as the type they wrap?
08:52:46 <ChrisTrac> I think coercing between representational types (e.g. newtype wrappers) is fine; coercing between GHC's current dictionary representations is where it gets hairy (i.e. where we're depending on the Core structure)
08:53:47 <danse-nr3> but then... whey would you coerce between newtype wrappers?
08:53:51 <danse-nr3> *why
08:54:13 → sawilagar joins (~sawilagar@user/sawilagar)
08:54:18 × tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
08:54:50 <ChrisTrac> danse-nr3: classic examples are Monoid instances for `Sum Int`, `Product Int`, `Min Int`, `Max Int`, etc. (where all those wrappers are newtypes)
08:56:42 <Leary> ChrisTrac: What I'm suggesting is only `unsafeCoerce :: Dict (Arbitrary (FromArb a)) -> Dict (Arbitrary a)`. This doesn't depend on anything the language doesn't guarantee; it's only a threat to coherence, same as `withDict`.
08:56:52 <danse-nr3> i get it can be handy, i guess i would prefer to find a way that plays well with the type system
08:57:54 <tomsmeding> Leary: hm, I guess -- as long as you know that all methods of Arbitrary use the type variable at most representationally
08:59:03 <tomsmeding> how do I get ghci to print roles for a newtype again?
08:59:04 <Leary> Right, that's a point worthy of note.
08:59:42 <ChrisTrac> danse-nr3: say you `getSum (mappend (map Sum myBigListOfInts))`, the `Sum` and `getSum` are no-ops, so zero-overhead; but we might end up running `map` over the list, wasting resources (depends on optimisations; even if lists get optimised away, more complicated structures might not). We can replace the `map Sum` with coerce to ensure it's
08:59:43 <ChrisTrac> definitely a no-op (and the type-checker will ensure it's safe)
09:00:00 AlexNoo_ is now known as AlexNoo
09:00:01 <tomsmeding> but that's _coerce_, not _unsafeCoerce_
09:00:14 <tomsmeding> with unsafeCoerce it's up to you to check that there is indeed representational equality
09:00:29 × Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
09:00:29 <tomsmeding> the language does not, really, guarantee anything about the representation of dictionaries in something like the Dict type
09:00:38 → chele joins (~chele@user/chele)
09:01:25 <tomsmeding> so with the Leary's unsafeCoerce trick we're still depending on the fact that whatever that runtime representation of type class evidence is, this representation is the same for representationally equal type parameters
09:01:33 <tomsmeding> Haskell2010 does not guarantee that
09:01:43 <tomsmeding> it's _true_ in GHC
09:03:27 <tomsmeding> and the fact that I can't think of a different, still sensible implementation notwithstanding :p
09:05:37 × ChrisTrac quits (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net) (Ping timeout: 250 seconds)
09:15:47 <danse-nr3> interesting. `coerce` does not even feel that coercing :)
09:15:58 danse-nr3 wonders whether a `cast` exists
09:16:01 <danse-nr3> @hoogle cast
09:16:02 <lambdabot> Data.Typeable cast :: forall a b . (Typeable a, Typeable b) => a -> Maybe b
09:16:02 <lambdabot> Protolude cast :: (Typeable a, Typeable b) => a -> Maybe b
09:16:02 <lambdabot> BasePrelude cast :: (Typeable a, Typeable b) => a -> Maybe b
09:16:19 <danse-nr3> @hoogle coerce
09:16:20 <lambdabot> Data.Coerce coerce :: forall (k :: RuntimeRep) (a :: TYPE k) (b :: TYPE k) . Coercible a b => a -> b
09:16:20 <lambdabot> GHC.Exts coerce :: forall (k :: RuntimeRep) (a :: TYPE k) (b :: TYPE k) . Coercible a b => a -> b
09:16:20 <lambdabot> Control.Lens.Internal.Coerce coerce :: Coercible a b => a -> b
09:19:32 <mauke> @hoogle reify
09:19:33 <lambdabot> Language.Haskell.TH reify :: Name -> Q Info
09:19:33 <lambdabot> Language.Haskell.TH.Syntax reify :: Name -> Q Info
09:19:33 <lambdabot> Hedgehog.Internal.State reify :: HTraversable t => Environment -> t Symbolic -> Either EnvironmentError (t Concrete)
09:19:37 → ChrisTrac joins (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net)
09:23:51 <tomsmeding> @hoogle reflect
09:23:52 <lambdabot> Pipes.Core reflect :: Functor m => Proxy a' a b' b m r -> Proxy b b' a a' m r
09:23:52 <lambdabot> Data.Reflection reflect :: Reifies s a => proxy s -> a
09:23:52 <lambdabot> Control.Monad.Logic.Class reflect :: MonadLogic m => Maybe (a, m a) -> m a
09:24:17 danse-nr3 raises eyebrow
09:24:31 <tomsmeding> ¯\_(ツ)_/¯
09:24:37 <danse-nr3> =D
09:27:45 → kuribas joins (~user@ptr-17d51emfywuvjswcfv8.18120a2.ip6.access.telenet.be)
09:28:39 × gawen quits (~gawen@user/gawen) (Quit: cya)
09:34:42 × ChrisTrac quits (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net) (Quit: Client closed)
09:36:20 → gawen joins (~gawen@user/gawen)
09:42:37 → mreh joins (~matthew@host86-160-168-12.range86-160.btcentralplus.com)
09:43:36 → ChrisTrac joins (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net)
09:43:38 <mreh> I'm rather inspired by servant and beam to create some kind of depently typed eDSL to generate (limited for now) OpenGL pipelines.
09:44:04 <mreh> The amount of boilerplate I have to write doing OpenGL currently.
09:45:06 → gehmehgeh joins (~user@user/gehmehgeh)
09:45:21 gehmehgeh is now known as gmg
09:46:24 × gmg quits (~user@user/gehmehgeh) (Client Quit)
09:49:18 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
09:52:03 × TonyStone quits (~TonyStone@user/TonyStone) (Ping timeout: 260 seconds)
09:57:25 → madhavanmiui joins (~madhavanm@2409:40f4:ae:dd09:8000::)
09:59:58 → dequbed joins (~dequbed@banana-new.kilobyte22.de)
10:01:09 × madhavanmiui quits (~madhavanm@2409:40f4:ae:dd09:8000::) (Client Quit)
10:03:32 × kyborg2011 quits (~kyborg201@host-176-36-215-61.b024.la.net.ua) (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:04:40 → TonyStone joins (~TonyStone@user/TonyStone)
10:05:20 <danse-nr3> does nothing like that already exist mreh?
10:05:33 → gehmehgeh joins (~user@user/gehmehgeh)
10:06:36 × xff0x quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds)
10:06:38 gehmehgeh is now known as gmg
10:06:41 × gawen quits (~gawen@user/gawen) (Quit: cya)
10:10:27 <mreh> danse-nr3: There are DSLs and eDSLs, but I don't think they can exclude many runtime errors, say for example I don't have a vertex buffer object bound with the right kind of data in it with the right attribute pointer for my vertex shader.
10:11:38 <danse-nr3> oh had overlooked the "dependently typed" part. Good luck then
10:12:12 <mreh> The eDSLs I've found are also not well documented. Lambdacube looks good, but I didn't fancy it since it's its own language with its own toolchain.
10:13:01 <danse-nr3> i assume good doc is also a matter of how much collaboration one can get on their project
10:13:15 × acidjnk_new3 quits (~acidjnk@p200300d6e714dc085da20c6dea9e24be.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
10:13:59 <mreh> danse-nr3: probably. They're also mostly all around 10 years old and dependent types and OpenGL have come along a lot since then.
10:14:23 → gawen joins (~gawen@user/gawen)
10:14:28 <danse-nr3> but we've got "fearless refactoring"
10:14:44 danse-nr3 is not trying to get mreh collaborating on an existing project at all
10:14:51 → ChrisTrac91 joins (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net)
10:15:00 <mreh> danse-nr3: go on :)
10:15:05 <danse-nr3> :P
10:15:28 <mreh> do you have something of your own in mind?
10:15:54 <danse-nr3> nope, i just saw a lot of projects start, get no traction and eventually be abandoned
10:16:45 <mreh> yeah, I know right. I'm going to be the primary user of it
10:17:04 <mreh> so there will be an enthusiastic development team behind it
10:17:59 × ChrisTrac quits (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net) (Ping timeout: 250 seconds)
10:18:33 <mreh> lack of traction in the case of the others is probably because of no doc and incompleteness
10:18:47 <danse-nr3> an enthusiastic team of 1 you mean? (:
10:18:55 <mreh> danse-nr3: damn right
10:19:07 <mreh> even lambdacube is hard to get into
10:19:51 <danse-nr3> enthusiastic & a bit lonely. Not uncommon in haskell land but also not necessarily the only way
10:21:12 <mreh> there seems to be a bit of a haskell boom going on right now
10:21:28 × ChrisTrac91 quits (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net) (Ping timeout: 250 seconds)
10:21:28 <danse-nr3> "a bit of a boom"?
10:22:22 <mreh> I see lots of mainstream influencers talking about it
10:28:12 × cfricke quits (~cfricke@user/cfricke) (Ping timeout: 255 seconds)
10:30:51 × noumenon quits (~noumenon@113.51-175-156.customer.lyse.net) (Quit: Leaving)
10:34:29 × danse-nr3 quits (~danse-nr3@151.57.10.250) (Ping timeout: 268 seconds)
10:35:06 × sprout quits (~quassel@2a02-a448-3a80-0-758a-35d7-4890-aab6.fixed6.kpn.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
10:35:29 → sprout joins (~quassel@2a02-a448-3a80-0-d1d9-fee0-140e-a81b.fixed6.kpn.net)
10:41:53 → cfricke joins (~cfricke@user/cfricke)
10:53:42 → ubert joins (~Thunderbi@2a02:8109:ab8a:5a00:b0fb:c3f5:4666:ad2f)
10:55:15 × piele_ quits (~piele@tbonesteak.creativeserver.net) (Remote host closed the connection)
10:56:28 → piele joins (~piele@tbonesteak.creativeserver.net)
11:04:44 → xff0x joins (~xff0x@ai068022.d.east.v6connect.net)
11:07:05 → mmohammadi9812 joins (~mohammad@85.185.34.203)
11:09:31 → danza joins (~francesco@151.43.26.19)
11:22:58 → ChrisTrac joins (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net)
11:24:56 → CiaoSen joins (~Jura@2a05:5800:2a6:de00:e6b9:7aff:fe80:3d03)
11:26:53 × danza quits (~francesco@151.43.26.19) (Ping timeout: 240 seconds)
11:28:34 × pavonia quits (~user@user/siracusa) (Quit: Bye!)
11:33:19 × gmg quits (~user@user/gehmehgeh) (Quit: Leaving)
11:34:21 × ChrisTrac quits (~ChrisTrac@cpc116330-smal16-2-0-cust397.19-1.cable.virginm.net) (Quit: Client closed)
11:40:28 × CiaoSen quits (~Jura@2a05:5800:2a6:de00:e6b9:7aff:fe80:3d03) (Ping timeout: 268 seconds)
11:45:33 → andrewboltachev joins (~andrey@178.141.121.180)
11:46:16 <andrewboltachev> Hi. Do I understand correctly that `mtl` is much more recommended to use than `trnasformers`?
11:46:44 → danse-nr3 joins (~danse-nr3@151.43.38.52)
11:47:47 <andrewboltachev> I have a challenge of adding one more monad to here (StateT): https://github.com/andrewboltachev/matcher/blob/master/src/Logicore/Matcher/Core.hs#L468 so will transition to MTL make such things easier?
11:54:58 × dcoutts__ quits (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 268 seconds)
11:57:33 <mreh> transformers is a dependency of mtl
11:58:08 <mreh> andrewboltachev: ^
11:59:53 × L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer)
12:00:32 <mreh> you have to use transformers if you need to write Haskell98, otherwise mtl has some nice features
12:01:12 <mreh> since mtl uses some Language extensions, it's GHC only I believe
12:01:55 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
12:04:34 → dcoutts__ joins (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net)
12:06:49 → acidjnk_new3 joins (~acidjnk@p200300d6e714dc085da20c6dea9e24be.dip0.t-ipconnect.de)
12:07:34 <mreh> simply put, mtl doesn't require you to litter your code with `lift` when using transformer stacks
12:10:12 <andrewboltachev> mreh: yes, this seems clear. I have things like that when I need to "ask" (so, not even lift): https://github.com/andrewboltachev/matcher/blob/master/src/Logicore/Matcher/Core.hs#L946
12:12:21 <mreh> yeah, so MatchStatusT could derive the class MonadReader if you were using mtl
12:12:37 <mreh> you could make MatchStatusT a type synonym and get that for free
12:13:10 <mreh> or use newtype deriving
12:14:09 <mreh> that would also apply to the other typeclasses, like Monad, Functor, Applicative...
12:15:20 <mreh> nothing to do with mtl in the latter case, but something I noticed about the code
12:16:19 → lortabac joins (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
12:21:17 × Buggys quits (Buggys@shelltalk.net) (Quit: IRCNow and Forever!)
12:26:35 → gmg joins (~user@user/gehmehgeh)
12:31:35 × Pixi quits (~Pixi@user/pixi) (Ping timeout: 252 seconds)
12:32:29 × mreh quits (~matthew@host86-160-168-12.range86-160.btcentralplus.com) (Quit: Lost terminal)
12:35:40 × mmohammadi9812 quits (~mohammad@85.185.34.203) (Ping timeout: 268 seconds)
12:37:13 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
12:38:49 → kyborg2011 joins (~kyborg201@host-176-36-215-61.b024.la.net.ua)
12:45:47 → mreh joins (~matthew@host86-160-168-12.range86-160.btcentralplus.com)
12:50:57 <andrewboltachev> mreh: I guess this one is also should be called MatchStatusM (by convention)?
12:51:09 <andrewboltachev> the type synonym
12:51:46 → Pixi joins (~Pixi@user/pixi)
12:52:27 <mreh> andrewboltachev: not sure I follow you
12:53:40 <andrewboltachev> you said above: you could make MatchStatusT a type synonym and get that for free
12:54:21 <andrewboltachev> I know that sonetimes that "top-level monads" are defined as type synonyms and also called like AppM, ResponderM etc
12:55:18 <andrewboltachev> I always thought that that "M" means sth special
12:55:34 <mreh> oh right yeah, it just means Monad usually!
12:57:05 <andrewboltachev> well I think I've got the idea of what mtl is now
12:57:49 <mreh> why not call it something like `Match`?
12:58:43 <andrewboltachev> might be
12:59:32 <edwardk> andrewboltachev: 'transformers' is the base upon which 'mtl' is built. if you dont want to use mtl, but want to use some other mechanism, like, say, the ill-advised monads-tf package or whatever, or some effect system that might just use the mtl to write out the code of a handler or two, then this lets you share the base transformers, while retaining the option of dispatching classes in a different way.
13:00:23 <edwardk> the main scenario where this split is useful is that you might import only transformers if you want to provide instances for your own class for its data types, rather than import all of mtl.
13:00:31 <edwardk> but this is pretty much a tiny wibble
13:01:20 <andrewboltachev> so the idea is that I shouldn't implement MatchStatusT's MonadTrans instance?
13:01:36 <edwardk> no. you should implement all the things
13:02:41 <edwardk> let's look at that type for a sec.
13:02:45 <edwardk> newtype MatchStatusT m a = MatchStatusT { runMatchStatusT :: ReaderT MatcherEnv m (MatchStatus a) }
13:03:10 <edwardk> ok, so you have a readerT, and some match status thing. i've literally never read this code before so give me a sec.
13:03:42 <edwardk> data MatchStatus a = MatchSuccess a| MatchFailure T.Text| NoMatch T.Text deriving (Eq, Show)
13:04:28 <edwardk> ok, so that is purely an error type. so this is basicaly ReaderT MatcherEnv (EitherT MatchFailure m) a
13:04:38 <edwardk> for some notion of match failure that covers the two cases in matchstatus
13:05:07 <andrewboltachev> so, yes. it's like Either but with extra state
13:05:33 <mreh> did you intend MatchStatus to be at the bottom of the stack?
13:05:36 <edwardk> now you have a couple of options. if you want the _user_ to be reaching into that MatcherEnv using ask/asks you can implement MonadReader for MatchStatusT. if you want the _user_ to be responding to failures and extracting that information you can implement MonadError
13:06:29 <edwardk> and mreh has a good point. MatchStatus = MatchStatusT Identity is what one would expect, but you used it for the MatchResult type more or less
13:07:45 <edwardk> if the stuff in the MatcherEnv is for 'you' and you expect it to be tricky for users to maintain its invariants it may make sense not to implement the MonadReader instance for it. because then you can implement MonadReader e (MatchStatusT m) for whatever m offers!
13:07:49 <andrewboltachev> mreh: I'm not even sure
13:08:19 <edwardk> the user can then ask/asks/local that rather than get tripped up by the fact that you have some administrative environmental stuff out in MatchStatusT
13:08:50 <mreh> also should MatchStatusT even be a transformer? another question I would ask myself
13:09:03 <mreh> you might already know the answer
13:09:11 <edwardk> do you want users 'matching with monadic side-effects?'
13:09:12 <mreh> (just asking :)
13:09:28 <edwardk> e.g. running IO-actions that might launch missiles while you haven't even resolved the match
13:09:51 <edwardk> what is the semantics you want to assign to matching, basically
13:09:51 <andrewboltachev> print :-)
13:10:03 <mreh> "my JSON doesn't match, time to turn on the coffee machine"
13:10:10 <andrewboltachev> so btw
13:10:17 <edwardk> you can include that in the mix, just be warned you're loading a footgun
13:11:10 <andrewboltachev> https://www.dropbox.com/scl/fi/iyutvisq8v6arlj5ppuf8/2024-06-20-16-10-33.png?rlkey=ej84tfvumvfoh3w8ao2pgqm0j&st=0i7l889q&dl=0
13:11:47 <andrewboltachev> this is a "python code schema" that I made encoded as python code to match python code and extract patterns from it
13:12:33 <edwardk> looks like you're building up a 'bigger and bigger' stuck term for all the elimination forms being applied to some initial stuck object, like one does in a normalization by evaluation interpreter
13:13:15 <andrewboltachev> I also dealt with Figma files for example (yet the type is clear so there's not so much to match) but just as an example of big data structure (100s of MB) - I read/write some preliminary results into Redis for example
13:13:28 <edwardk> want to see what a lambda does? pass this sort of thing in as an argument and see what the lambda does to the argument.
13:13:58 <andrewboltachev> uhm
13:15:05 <edwardk> andrewboltachev: https://davidchristiansen.dk/tutorials/implementing-types-hs.pdf is a walkthrough of building something kind of similar for a simple lambda calculus implemented in haskell
13:16:34 <andrewboltachev> interesting. I still thought that I'm building more like a... lens
13:17:19 <mreh> you're talking to the right man
13:18:39 <edwardk> if what you wrote is what i think you wrote, its like a big sticky ball of tar that any attempt to invoke it as a function gets turned into a bigger ball of tar that represents 'hey this is the result of calling that previous thing with this argument' or invoking && on it captures 'hey this is the result of calling && with some other argument on that base thing'. so if it gets returned as part of the result of a function it 'traces' what
13:18:39 <edwardk> was done relative to the input to the function.
13:19:14 <edwardk> chuck the ball of tar in, see what comes out stuck to it
13:19:28 <edwardk> this is the essence of NBE ;)
13:20:03 <edwardk> mreh: hah
13:20:14 <andrewboltachev> aha. but the trick is, there's always some more theory
13:20:59 <andrewboltachev> I'm in my spare time going through "Elementary categories elementary toposes" book and it doesn't seem to end very soon. 287 pages but ~500 theorems or so
13:21:48 <edwardk> andrewboltachev: that's the good part. without more theory you are stuck inventing it all from scratch and you can miss good stuff! ;)
13:22:25 <andrewboltachev> well, thanks :-) I'll keep that
13:23:31 <andrewboltachev> pretty much the biggest theoretical discovery I made is that: (MatchStringExact "abc") (i.e. the "type" that only has one object) is a final object
13:24:13 <edwardk> what are your morphisms?
13:24:43 <andrewboltachev> well that's just like in Set
13:25:03 <edwardk> so these are functions that take sets of strings to sets of strings?
13:25:57 <andrewboltachev> Say, all the types of JSON (Aeson)
13:26:14 → Pixi` joins (~Pixi@user/pixi)
13:26:15 <andrewboltachev> (MatchStringExact "abc") is a set of one string
13:27:04 <edwardk> or do you have something like a 'is more specific than' thing where a -> b shows json objet that would parse into 'a' should parse in 'b', which behaves kind of like set^op.
13:27:46 <edwardk> the ltter is more like a powerset, which pushes you contravariant, and then breaks your current intution
13:27:46 <andrewboltachev> this function that I have: https://github.com/andrewboltachev/matcher/blob/master/src/Logicore/Matcher/Core.hs#L1766 given a grammar (MatchPattern) is meant to eliminate the "static" part of that grammar...
13:28:08 <andrewboltachev> static part of data*
13:28:23 × Pixi` quits (~Pixi@user/pixi) (Read error: Connection reset by peer)
13:28:48 → Pixi` joins (~Pixi@user/pixi)
13:29:03 × Pixi quits (~Pixi@user/pixi) (Ping timeout: 260 seconds)
13:29:25 <andrewboltachev> https://dpaste.com/DWWJLDHCC#wrap
13:29:42 <andrewboltachev> that "w" aka whitespace is eliminated
13:30:31 → Pixi__ joins (~Pixi@user/pixi)
13:32:30 <andrewboltachev> ah, sorry, this is the correct example: https://dpaste.com/4FPGJMZ7J#wrap
13:34:17 × Pixi` quits (~Pixi@user/pixi) (Ping timeout: 252 seconds)
13:34:29 <andrewboltachev> idea is that "b" is already "terminal object", so we can throw it away, and deal with "a" (provide another value for it) and then re-create the whole structure. the whitespace-like stuff is another beast I'm trying to support
13:35:46 <andrewboltachev> so product of terminal objects is itself a terminal object ('cause when you multiply by 1 you got the same number)
13:36:37 <andrewboltachev> and that's exactly what I have to eliminate (to write this function called `matchResultToThinValueFAlgebra` correctly)
13:37:30 <andrewboltachev> thanks for help and support mreh edwardk :-)
13:39:42 × caubert_ quits (~caubert@user/caubert) (Read error: Connection reset by peer)
13:40:02 → caubert joins (~caubert@user/caubert)
13:49:33 → ocra8 joins (~ocra8@user/ocra8)
14:00:13 → ystael joins (~ystael@user/ystael)
14:07:43 <mreh> andrewboltachev: np
14:14:25 × euleritian quits (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
14:18:13 × andrewboltachev quits (~andrey@178.141.121.180) (Quit: Leaving.)
14:19:26 → euleritian joins (~euleritia@dynamic-176-007-169-090.176.7.pool.telefonica.de)
14:22:03 → Sgeo joins (~Sgeo@user/sgeo)
14:35:15 × machinedgod quits (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 255 seconds)
14:41:44 → enoq joins (~enoq@2a05:1141:1e6:3b00:c958:a45e:c4e0:3650)
14:42:30 <enoq> hi, so I was watching a Kotlin talk recently where they've mentioned that sum types have undecidability problems; is this inherent to sum types or just related to how OO languages design their type hyrarchies?
14:45:18 × euleritian quits (~euleritia@dynamic-176-007-169-090.176.7.pool.telefonica.de) (Read error: Connection reset by peer)
14:45:32 → mmohammadi9812 joins (~mohammad@85.185.34.203)
14:45:34 → euleritian joins (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
14:47:16 → soverysour joins (~soverysou@188.27.2.34)
14:47:16 × soverysour quits (~soverysou@188.27.2.34) (Changing host)
14:47:16 → soverysour joins (~soverysou@user/soverysour)
14:49:54 <danse-nr3> sounds to me something related more to object-oriented hierarchies, but it's difficult to tell without more detail
14:51:37 <dolio> Undecidability of what?
14:51:52 <tomsmeding> haskell has no problems with sum types, but then haskell is not an OO language
14:56:43 <sprout> most interesting type systems are undecidable
14:56:50 sprout looks at system f
14:57:12 → yin joins (~yin@user/zero)
15:06:35 → tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net)
15:08:49 × lortabac quits (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2)
15:08:54 × L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
15:09:56 × Pixi__ quits (~Pixi@user/pixi) (Quit: Leaving)
15:13:53 × chiselfuse quits (~chiselfus@user/chiselfuse) (Remote host closed the connection)
15:14:48 → chiselfuse joins (~chiselfus@user/chiselfuse)
15:16:26 <drdo> enoq: decidability of what exactly?
15:17:23 <enoq> I think they've mentioned something about polynomial runtime
15:19:33 <EvanR> kotlin conf 2024 brochure says this apparently to elaborate on what "kotlin's type system is undecdiable" means: we can reliably cause the type-checker to stack overflow
15:20:01 <EvanR> and it is unsound because "we can trick it into thinking a String is an Int"
15:20:15 <dolio> That's a bit non-standard.
15:21:01 EvanR loads up some isomorphic javascript and escapes through it
15:22:19 → Pixi joins (~Pixi@user/pixi)
15:24:28 × cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2)
15:25:10 × danse-nr3 quits (~danse-nr3@151.43.38.52) (Read error: Connection reset by peer)
15:25:23 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
15:25:24 <EvanR> if something can be decided in polynomial time, that's highly non-undecidable
15:26:23 → danse-nr3 joins (~danse-nr3@151.43.0.225)
15:26:37 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
15:27:51 <drdo> EvanR: did you throw that double negative in to confuse the intuitionists?
15:29:19 <dolio> Intuitionists are the ones who aren't confused about double negatives. :)
15:33:29 <EvanR> let the rhetorical purpose there be a free construction of the mind
15:37:57 <dminuoso> Regarding type safety, if we take the TaPL definition, then "safety = progress + preservation", and confusing a String for an Int probably is a preservation violation
15:39:11 <danse-nr3> resorting to the definition probably unnecessary in order to consider that unsafe
15:39:25 <danse-nr3> well to /a/ definition
15:40:26 <dminuoso> Well, I think to state "x is unsafe" requires some definition of what we mean by "unsafe" really.
15:40:55 <danse-nr3> then i'll say "x is frown upon". Even works better these days
15:41:10 <danse-nr3> *frowned
15:42:47 <EvanR> they say it's unsound, which sounds like a logic thing not a programming thing
15:43:12 <EvanR> like unsafe
15:43:58 <dminuoso> EvanR: Again according to TaPL at least, soundness is in some circles a synonym for safety
15:44:05 <EvanR> but I can imagine using suitable logic you can use the assumption that String = Int to prove 0 = 1 or False
15:45:38 → igghibu joins (~igghibu@193.19.202.131)
15:46:23 × igghibu quits (~igghibu@193.19.202.131) (Remote host closed the connection)
15:46:52 <dolio> Type soundness is a programming thing.
15:48:51 <dolio> In GHC, getting a String where you're expecting Ints might causes a segfault or something. In Kotlin it probably only causes some kind of runtime exception, but it's probably harder to debug than most errors.
15:49:24 <dolio> It might not even be obvious where the problem is.
15:50:09 <dolio> Segfault is if you're lucky in GHC, I guess. It might just do something wrong and leave you wondering why.
15:55:59 <dminuoso> Bugs like Pentium FDIV make you wonder how many subtle errors are left in silicon, microcode, kernel code, or compilers that have not been detected but keep influencing your programs, perhaps especially in case of FDIV in ways that are hard to even notice.
15:57:03 × rosco quits (~rosco@175.136.155.137) (Quit: Lost terminal)
15:57:17 × soverysour quits (~soverysou@user/soverysour) (Ping timeout: 240 seconds)
16:00:03 → Buggys joins (Buggys@shelltalk.net)
16:01:12 <johnw_> what if FDIV results in Zombies being harder to kill in Left for Dead, so we simply evolved to become better zombie killers...
16:08:29 × lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds)
16:09:17 → soverysour joins (~soverysou@user/soverysour)
16:10:39 → lxsameer joins (lxsameer@Serene/lxsameer)
16:15:57 → Tuplanolla joins (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi)
16:16:40 → andrei_n joins (~andrei_n@user/andrei-n:62396)
16:17:51 × kyborg2011 quits (~kyborg201@host-176-36-215-61.b024.la.net.ua) (Ping timeout: 255 seconds)
16:18:48 × Buggys quits (Buggys@shelltalk.net) (Quit: IRCNow and Forever!)
16:19:15 × FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
16:20:08 → kyborg2011 joins (~kyborg201@host-176-36-215-61.b024.la.net.ua)
16:21:00 → FinnElija joins (~finn_elij@user/finn-elija/x-0085643)
16:24:07 × lxsameer quits (lxsameer@Serene/lxsameer) (Ping timeout: 246 seconds)
16:24:41 → igghibu joins (~igghibu@193.19.202.131)
16:25:48 × danse-nr3 quits (~danse-nr3@151.43.0.225) (Ping timeout: 256 seconds)
16:25:57 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
16:26:08 × chele quits (~chele@user/chele) (Remote host closed the connection)
16:26:09 → lxsameer joins (~lxsameer@Serene/lxsameer)
16:26:11 → CiaoSen joins (~Jura@2a05:5800:2a6:de00:e6b9:7aff:fe80:3d03)
16:29:03 × igghibu quits (~igghibu@193.19.202.131) (Remote host closed the connection)
16:30:02 × FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
16:30:22 → FinnElija joins (~finn_elij@user/finn-elija/x-0085643)
16:30:51 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
16:30:54 → econo_ joins (uid147250@id-147250.tinside.irccloud.com)
16:35:22 → danse-nr3 joins (~danse-nr3@151.43.0.225)
16:39:31 × dcoutts__ quits (~duncan@oxfd-27-b2-v4wan-164228-cust163.vm42.cable.virginm.net) (Ping timeout: 246 seconds)
16:40:51 × CiaoSen quits (~Jura@2a05:5800:2a6:de00:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds)
16:41:17 → madhavanmiui joins (~madhavanm@2409:40f4:28:9c68:8000::)
16:41:24 → igghibu joins (~igghibu@146.70.225.113)
16:42:15 × mmohammadi9812 quits (~mohammad@85.185.34.203) (Ping timeout: 260 seconds)
16:43:15 × yin quits (~yin@user/zero) (Ping timeout: 268 seconds)
16:43:23 × igghibu quits (~igghibu@146.70.225.113) (Remote host closed the connection)
16:43:40 → igghibu joins (~igghibu@146.70.225.113)
16:43:44 × madhavanmiui quits (~madhavanm@2409:40f4:28:9c68:8000::) (Client Quit)
16:47:30 × ubert quits (~Thunderbi@2a02:8109:ab8a:5a00:b0fb:c3f5:4666:ad2f) (Remote host closed the connection)
16:47:40 → bontaq joins (~user@ool-45779c03.dyn.optonline.net)
16:55:51 → yin joins (~yin@user/zero)
17:02:56 → ft joins (~ft@p3e9bcb39.dip0.t-ipconnect.de)
17:03:52 × igghibu quits (~igghibu@146.70.225.113) (Remote host closed the connection)
17:08:50 → wootehfoot joins (~wootehfoo@user/wootehfoot)
17:10:19 × soverysour quits (~soverysou@user/soverysour) (Ping timeout: 246 seconds)
17:13:24 → Square joins (~Square@user/square)
17:14:05 × yin quits (~yin@user/zero) (Remote host closed the connection)
17:15:29 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
17:15:44 × enoq quits (~enoq@2a05:1141:1e6:3b00:c958:a45e:c4e0:3650) (Quit: Leaving)
17:29:30 × euleritian quits (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
17:31:57 → euleritian joins (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
17:32:37 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
17:43:36 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
17:46:12 ← L29Ah parts (~L29Ah@wikipedia/L29Ah) ()
17:47:27 → simendsjo joins (~user@84.209.170.3)
17:49:37 → philopsos1 joins (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net)
17:52:32 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
17:52:33 × danse-nr3 quits (~danse-nr3@151.43.0.225) (Quit: Leaving)
17:53:14 × philopsos1 quits (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net) (Client Quit)
17:58:09 → philopsos1 joins (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net)
18:01:02 × philopsos1 quits (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net) (Client Quit)
18:01:29 → philopsos1 joins (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net)
18:02:10 × philopsos1 quits (~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net) (Changing host)
18:02:10 → philopsos1 joins (~caecilius@user/philopsos)
18:02:49 × philopsos1 quits (~caecilius@user/philopsos) (Client Quit)
18:03:25 → philopsos1 joins (~caecilius@user/philopsos)
18:08:29 → Lord_of_Life_ joins (~Lord@user/lord-of-life/x-2819915)
18:10:09 × Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds)
18:11:26 Lord_of_Life_ is now known as Lord_of_Life
18:13:57 × mreh quits (~matthew@host86-160-168-12.range86-160.btcentralplus.com) (Quit: Lost terminal)
18:14:32 × philopsos quits (~caecilius@user/philopsos) (Quit: Lost terminal)
18:15:10 → soverysour joins (~soverysou@188.27.2.34)
18:15:10 × soverysour quits (~soverysou@188.27.2.34) (Changing host)
18:15:10 → soverysour joins (~soverysou@user/soverysour)
18:17:40 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
18:19:00 → mmohammadi9812 joins (~mohammad@85.185.34.203)
18:19:48 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
18:21:23 × philopsos1 quits (~caecilius@user/philopsos) (Ping timeout: 252 seconds)
18:23:46 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
18:31:19 × ocra8 quits (~ocra8@user/ocra8) (Quit: WeeChat 4.3.2)
18:40:25 × jrm quits (~jrm@user/jrm) (Ping timeout: 268 seconds)
18:42:12 → target_i joins (~target_i@user/target-i/x-6023099)
18:42:29 → waleee joins (~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
18:43:30 → jrm joins (~jrm@user/jrm)
18:44:27 × wlhn quits (~wenzel@dl46fx8hbfttwvhb-h1ly-3.rev.dnainternet.fi) (Quit: Leaving)
18:48:36 × soverysour quits (~soverysou@user/soverysour) (Ping timeout: 255 seconds)
19:06:35 × lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 264 seconds)
19:08:34 → lxsameer joins (lxsameer@Serene/lxsameer)
19:17:01 × lxsameer quits (lxsameer@Serene/lxsameer) (Ping timeout: 256 seconds)
19:18:59 → lxsameer joins (~lxsameer@Serene/lxsameer)
19:19:16 × waleee quits (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 268 seconds)
19:20:24 <hadronized> I have a silly question; is there a range (expected range?) of the time a typicall GC collection can take?
19:20:30 <hadronized> is there a upper boundary?
19:21:00 <hadronized> like, if there are tons of free objects, is the GC interruptable to prevent having stopping the world for too long? and if not, is there a way to know the average-worst performance?
19:21:08 <hadronized> is it within 1ms? 10ms? 100ms?
19:22:53 <EvanR> there is --copying-gc and --nonmoving-gc which will get different latency characteristics
19:23:31 → machinedgod joins (~machinedg@d173-183-246-216.abhsia.telus.net)
19:23:41 <EvanR> the default copying gc will worst case take time proportional to how many live objects there are
19:24:20 <EvanR> use profiling to see how much the time actually is
19:27:42 <tomsmeding> also consider using the `+RTS -S` rts flag; it prints statistics about GC runtime when the process exits
19:27:47 <hadronized> I just wanted to have a rough idea of what to expect
19:28:14 <EvanR> write a program and tell us how it goes xD
19:28:15 <tomsmeding> hadronized: it depends completely on the size of your heap
19:28:30 <tomsmeding> if you never have more than 100 KB of data alive at a time, GC will be trivial
19:28:51 <tomsmeding> if you have 30 GB of live data, GC will be very expensive, see if you can use compact regions or similar to alleviate trouble
19:29:12 <hadronized> yeah
19:29:26 <tomsmeding> (that is, live data that the GC has to traverse; a huge ByteString doesn't count because the GC sees "ok, here's a ByteString" and moves on)
19:29:27 <hadronized> I’m trying to think whether it would be usable to make some graphics code to make a video game etc.
19:29:35 <hadronized> since I really want to go back to what I used to do ~years ago (luminance)o
19:29:36 <hadronized> -o
19:30:35 <tomsmeding> the nonmoving GC would be better for that because it tries to keep GC latency low, at the expense of throughput (i.e. total amount of time spent in GC is higher, but most of it happens in parallel with your code)
19:30:48 <EvanR> video games are possible, check out #haskell-game xD
19:31:00 <hadronized> is lambdacube still a thing?
19:31:03 <EvanR> intense CPU based graphics code, might be possible for very low rez framebuffer
19:31:23 <tomsmeding> if you want to make a game with large amounts of data in-memory and a consistent, high frame rate, perhaps haskell is not the optimal language to make that in
19:32:21 <tomsmeding> GC can easily take 10ms if you have GBs of data
19:32:34 → andrewboltachev joins (~andrey@178.141.121.180)
19:32:39 <tomsmeding> probably more
19:32:41 <EvanR> there are ECS engines... I heard good things about Apecs
19:32:51 <EvanR> probably overkill for your first attempt at a haskell game
19:33:25 <EvanR> GB of truly dynamic data seems a bit nuts, usually games have huge amounts of static stuff loaded once
19:33:34 <EvanR> triple A games
19:33:43 <hadronized> yeah that sounds like a lot of data
19:34:15 <hadronized> but if you have memory that sticks around (not garbage), even with tons of it, the GC shouldn’t have too much problem with that, right?
19:34:17 <EvanR> I think performance isn't going to be first hurdle to writing games
19:34:20 <EvanR> in haskell
19:36:33 <tomsmeding> hadronized: the GC is going to traverse all that data every time, except if 1. it's memory of which the GC knows that it doesn't contain pointers, such as a ByteString, or 2. it's in a compact region (https://hackage.haskell.org/package/compact)
19:37:04 <tomsmeding> if you use the (default) copying GC, (1.) has the further side condition that that memory must be pinned, otherwise it'll be copied anyway; a ByteString is pinned, but a Vector is not, for example
19:37:46 <talismanick> Can `data Tree a = Tip a | Bin (Tree a) (Tree a)` be reformulated to avoid proving typeclass laws by cases + induction? Something to do with recursion schemes?
19:38:38 <tomsmeding> which type classes?
19:38:58 <EvanR> hadronized, for each ton of non garbage, the major collection cycle requires 1 millisecond per ton of time xD
19:38:59 <talismanick> tomsmeding: Applicative thus far, but also Monad
19:39:29 <talismanick> I wrote `(Tip f) <*> t = f <$> t` and `(Bin l r) <*> t = Bin (l <*> t) (r <*> t)`
19:39:52 <tomsmeding> that's correct, I think
19:40:11 <talismanick> proving interchange was easy enough with induction, but composition is a doozy
19:40:12 <tomsmeding> general advice with this is: write pure (easy) and (>>=) (harder, but less chance of making mistakes), then define (<*>) = ap
19:40:47 <talismanick> bind was `Tip x >>= f = f x` and `Bin l r >>= f = Bin (l >>= f) (r >>= f)`
19:40:47 <tomsmeding> you'll find that there's really only one way to write (>>=) for your Tree
19:40:54 <tomsmeding> indeed
19:41:38 <tomsmeding> if you expand the definition of 'ap' and the calls to your (>>=) that it contains, you'll find out that it's equivalent to the (<*>) that you wrote
19:42:00 <talismanick> so just prove the monad laws and leave it at that?
19:42:27 <tomsmeding> there's no "standard" way to generate Monad instances for general tree-like data types (this is why there is no -XDeriveMonad), so it'll be hard to find some general construction that makes it come "for free"
19:42:39 <tomsmeding> but this particular data type is very standard; you might be able to find it in a library
19:42:41 <hadronized> it’s a bit discouraging :(
19:42:59 <EvanR> hadronized, are you imagining bad gc performance for some reason?
19:43:01 <EvanR> that's not healthy
19:43:03 <tomsmeding> talismanick: yes, I'd just prove the monad laws for your (>>=); they imply the applicative laws
19:43:07 <hadronized> EvanR: yeah
19:43:11 <EvanR> lol
19:43:16 <talismanick> tomsmeding: I don't mean a way to derive Monad (because that depends on Applicative, which depends on a choice of monoid)
19:43:23 <hadronized> I mean, a decent video game today has to run at the v-sync of your screen
19:43:25 <EvanR> that's like people can't write any C code because they thing malloc will be too slow
19:43:26 <talismanick> I mean a way to factor out recursion/induction when proving laws
19:43:29 <hadronized> my screen, for instance, runs at 165Hz
19:43:52 <hadronized> so a whole frame has to be rendered in less than 6ms
19:44:00 <hadronized> if a GC pause can take 10ms, that’s already done
19:44:02 <EvanR> I recommend using opengl somehow so you utilize the GPU for graphics
19:44:24 <EvanR> esp at 165 fps
19:44:28 <hadronized> EvanR: I wrote luminance in Haskell years ago, and luminance in Rust using OpenGL, WebGL, Vulkan, etc.
19:44:40 <hadronized> so yeah, I’m not saying the problem will be due to graphics technology
19:44:41 <tomsmeding> talismanick: I mean, you can factor your data type as `newtype Fix f = In (f (Fix f)); data TreeF a r = TipF a | BinF r r; type Tree a = Fix (TreeF a)`
19:44:44 <hadronized> but everything that revolve around it
19:44:52 <talismanick> although it would be nice to be able to write "given this monoid, derive the corresponding Applicative/Monad instances"
19:45:08 <tomsmeding> talismanick: what monoid do you mean? `join`?
19:45:27 <tomsmeding> there are sometimes less valid Monad instances than there are valid Applicative instances for a type
19:45:32 × m5zs7k quits (aquares@web10.mydevil.net) (Ping timeout: 252 seconds)
19:45:33 <tomsmeding> so bunching them together like that doesn't sound right
19:45:38 <tomsmeding> (to wit: [a])
19:45:57 <talismanick> yeah, zipping is applicative but not monadic
19:46:22 <talismanick> but I thought every monad instance depends on some underlying applicative, which itself depends on some underlying choice of monoid
19:46:24 <EvanR> hadronized, yeah a hypothetical unsubstantiated data point was 10ms for a major collection because you have gigabytes of live heap for some reason
19:46:42 <tomsmeding> talismanick: what monoid are you talking about there? (My category-fu is limited)
19:46:42 <EvanR> note that most collections aren't major collections
19:47:02 <EvanR> you can also time major collections yourself if there's a convenient place to do it, e.g. between levels
19:47:20 <tomsmeding> if that happens often enough
19:47:29 <talismanick> www.staff.city.ac.uk/~ross/papers/Applicative.pdf
19:47:46 → m5zs7k joins (aquares@web10.mydevil.net)
19:47:52 <ncf> starting to understand why Escardó says the Applicative => Monad thing was a pedagogical disaster...
19:47:54 <EvanR> sure you just wouldn't want to switch levels then wait until sometime into the next level for a major GC "pause" (if there is one)
19:47:59 <talismanick> see section 4, "Monoids are phantom Applicative functors"
19:48:56 <ncf> a monad does not "depend" on a choice of underlying applicative; every Monad induces two Applicative structures, and there is a law that says that if a type implements Monad then it also has to implement Applicative with the first of those induced structures
19:49:06 <tomsmeding> talismanick: doesn't that say that every Monoid induces an Applicative, not that every Applicative is based on a Monoid?
19:49:28 <ncf> that section is just explaining the Monoid m => Applicative (Const m) instance
19:49:41 × machinedgod quits (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 240 seconds)
19:49:57 <ncf> every monoid gives rise to an applicative this way (and to a monad via Writer), but that does not mean that every applicative (or monad) has an underlying Monoid
19:50:10 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
19:50:10 <ncf> (it does have an underlying monoid object in some monoidal category but that's another story)
19:50:16 <talismanick> isn't every applicative isomorphic to a monoidal functor?
19:50:19 <ncf> yes
19:50:27 <tomsmeding> that's a different monoid, though
19:50:32 <talismanick> ah, I see
19:50:33 <tomsmeding> that's `join`
19:50:38 <tomsmeding> :t join
19:50:39 <lambdabot> Monad m => m (m a) -> m a
19:50:48 <ncf> join has little to do with monoidal functors
19:50:52 <tomsmeding> oh oops
19:51:22 tomsmeding will refrain from saying further falsehoods about category theory :p
19:51:50 <EvanR> hadronized, you could also try existing commercial computer games that were written in haskell and see if run at 165 fps, if you're still skeptical
19:52:10 <hadronized> is there any?!
19:52:15 <EvanR> lol
19:53:03 <EvanR> hmm https://magiccookies2.haskell.games/
19:53:38 <talismanick> https://keera.co.uk/posts/2014/10/15/from-60-fps-to-500/
19:54:38 talismanick sees reference to gamedev in Haskell, greps chat log for references to FRP
19:56:16 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
20:00:13 → va10323 joins (~v324@2802:8010:a008:4700:4e6a:6189:b174:1928)
20:00:58 × _xor quits (~xor@ip-208-102-243-175.dynamic.fuse.net) (Quit: Ping timeout (120 seconds))
20:01:12 → _xor joins (~xor@ip-208-102-243-175.dynamic.fuse.net)
20:04:59 × va10323 quits (~v324@2802:8010:a008:4700:4e6a:6189:b174:1928) (Quit: Leaving)
20:13:49 <cheater> i wish codex was up to date
20:13:53 <cheater> cuz it's really good actually
20:21:23 → rlj joins (~rlj@194-218-34-180.customer.telia.com)
20:22:12 × rlj quits (~rlj@194-218-34-180.customer.telia.com) (Client Quit)
20:25:39 → Guest|39 joins (~Guest|39@160.178.51.69)
20:27:10 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
20:37:59 × tcard quits (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving)
20:39:24 → tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
20:40:25 → tcard joins (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
20:46:38 × sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
20:46:57 × ystael quits (~ystael@user/ystael) (Quit: Lost terminal)
20:50:23 × lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 264 seconds)
20:52:27 × simendsjo quits (~user@84.209.170.3) (Ping timeout: 264 seconds)
20:53:05 → philopsos1 joins (~caecilius@user/philopsos)
20:53:47 × __monty__ quits (~toonn@user/toonn) (Quit: leaving)
20:55:29 × Guest|39 quits (~Guest|39@160.178.51.69) (Ping timeout: 256 seconds)
20:58:33 → Guest|86 joins (~Guest|86@161.230.86.113)
20:59:36 → ystael joins (~ystael@user/ystael)
21:01:55 × Guest|86 quits (~Guest|86@161.230.86.113) (Client Quit)
21:02:33 → Guest|86 joins (~Guest|86@161.230.86.113)
21:02:39 × AlexZenon quits (~alzenon@178.34.162.224) (Ping timeout: 260 seconds)
21:03:41 × target_i quits (~target_i@user/target-i/x-6023099) (Quit: leaving)
21:05:53 → waleee joins (~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
21:07:39 × mmohammadi9812 quits (~mohammad@85.185.34.203) (Ping timeout: 255 seconds)
21:08:03 → AlexZenon joins (~alzenon@178.34.162.224)
21:10:54 → saus joins (~saus@pool-98-114-45-229.phlapa.fios.verizon.net)
21:12:23 × andrei_n quits (~andrei_n@user/andrei-n:62396) (Quit: Leaving)
21:13:23 × AlexZenon quits (~alzenon@178.34.162.224) (Ping timeout: 260 seconds)
21:14:04 × takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
21:17:48 → AlexZenon joins (~alzenon@178.34.162.224)
21:23:08 × philopsos1 quits (~caecilius@user/philopsos) (Quit: Lost terminal)
21:23:27 × michalz quits (~michalz@185.246.207.218) (Quit: ZNC 1.9.0 - https://znc.in)
21:24:05 → philopsos1 joins (~caecilius@user/philopsos)
21:24:13 → emmanuelux joins (~emmanuelu@user/emmanuelux)
21:24:27 × Guest|86 quits (~Guest|86@161.230.86.113) (Quit: Connection closed)
21:24:43 × philopsos1 quits (~caecilius@user/philopsos) (Client Quit)
21:26:06 → philopsos1 joins (~caecilius@user/philopsos)
21:28:00 × EvanR quits (~EvanR@user/evanr) (Quit: Leaving)
21:32:30 → EvanR joins (~EvanR@user/evanr)
21:34:54 × saus quits (~saus@pool-98-114-45-229.phlapa.fios.verizon.net) (Quit: Client closed)
21:46:42 ← L29Ah parts (~L29Ah@wikipedia/L29Ah) ()
21:55:58 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
22:00:10 → bgamari_ joins (~bgamari@64.223.157.161)
22:01:55 × bgamari quits (~bgamari@64.223.238.64) (Ping timeout: 256 seconds)
22:13:47 × acidjnk_new3 quits (~acidjnk@p200300d6e714dc085da20c6dea9e24be.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
22:14:08 <monochrom> It will be difficult (impossible?) to tell GHC "these are static data, don't bother traversing them during GC". But GHC GC is generational, it will eventually discover that the data has been live for too long so mark them as "very old generation" and then they are traversed infrequently.
22:15:14 <monochrom> Likewise for the opposite, data that comes and goes fleetingly, GHC keeps them cheap.
22:16:29 <geekosaur> compact regions, but you need to obey their rules or they won't work
22:16:30 × philopsos1 quits (~caecilius@user/philopsos) (Ping timeout: 255 seconds)
22:21:36 <EvanR> didn't know about "very old generational"
22:21:46 <geekosaur> but if your data is truly static, chuck it into a compact region and GC won't traverse anything pointing into it
22:22:45 <EvanR> oh very old generation is just the oldest generation
22:22:50 <geekosaur> you can specify a number of generations (default is 1 + nursery)
22:23:21 <geekosaur> if you add more, GC of successive generations gets rarer and rarer
22:26:46 <EvanR> I'm guessing that can lead to huge memory usage?
22:27:22 <geekosaur> not really, you're using the same amount of memory but there's a little more overhead in GC
22:27:54 <geekosaur> heap is allocated in blocks, it'll only be huge if you change the default heap block size
22:27:55 × sawilagar quits (~sawilagar@user/sawilagar) (Ping timeout: 272 seconds)
22:31:48 × phma quits (phma@2001:5b0:2172:eb58:a102:8e01:4f76:63c6) (Read error: Connection reset by peer)
22:32:33 → phma joins (~phma@host-67-44-208-58.hnremote.net)
22:49:14 → yin joins (~yin@user/zero)
22:56:51 → Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542)
22:59:58 × destituion quits (~destituio@2a02:2121:306:89fe:b849:537f:4eb9:4445) (Ping timeout: 246 seconds)
23:00:46 × Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
23:16:12 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
23:18:30 → pavonia joins (~user@user/siracusa)
23:39:49 × bontaq quits (~user@ool-45779c03.dyn.optonline.net) (Ping timeout: 256 seconds)
23:41:00 × gmg quits (~user@user/gehmehgeh) (Quit: Leaving)
23:41:04 × Square quits (~Square@user/square) (Quit: Leaving)

All times are in UTC on 2024-06-20.