2024/09/04

Newest at the top

2024-09-04 02:58:54 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 246 seconds)
2024-09-04 02:57:25 +0200motherfsck(~motherfsc@user/motherfsck) (Quit: quit)
2024-09-04 02:53:48 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-09-04 02:50:59 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-09-04 02:48:47 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2024-09-04 02:48:18 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 02:48:03 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2024-09-04 02:45:07 +0200 <Leary> (in Haskell the limits are just softer, bottoming out at runtime rather than failing to type check)
2024-09-04 02:42:32 +0200gmg(~user@user/gehmehgeh)
2024-09-04 02:42:28 +0200 <Leary> The infiniteness is in the semantics we ascribe, not in the program that actually runs. Of course that limits which operations we can support, but this is all the same whether in Haskell or System F.
2024-09-04 02:41:23 +0200 <Leary> Bowuigi: GFP_F := forall r. (forall x. (x -> F x) -> x -> r) -> r; ana_F := /\a. \coalg:a -> F a. \seed:a. /\r. \expair:forall x. (x -> F x) -> x -> r. expair a coalg seed; out_F := \ff:GFP_F. ff (F GFP_F) /\a. \coalg:a -> F a. \seed:a. map_F a GFP_F (ana_F a coalg) (coalg seed)
2024-09-04 02:40:44 +0200myxos(~myxos@syn-065-028-251-121.res.spectrum.com)
2024-09-04 02:37:25 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-09-04 02:35:14 +0200myxos(~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 255 seconds)
2024-09-04 02:32:30 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 02:32:06 +0200 <Inst> like, say, Foo pat; Bar pat = pat * 3
2024-09-04 02:31:48 +0200 <Inst> i'm sort of disappointed you can't condense multiple pattern matches into the same term, though
2024-09-04 02:31:27 +0200 <Inst> are the or patterns from GHC 9.12 actually useful?
2024-09-04 02:29:30 +0200 <haskellbridge> <Bowuigi> If the only valid operations are pretty much "zip" (over codata) and take (to data) variants it makes sense though
2024-09-04 02:28:40 +0200 <haskellbridge> <Bowuigi> Leary what about the "infinite-ness" of codata tho? You can't fold/traverse over infinite structures without taking infinite time on normal order (thus, breaking Church-Rosser and disproving totality)
2024-09-04 02:27:09 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-09-04 02:21:41 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-09-04 02:16:43 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 02:14:19 +0200Fooo(~Square@user/square) (Ping timeout: 252 seconds)
2024-09-04 02:10:53 +0200Square2(~Square4@user/square)
2024-09-04 02:10:49 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-09-04 02:08:05 +0200acidjnk_new(~acidjnk@p200300d6e72cfb5469ca77b0637d5192.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2024-09-04 02:05:42 +0200xff0x(~xff0x@2405:6580:b080:900:3618:2400:ae18:e1a3) (Ping timeout: 246 seconds)
2024-09-04 02:05:42 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-09-04 02:02:19 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-09-04 02:00:58 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 02:00:46 +0200jespada(~jespada@r190-64-133-178.su-static.adinet.com.uy) (Ping timeout: 252 seconds)
2024-09-04 01:58:11 +0200ystael(~ystael@user/ystael) (Ping timeout: 252 seconds)
2024-09-04 01:54:30 +0200misterfish(~misterfis@84.53.85.146) (Ping timeout: 246 seconds)
2024-09-04 01:51:47 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2024-09-04 01:50:45 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-09-04 01:45:08 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 01:42:25 +0200bliminse(~bliminse@user/bliminse)
2024-09-04 01:36:13 +0200ZharMeny(~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4))
2024-09-04 01:34:22 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-09-04 01:30:20 +0200bliminse(~bliminse@user/bliminse) (Ping timeout: 252 seconds)
2024-09-04 01:29:21 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-04 01:29:07 +0200acidjnk_new(~acidjnk@p200300d6e72cfb5469ca77b0637d5192.dip0.t-ipconnect.de)
2024-09-04 01:27:21 +0200machinedgod(~machinedg@d50-99-47-73.abhsia.telus.net)
2024-09-04 01:24:52 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-09-04 01:21:00 +0200 <davean> Just I better not care about any specific improvements
2024-09-04 01:20:31 +0200 <davean> but if someone wants to abstractly think about some business logic, I'm happy to expect it to be generally improved
2024-09-04 01:20:26 +0200 <c_wraith> I mean, in that case that's the code I want to run. Something simple where performance isn't critical
2024-09-04 01:20:12 +0200 <davean> It should never be terrible!
2024-09-04 01:20:04 +0200 <davean> c_wraith: right, for at least core stuff. I'm happy when I have a lot of code saying "it'll do a decent job on cleaning up this code that runs only a few times and isn't core"