2024/05/16

2024-05-16 00:00:22 +0200gamja19(~gamja@103.166.150.118)
2024-05-16 00:01:32 +0200gamja19(~gamja@103.166.150.118) (Client Quit)
2024-05-16 00:01:55 +0200gamja17(~gamja@103.166.150.118)
2024-05-16 00:02:11 +0200phma_phma
2024-05-16 00:02:29 +0200gamja17(~gamja@103.166.150.118) (Write error: Broken pipe)
2024-05-16 00:02:49 +0200mailman03(~mailman03@103.166.150.118)
2024-05-16 00:02:53 +0200qqq(~qqq@92.43.167.61) (Remote host closed the connection)
2024-05-16 00:03:48 +0200sixfourtwelve(~ethanmorg@pnwn-04-b2-v4wan-162727-cust211.vm43.cable.virginm.net) ()
2024-05-16 00:04:12 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2)
2024-05-16 00:10:17 +0200zzz(~yin@user/zero)
2024-05-16 00:13:12 +0200mailman03(~mailman03@103.166.150.118) (Quit: Client closed)
2024-05-16 00:13:37 +0200mailman03(~mailman03@103.166.150.118)
2024-05-16 00:23:43 +0200mailman03(~mailman03@103.166.150.118) (Ping timeout: 250 seconds)
2024-05-16 00:27:32 +0200zzz(~yin@user/zero) (Ping timeout: 252 seconds)
2024-05-16 00:32:01 +0200acidjnk_new(~acidjnk@p200300d6e714dc380dd5b841c8115985.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2024-05-16 00:35:29 +0200yin(~yin@user/zero)
2024-05-16 00:39:57 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-16 00:40:22 +0200sawilagar(~sawilagar@user/sawilagar) (Ping timeout: 255 seconds)
2024-05-16 00:41:05 +0200acidjnk_new(~acidjnk@p200300d6e714dc38a510b4bd44380922.dip0.t-ipconnect.de)
2024-05-16 00:42:20 +0200mei(~mei@user/mei)
2024-05-16 00:49:03 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out)
2024-05-16 00:50:46 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 00:53:32 +0200yin(~yin@user/zero) (Killed (NickServ (GHOST command used by yin_)))
2024-05-16 01:02:04 +0200aku(~aku@65.108.245.241) (Remote host closed the connection)
2024-05-16 01:02:43 +0200aku(~aku@65.108.245.241)
2024-05-16 01:03:15 +0200Sgeo(~Sgeo@user/sgeo)
2024-05-16 01:05:33 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 255 seconds)
2024-05-16 01:09:56 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2024-05-16 01:12:49 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2024-05-16 01:41:06 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-05-16 01:48:49 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
2024-05-16 01:49:30 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 01:51:07 +0200acidjnk_new(~acidjnk@p200300d6e714dc38a510b4bd44380922.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2024-05-16 01:54:50 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2024-05-16 01:59:50 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 02:11:59 +0200troydm(~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
2024-05-16 02:40:05 +0200cawfee(~root@2406:3003:2077:1c50::babe) (Ping timeout: 256 seconds)
2024-05-16 02:41:39 +0200visilii(~visilii@188.254.110.43) (Read error: Connection reset by peer)
2024-05-16 02:42:14 +0200visilii(~visilii@217.107.125.158)
2024-05-16 02:48:36 +0200 <Axman6> IORef + atomicModifyIORef['] is actually a very useful tool for concurrent programs which also has quite good performance
2024-05-16 02:50:29 +0200 <Axman6> Hmm, I shoudl check timestamps before replying to discussions from last night =)
2024-05-16 02:52:39 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 255 seconds)
2024-05-16 02:59:31 +0200yin_(~yin@user/zero)
2024-05-16 03:09:02 +0200otto_s(~user@p5de2fa8d.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2024-05-16 03:10:55 +0200otto_s(~user@p4ff27827.dip0.t-ipconnect.de)
2024-05-16 03:17:32 +0200y04nn(~username@2a03:1b20:8:f011::e10d) (Ping timeout: 260 seconds)
2024-05-16 03:21:33 +0200philopsos(~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net)
2024-05-16 03:25:29 +0200xff0x(~xff0x@2405:6580:b080:900:8cc9:e47c:f89a:15ee) (Ping timeout: 268 seconds)
2024-05-16 03:25:43 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz)
2024-05-16 03:26:51 +0200barak(~barak@2a0d:6fc2:68c1:7200:e61a:851b:d7b:27e8)
2024-05-16 03:34:03 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:a104:ac74:dd16:a7df) (Ping timeout: 256 seconds)
2024-05-16 03:38:02 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Quit: Lost terminal)
2024-05-16 03:39:35 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 03:40:13 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Quit: leaving)
2024-05-16 03:41:25 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2024-05-16 03:47:16 +0200bilegeek(~bilegeek@2600:1008:b010:1cfe:3776:17b8:1dc2:3fdf)
2024-05-16 03:52:56 +0200barak(~barak@2a0d:6fc2:68c1:7200:e61a:851b:d7b:27e8) (Ping timeout: 268 seconds)
2024-05-16 03:53:14 +0200ystael(~ystael@user/ystael) (Ping timeout: 256 seconds)
2024-05-16 04:00:11 +0200Axman6(~Axman6@user/axman6) (Server closed connection)
2024-05-16 04:05:00 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2024-05-16 04:12:35 +0200td_(~td@i53870936.versanet.de) (Ping timeout: 256 seconds)
2024-05-16 04:12:42 +0200discuss9128(~discuss91@137.132.213.131)
2024-05-16 04:14:01 +0200td_(~td@i53870936.versanet.de)
2024-05-16 04:25:21 +0200gorignak(~gorignak@user/gorignak)
2024-05-16 04:33:36 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:7d90:75c4:66ca:204a)
2024-05-16 04:39:59 +0200yin_(~yin@user/zero) (Ping timeout: 252 seconds)
2024-05-16 04:43:13 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2024-05-16 04:46:06 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2024-05-16 04:51:41 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 240 seconds)
2024-05-16 05:06:59 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 272 seconds)
2024-05-16 05:14:11 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-16 05:30:37 +0200discuss9128(~discuss91@137.132.213.131) (Quit: Client closed)
2024-05-16 05:32:48 +0200ystael(~ystael@user/ystael)
2024-05-16 05:37:30 +0200ystael(~ystael@user/ystael) (Ping timeout: 256 seconds)
2024-05-16 05:45:21 +0200Axman6(~Axman6@user/axman6)
2024-05-16 05:50:24 +0200EvanR(~EvanR@user/evanr) (Ping timeout: 255 seconds)
2024-05-16 05:53:41 +0200aforemny_(~aforemny@2001:9e8:6cd4:e700:d233:e5e6:582d:855)
2024-05-16 05:54:30 +0200aforemny(~aforemny@2001:9e8:6ced:bf00:55ed:d004:4aaa:1f0a) (Ping timeout: 256 seconds)
2024-05-16 06:07:40 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:7d90:75c4:66ca:204a) (Ping timeout: 268 seconds)
2024-05-16 06:09:38 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds)
2024-05-16 06:15:30 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 06:16:20 +0200Square(~Square@user/square)
2024-05-16 06:20:06 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds)
2024-05-16 06:23:39 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 06:24:19 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:913:214a:315:2891)
2024-05-16 06:32:57 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2024-05-16 06:35:57 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 06:42:49 +0200causal(~eric@50.35.88.207)
2024-05-16 06:42:49 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2024-05-16 06:48:44 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 06:51:13 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2024-05-16 06:56:43 +0200gorignak(~gorignak@user/gorignak) (Quit: quit)
2024-05-16 07:00:08 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:913:214a:315:2891) (Ping timeout: 260 seconds)
2024-05-16 07:02:39 +0200philopsos(~caecilius@pool-71-183-97-38.nycmny.fios.verizon.net) (Remote host closed the connection)
2024-05-16 07:03:16 +0200philopsos(~caecilius@user/philopsos)
2024-05-16 07:12:01 +0200jjnkn(~jjnkn@46.150.73.222.kyiv.volia.net)
2024-05-16 07:12:05 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 256 seconds)
2024-05-16 07:19:31 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2024-05-16 07:19:35 +0200philopsos1(~caecilius@user/philopsos)
2024-05-16 07:20:18 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2024-05-16 07:20:43 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 256 seconds)
2024-05-16 07:28:47 +0200jinsun(~jinsun@user/jinsun)
2024-05-16 07:30:04 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-05-16 07:40:44 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2024-05-16 07:41:49 +0200euleritian(~euleritia@dynamic-176-006-196-153.176.6.pool.telefonica.de)
2024-05-16 08:00:42 +0200sroso(~sroso@user/SrOso)
2024-05-16 08:03:31 +0200acidjnk(~acidjnk@p200300d6e714dc32b43b4fa4bda78a3a.dip0.t-ipconnect.de)
2024-05-16 08:11:25 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:a189:af79:61c5:4ba2)
2024-05-16 08:16:23 +0200superbil(~superbil@1-34-176-171.hinet-ip.hinet.net) (Quit: WeeChat 4.2.2)
2024-05-16 08:19:14 +0200internatetional(~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97)
2024-05-16 08:30:09 +0200jcarpenter2(~lol@2603:3016:1e01:b940:9e16:4716:cb0d:9d39) (Read error: Connection reset by peer)
2024-05-16 08:32:26 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 08:36:28 +0200internatetional(~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) (Quit: WeeChat 4.2.2)
2024-05-16 08:36:41 +0200internatetional(~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97)
2024-05-16 08:44:39 +0200fendor(~fendor@2a02:8388:1605:ce00:24e2:c141:1f86:a346)
2024-05-16 08:44:51 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-05-16 08:47:48 +0200m1dnight(~christoph@82.146.125.185) (Quit: WeeChat 4.2.2)
2024-05-16 08:48:13 +0200califax(~califax@user/califx)
2024-05-16 08:48:29 +0200m1dnight(~christoph@82.146.125.185)
2024-05-16 08:49:24 +0200califax(~califax@user/califx) (Read error: Connection reset by peer)
2024-05-16 08:50:36 +0200kuribas(~user@2a02:1808:2:a50c:ee7a:245e:1a98:7ade)
2024-05-16 08:51:28 +0200califax(~califax@user/califx)
2024-05-16 08:55:51 +0200Square2(~Square4@user/square)
2024-05-16 08:58:09 +0200ft(~ft@p508db8fc.dip0.t-ipconnect.de) (Quit: leaving)
2024-05-16 08:58:10 +0200Square(~Square@user/square) (Ping timeout: 246 seconds)
2024-05-16 09:00:11 +0200 <tomsmeding> the memory model thing with IORefs indeed refers to the methods outside of the atomic* family
2024-05-16 09:00:33 +0200 <tomsmeding> atomicModifyIORef is a great building block for concurrent programs, but sometimes you need more
2024-05-16 09:00:37 +0200kuribas`(~user@2a02:1808:8:dd22:98a8:ccd5:a4c3:db95)
2024-05-16 09:01:27 +0200 <tomsmeding> in concurrency terminology, atomicModifyIORef is non-blocking, which means a certain progress guarantee for your program (as long as you don't go implementing a lock yourself using atomicModifyIORef, which is possible)
2024-05-16 09:02:07 +0200kuribas(~user@2a02:1808:2:a50c:ee7a:245e:1a98:7ade) (Ping timeout: 255 seconds)
2024-05-16 09:02:13 +0200 <tomsmeding> many concurrent algorithms can be written in a non-blocking way (there's even a theorem that "all" can, in some sense, iirc), but that's not always the most efficient or most understandable way
2024-05-16 09:02:41 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2024-05-16 09:03:05 +0200 <tomsmeding> having transactions sometimes relieves you of a whole lot of trouble in designing your data structures and methods
2024-05-16 09:06:00 +0200euleritian(~euleritia@dynamic-176-006-196-153.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-16 09:06:18 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-16 09:08:08 +0200 <Axman6> yeah definitely, and can also lead to less contention on shared values - the difference between n IORef (Map Key Value) and Map Key (IORef value) (or even IORef (Map Key (IORef Value)) might make significant performance differences.
2024-05-16 09:08:57 +0200kuribas`(~user@2a02:1808:8:dd22:98a8:ccd5:a4c3:db95) (Ping timeout: 256 seconds)
2024-05-16 09:09:40 +0200 <c_wraith> that last one is dangerous
2024-05-16 09:10:14 +0200 <c_wraith> It's begging to introduce race conditions
2024-05-16 09:11:56 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2024-05-16 09:13:09 +0200 <Axman6> it can be used safely, you just wrap things in a safe interface
2024-05-16 09:15:20 +0200 <Axman6> getRefForKey outer key = do exists <- Map.lookup key <$> readIORef ref; case exists of Nothing -> do newRef <- newIORef; atomicModifyIORef ref (\old -> case Map.lookup key old of Nothing -> (Map.insert key newRef, newRef); Just race -> (old, race))
2024-05-16 09:15:37 +0200 <c_wraith> I'm not even sure it can be used safely. If you look at the Map and determine you need to insert a new key/value pair, you can't do that from within an atomicModifyIORef
2024-05-16 09:16:28 +0200 <Axman6> (missing `old` in the Map.insert but that should work)
2024-05-16 09:16:46 +0200 <Axman6> oh and the Just case for the first case uses the value returned
2024-05-16 09:17:14 +0200 <Axman6> this also assumes you never delete keys (use Maybe (IORef Value)) then)
2024-05-16 09:17:43 +0200 <c_wraith> It also assumes you never have two threads trying to insert the same key at the same time.
2024-05-16 09:17:53 +0200 <tomsmeding> c_wraith: I think Axman6 meant `IORef (Map Key (IORef Value))`
2024-05-16 09:18:03 +0200 <tomsmeding> judging from the getRefForKey code
2024-05-16 09:18:08 +0200 <Axman6> yes
2024-05-16 09:18:10 +0200 <c_wraith> so do I
2024-05-16 09:18:30 +0200 <tomsmeding> oh hm fair
2024-05-16 09:18:42 +0200 <tomsmeding> time-of-check to time-of-use race condition
2024-05-16 09:19:21 +0200 <Axman6> the code above should handle that fine, since it uses atomicModifyIORef in the update case, only one of the can put their key in
2024-05-16 09:19:46 +0200 <tomsmeding> interesting
2024-05-16 09:19:49 +0200 <Axman6> of the threads*
2024-05-16 09:20:00 +0200 <Axman6> but in the case where the key exists no synchronisation is needed
2024-05-16 09:20:20 +0200 <tomsmeding> neat
2024-05-16 09:20:27 +0200 <tomsmeding> gets you a limited interface though, to the map
2024-05-16 09:20:31 +0200 <tomsmeding> but if that's enough, it's nice
2024-05-16 09:20:44 +0200 <tomsmeding> also needs a read-heavy workload
2024-05-16 09:21:05 +0200 <Axman6> yeah - which my one use case for this particular design was =)
2024-05-16 09:21:39 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-16 09:21:41 +0200 <Axman6> actually that's not true, since things were only read when a uses used the webservice, which no one ever did =)
2024-05-16 09:22:17 +0200 <tomsmeding> :D
2024-05-16 09:22:25 +0200 <tomsmeding> write-light, then
2024-05-16 09:23:57 +0200frumon(~Frumon@user/Frumon)
2024-05-16 09:27:07 +0200 <c_wraith> Ok, it works on the assumption that the value you want to insert doesn't depend on whether there was already a key there or not (or depends trivially, with some sort of commutative operation)
2024-05-16 09:27:45 +0200_bo(~bo@198.red-83-56-252.dynamicip.rima-tde.net)
2024-05-16 09:28:09 +0200 <tomsmeding> I that would be a requirement from the interface of getRefForKey anyway, regardless of the implementation
2024-05-16 09:28:37 +0200 <c_wraith> You're adding extra semantics. I'm looking at the type. :P
2024-05-16 09:29:12 +0200 <tomsmeding> I'm looking at an idealised implementation in terms of `MVar (Map Key Value)`
2024-05-16 09:29:28 +0200kuribas`(~user@ip-188-118-57-242.reverse.destiny.be)
2024-05-16 09:29:30 +0200 <tomsmeding> and observing that this cleverer implementation does not have stronger preconditions than the MVar-based one
2024-05-16 09:30:31 +0200 <c_wraith> in practice, an MVar-based implementation will perform way better with heavy writes.
2024-05-16 09:30:38 +0200 <tomsmeding> of course
2024-05-16 09:30:46 +0200 <tomsmeding> hence the "write-light" observed above
2024-05-16 09:30:55 +0200bo_(~bo@198.red-83-56-252.dynamicip.rima-tde.net) (Ping timeout: 256 seconds)
2024-05-16 09:32:35 +0200 <c_wraith> and a TVar-based approach lets you write much more obviously-correct code that works under the write-light conditions.
2024-05-16 09:33:02 +0200 <tomsmeding> with slightly more overhead
2024-05-16 09:33:31 +0200 <tomsmeding> but true
2024-05-16 09:36:41 +0200bilegeek(~bilegeek@2600:1008:b010:1cfe:3776:17b8:1dc2:3fdf) (Quit: Leaving)
2024-05-16 09:42:21 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl)
2024-05-16 09:44:11 +0200cfricke(~cfricke@user/cfricke)
2024-05-16 09:46:51 +0200 <kuribas`> perhaps offtopic, but I looked at twelf, and I am surprised you need to reinvent equality (refl, cong, ...) for each datatype.
2024-05-16 09:49:30 +0200 <kuribas`> https://twelf.org/wiki/equality/
2024-05-16 09:56:54 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-16 10:02:03 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-05-16 10:02:54 +0200titibandit(~user@user/titibandit)
2024-05-16 10:03:14 +0200danza(~francesco@an-19-164-164.service.infuturo.it)
2024-05-16 10:15:27 +0200danza(~francesco@an-19-164-164.service.infuturo.it) (Remote host closed the connection)
2024-05-16 10:16:46 +0200 <ski> kuribas` : aiui, no parametric polymorphism, types only depend on values, not types; iirc, in original implementation, they had that, but they didn't include it in the reworked implementation (yet at least), because the theory for it was unclear
2024-05-16 10:17:40 +0200 <kuribas`> ski: so types are not values then?
2024-05-16 10:18:19 +0200 <ski> there are three levels, values, types, and kinds
2024-05-16 10:19:01 +0200 <ski> (in LF, the Logical Framework system, that Elf is based on, and of which Twelf is an implementation of)
2024-05-16 10:19:22 +0200 <kuribas`> Twelf is dependently typed Elf?
2024-05-16 10:19:35 +0200 <ski> no, LF is dependently typed to begin with
2024-05-16 10:19:44 +0200 <ski> bu there's no infinite tower of sorts
2024-05-16 10:20:15 +0200 <ski> it's a fairly conservative/restrictive theory
2024-05-16 10:20:24 +0200 <kuribas`> right, no type 1, type 2, ... as in idris2
2024-05-16 10:20:54 +0200 <ski> yep
2024-05-16 10:22:36 +0200 <ski> aiui, this is because (a) they purposely want a rather weak theory, to not assume too much, when representing object systems (logics, type systems, operational semantics, &c.); but also (b) in order to keep unification and type checking decidable
2024-05-16 10:24:19 +0200 <ski> (they have unification of lambda terms, up to alpha-, beta-, and eta- conversion. but lambda terms are rather weak, can't compute on sum types, and no recursion. you do computation not with functions, but with predicates/relations, iow logic programming, searching for proofs/values of propositions/types)
2024-05-16 10:25:53 +0200 <ski> (i may be missing some detail, or getting some details wrong, but that's my impression, from reading some papers about it, semi-recently .. still need to play around more in the implementation, though)
2024-05-16 10:32:39 +0200danse-nr3(~danse-nr3@an-19-164-164.service.infuturo.it)
2024-05-16 10:37:04 +0200frumon(~Frumon@user/Frumon) (Leaving)
2024-05-16 10:40:45 +0200_bo(~bo@198.red-83-56-252.dynamicip.rima-tde.net) (Quit: Leaving)
2024-05-16 10:41:05 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 10:42:28 +0200philopsos1(~caecilius@user/philopsos) (Ping timeout: 255 seconds)
2024-05-16 10:45:06 +0200chele(~chele@user/chele)
2024-05-16 10:48:19 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:d028:ce6d:23c1:c5bb)
2024-05-16 10:48:21 +0200 <int-e> You have to restrict beta for this to be decidable (unification can guess arguments of unbounded size so termination doesn't save you). https://www.cs.cmu.edu/~twelf/guide-1-4/twelf_5.html#SEC27 mentions higher-order pattern unification which IIRC doesn't have beta, and also doesn't guess the head of applications. The type checking/inference might have something a bit more fancy though.
2024-05-16 10:51:23 +0200 <ski> yes, the unification is restricted
2024-05-16 10:52:10 +0200 <ski> it has beta_0
2024-05-16 10:53:52 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-16 10:54:09 +0200 <ski> (the rules for how it's restricted are somewhat complicated. i read the L-lambda unification paper, and also the details of which unifications are allowed in Twelf, but i don't recall the details of either that well)
2024-05-16 10:54:54 +0200skiidly wonders whether something like L-lambda / higher-order pattern unification, could sensibly be added to GHC
2024-05-16 10:54:55 +0200 <int-e> Now what do I google to figure out what beta_0 is :)
2024-05-16 10:55:10 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz)
2024-05-16 10:55:21 +0200 <ski> basically `(\x. M) y', substituting `x' with another variable `y'
2024-05-16 10:55:54 +0200 <ski> (well, more specifically, either with a bound variable, or with a constant. but not with a logic / meta- variable, nor with an arbitrary term)
2024-05-16 10:56:06 +0200 <int-e> Ah, yeah supporting that makes sense to me.
2024-05-16 10:56:44 +0200 <ski> (i think in some papers, they also allow substituting like numeric literal, (unapplied) data constructors)
2024-05-16 10:57:47 +0200 <int-e> And I think it's a detail of the pattern unification that I forgot. Yeah I do remember support for constructors too.
2024-05-16 10:58:45 +0200skiread it like last month or so
2024-05-16 10:59:40 +0200 <ski> the "unification under a mixed prefix" paper by Dale Miller is also relevant
2024-05-16 11:00:09 +0200 <ski> .. as well as the tutorial interpreter paper for lambdaProlog (which implements that idea, amongst various other stuff)
2024-05-16 11:02:22 +0200 <ski> (they implement in SML, using a one-level continuation-passing style. success means calling continuation deeper. failure means returning. initial continuation will print out answer substitution, and query if user wants to search for more solutions. they implement cut by throwing exception)
2024-05-16 11:07:53 +0200gmg(~user@user/gehmehgeh)
2024-05-16 11:17:51 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:a189:af79:61c5:4ba2) (Ping timeout: 268 seconds)
2024-05-16 11:20:41 +0200 <kuribas`> ski: it looks like lists are parametric? https://twelf.org/wiki/lists/
2024-05-16 11:21:37 +0200__monty__(~toonn@user/toonn)
2024-05-16 11:21:59 +0200destituion(~destituio@2a02:2121:10b:62ca:bae7:e090:21e:1459) (Ping timeout: 256 seconds)
2024-05-16 11:22:50 +0200destituion(~destituio@85.221.111.174)
2024-05-16 11:24:47 +0200 <ski> "Unification Under a Mixed Prefix" by Dale Miller in 1992-07-08 at <https://www.lix.polytechnique.fr/~dale/papers/jsc92.pdf>
2024-05-16 11:24:50 +0200 <ski> "A Semi-Functional Implementation of a Higher-Order Logic Programming Language" by Conal Elliott,Frank Pfenning in 1990-02 (draft) at <http://www.cs.cmu.edu/~fp/papers/elpsml90.pdf>,<http://www.cs.cmu.edu/~fp/papers/elpsml-paper.tar.gz>
2024-05-16 11:25:30 +0200 <ski> kuribas` : sure, it's parametric in the sense of ML functors (parameterized modules), you can assume anything you like about the element type `elem'. but `list' has type `type', not `type -> type'
2024-05-16 11:26:22 +0200 <ski> (so `list' itself is not a parameterized type, and relations/predicates operating over it won't be parametrically polymorphic in the element type)
2024-05-16 11:26:57 +0200 <kuribas`> ski: If if I need 5 different types of lists, I need to load the module 5 times?
2024-05-16 11:30:50 +0200 <ski> (btw .. an LF program is basically a signature, a list of type signatures of constants (value constants and type constants) .. you can interpret this as something quite close to an ML module signature, and then you can introduce ML module functors into the picture, implementing the constants of one signature in terms of those of another. this is e.g. useful when you specify a type system using "declarative"
2024-05-16 11:30:56 +0200 <ski> inference rules (comprising one signature), and then also specify an alternative set of "algorithmic" inference rules (avoiding ambiguity, and allowing the type signatures to be effectively be interpreted as a logic program, something the declarative version often doesn't usefully, or at least efficiently, admit) .. and then the functor tells you how to transform a derivation in the algorithmic system (which
2024-05-16 11:31:02 +0200 <ski> proof search automatically can find for your), into a derivation in the declarative system)
2024-05-16 11:32:15 +0200 <ski> kuribas` : or load five (copy-pasted) versions of it. or perhaps it could be possible to parameterize the whole file on `elem', but aiui, Twelf doesn't currently implement anything like that
2024-05-16 11:33:51 +0200barak(~barak@2a0d:6fc2:68c1:7200:e61a:851b:d7b:27e8)
2024-05-16 11:34:26 +0200cfricke(~cfricke@user/cfricke) (Remote host closed the connection)
2024-05-16 11:34:45 +0200cfricke(~cfricke@user/cfricke)
2024-05-16 11:35:22 +0200 <ski> (i guess one should clearly distinguish here between wanting to parameterize an LF program (being a signature), and wanting to parameterize a realization of that signature (which would give a functor). what i meant to say at the end above is that i've seen papers for (and source code implementing) the latter, but not the former)
2024-05-16 11:37:44 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2024-05-16 11:37:44 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2024-05-16 11:38:23 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2024-05-16 11:38:38 +0200ec(~ec@gateway/tor-sasl/ec)
2024-05-16 11:42:40 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:e4f7:dd84:71b6:db6)
2024-05-16 11:46:26 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.2.2)
2024-05-16 11:49:41 +0200cfricke(~cfricke@user/cfricke)
2024-05-16 11:52:10 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds)
2024-05-16 11:53:45 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2024-05-16 11:56:18 +0200pie_(~pie_bnc@user/pie/x-2818909) ()
2024-05-16 11:56:36 +0200pie_(~pie_bnc@user/pie/x-2818909)
2024-05-16 11:58:52 +0200libertyprime(~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Remote host closed the connection)
2024-05-16 12:01:38 +0200danse-nr3(~danse-nr3@an-19-164-164.service.infuturo.it) (Ping timeout: 268 seconds)
2024-05-16 12:02:08 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1)
2024-05-16 12:08:51 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds)
2024-05-16 12:13:28 +0200todi(~todi@p57803331.dip0.t-ipconnect.de)
2024-05-16 12:20:48 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2024-05-16 12:21:37 +0200patrl(~patrl@user/patrl) (Remote host closed the connection)
2024-05-16 12:23:19 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2024-05-16 12:24:05 +0200patrl(~patrl@user/patrl)
2024-05-16 12:26:29 +0200patrl(~patrl@user/patrl) (Remote host closed the connection)
2024-05-16 12:28:55 +0200Square2(~Square4@user/square) (Ping timeout: 260 seconds)
2024-05-16 12:33:26 +0200famubu(~julinuser@user/famubu)
2024-05-16 12:37:33 +0200 <famubu> Hi. I had been trying to make a megaparsec parser to parse regular expression. I got atoms and concatenation working. Now I'm trying to get repetition like `r{2,4}` but couldn't finish it.
2024-05-16 12:38:01 +0200 <famubu> This is what I have: https://bpa.st/5O4Q
2024-05-16 12:38:31 +0200 <famubu> I wasn't sure how to add `rep` to the operator table (`optab`)
2024-05-16 12:41:15 +0200 <famubu> Saw this (parsec): https://stackoverflow.com/questions/9020254/using-parsec-to-parse-regular-expressions
2024-05-16 12:41:39 +0200 <famubu> where they mention it for `+`, and `*`. But still couldn't figure how to make it more general.
2024-05-16 12:44:01 +0200yin(~yin@user/zero)
2024-05-16 12:49:06 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:d028:ce6d:23c1:c5bb) (Remote host closed the connection)
2024-05-16 12:49:14 +0200 <tomsmeding> famubu: `Postfix rep` doesn't work?
2024-05-16 12:49:42 +0200 <tomsmeding> note the type of Postfix here https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/Control-Monad-Combinators-Expr.h…
2024-05-16 12:50:46 +0200 <tomsmeding> I wonder if your :- parsing is working though; should it not parse a '-'?
2024-05-16 12:53:57 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 12:55:45 +0200 <famubu> Symbols are single characters. So ABC should become like `A :- B :- C`. So no need to explicitly parse a hyphen. Is that what you meant?
2024-05-16 12:56:02 +0200 <tomsmeding> ah I see
2024-05-16 12:56:04 +0200 <tomsmeding> sure
2024-05-16 12:56:09 +0200 <famubu> Postfix rep didn't work. Because of the extra `Integer -> Integer`.
2024-05-16 12:56:20 +0200 <tomsmeding> (I wasn't reading carefully and assumed (:-) was for e.g. `[a-z]`
2024-05-16 12:56:22 +0200 <tomsmeding> )
2024-05-16 12:56:33 +0200 <famubu> Yeah.
2024-05-16 12:56:52 +0200 <famubu> Rep constructor is like `Re a -> Integer -> Integer`
2024-05-16 12:56:54 +0200rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-05-16 12:57:23 +0200 <famubu> This was the error: https://bpa.st/U6MQ
2024-05-16 12:57:32 +0200rvalue(~rvalue@user/rvalue)
2024-05-16 12:57:40 +0200 <tomsmeding> famubu: Postfix (Rep <$ rep) is not the same as Postfix rep
2024-05-16 12:57:43 +0200 <tomsmeding> I meant the latter
2024-05-16 12:57:54 +0200 <tomsmeding> <$ is for if you don't care about the result of 'rep' and want it to be Rep anyway
2024-05-16 12:57:58 +0200 <neiluj> hey! ocaml guy here! I'd like to deepen my knowledge by playing with haskell advanced features such as liquid haskell, category theory stuff. Which projects/reading material would you recommend to achieve this goal?
2024-05-16 12:58:00 +0200 <tomsmeding> but Rep is not fully applied so that fails
2024-05-16 12:58:03 +0200 <tomsmeding> :t (<$)
2024-05-16 12:58:04 +0200 <lambdabot> Functor f => a -> f b -> f a
2024-05-16 12:58:23 +0200 <tomsmeding> famubu: `rep` returns useful info here so you shouldn't use (<$)
2024-05-16 12:59:37 +0200 <famubu> Oh.. sorry. That worked. I'm not yet that good at extracting the correct info from the types.. 😬
2024-05-16 12:59:41 +0200 <famubu> Thanks.
2024-05-16 13:00:01 +0200 <tomsmeding> famubu: every time you figure something like this out, you gain a little more intuition for what the types meant :)
2024-05-16 13:00:08 +0200 <famubu> :)
2024-05-16 13:00:14 +0200 <famubu> Yeah
2024-05-16 13:02:20 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds)
2024-05-16 13:02:50 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2024-05-16 13:07:27 +0200xff0x(~xff0x@2405:6580:b080:900:25be:f228:ec64:b69c)
2024-05-16 13:12:25 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:c695:1779:f1ed:a0d3)
2024-05-16 13:18:09 +0200sroso(~sroso@user/SrOso) (Quit: Leaving :))
2024-05-16 13:21:56 +0200patrl(~patrl@user/patrl)
2024-05-16 13:26:21 +0200patrl(~patrl@user/patrl) (Remote host closed the connection)
2024-05-16 13:28:44 +0200patrl(~patrl@user/patrl)
2024-05-16 13:32:53 +0200koz(~koz@121.99.240.58) (Ping timeout: 256 seconds)
2024-05-16 13:33:27 +0200Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds)
2024-05-16 13:34:09 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.2.2)
2024-05-16 13:34:35 +0200koz(~koz@121.99.240.58)
2024-05-16 13:35:46 +0200bolivood1(~bolivood@2a0d:6fc2:5d10:8200:11e8:e299:e23d:e488)
2024-05-16 13:37:37 +0200Maxdamantus(~Maxdamant@user/maxdamantus)
2024-05-16 13:37:59 +0200bolivood(~bolivood@2a0d:6fc2:5d10:8200:e4f7:dd84:71b6:db6) (Ping timeout: 256 seconds)
2024-05-16 13:39:43 +0200danse-nr3(~danse-nr3@an-19-164-164.service.infuturo.it)
2024-05-16 13:41:02 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer)
2024-05-16 13:44:38 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 13:47:31 +0200xdminsy(~xdminsy@117.147.70.240) (Quit: Konversation terminated!)
2024-05-16 13:47:54 +0200xdminsy(~xdminsy@117.147.70.240)
2024-05-16 13:57:11 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-05-16 14:04:03 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 255 seconds)
2024-05-16 14:05:29 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 14:05:59 +0200danse-nr3(~danse-nr3@an-19-164-164.service.infuturo.it) (Read error: Connection reset by peer)
2024-05-16 14:06:15 +0200danse-nr3(~danse-nr3@151.43.160.43)
2024-05-16 14:19:47 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Ping timeout: 264 seconds)
2024-05-16 14:20:23 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2024-05-16 14:30:52 +0200danse-nr3(~danse-nr3@151.43.160.43) (Read error: Connection reset by peer)
2024-05-16 14:31:07 +0200cfricke(~cfricke@user/cfricke)
2024-05-16 14:31:09 +0200danse-nr3(~danse-nr3@151.43.160.43)
2024-05-16 14:36:38 +0200Square2(~Square4@user/square)
2024-05-16 14:39:14 +0200destituion(~destituio@85.221.111.174) (Ping timeout: 256 seconds)
2024-05-16 14:41:58 +0200bolivood1(~bolivood@2a0d:6fc2:5d10:8200:11e8:e299:e23d:e488) (Ping timeout: 268 seconds)
2024-05-16 14:42:27 +0200destituion(~destituio@2a02:2121:10b:62ca:10a5:f759:7fb5:9fb1)
2024-05-16 14:46:05 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2024-05-16 14:47:13 +0200__monty__(~toonn@user/toonn) (Ping timeout: 268 seconds)
2024-05-16 14:55:11 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 264 seconds)
2024-05-16 15:06:47 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 15:11:23 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 252 seconds)
2024-05-16 15:17:14 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 15:19:12 +0200bolivood1(~bolivood@2a0d:6fc2:5d10:8200:95cf:c099:dbf9:bb2d)
2024-05-16 15:19:45 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-16 15:34:36 +0200ystael(~ystael@user/ystael)
2024-05-16 15:41:57 +0200yinzzz
2024-05-16 15:42:22 +0200__monty__(~toonn@user/toonn)
2024-05-16 15:51:43 +0200random-jellyfish(~developer@user/random-jellyfish) (Ping timeout: 256 seconds)
2024-05-16 15:56:22 +0200Sgeo(~Sgeo@user/sgeo)
2024-05-16 15:59:45 +0200neiluj_(~neiluj@193.203.71.162)
2024-05-16 16:00:47 +0200 <Athas> tomsmeding: does Accelerate work with CUDA 12?
2024-05-16 16:02:08 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-16 16:02:32 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 252 seconds)
2024-05-16 16:05:27 +0200neiluj_(~neiluj@193.203.71.162) (Ping timeout: 256 seconds)
2024-05-16 16:05:50 +0200bolivood1(~bolivood@2a0d:6fc2:5d10:8200:95cf:c099:dbf9:bb2d) (Ping timeout: 268 seconds)
2024-05-16 16:06:17 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds)
2024-05-16 16:10:51 +0200 <tomsmeding> Athas: no, <=11
2024-05-16 16:11:17 +0200 <tomsmeding> Indirectly blocked on https://github.com/visq/language-c/pull/94
2024-05-16 16:11:25 +0200 <Athas> That'll be an issue.
2024-05-16 16:11:49 +0200 <tomsmeding> I think with sufficient hackery you can take that PR and build with that
2024-05-16 16:12:13 +0200 <tomsmeding> The problem is that language-c is a dep of c2hs which is a *build-dependency* of cuda, which is a dep of accelerate
2024-05-16 16:12:32 +0200 <tomsmeding> And a simple source-repository-package in cabal.project doesn't override build deps
2024-05-16 16:12:43 +0200 <Athas> I hope the Accelerate/CFAL team will do that, because otherwise it will not run on the benchmarking machine.
2024-05-16 16:12:59 +0200 <tomsmeding> I think I managed to override it at some point with sufficient vendoring
2024-05-16 16:13:00 +0200 <tomsmeding> Ah
2024-05-16 16:13:13 +0200 <tomsmeding> We'll have a look, but might take a few days
2024-05-16 16:17:35 +0200EvanR(~EvanR@user/evanr)
2024-05-16 16:23:44 +0200billchenchina-(~billchenc@103.152.35.21) (Remote host closed the connection)
2024-05-16 16:24:12 +0200billchenchina(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe)
2024-05-16 16:24:54 +0200billchenchina(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Max SendQ exceeded)
2024-05-16 16:25:18 +0200billchenchina(~billchenc@103.152.35.21)
2024-05-16 16:26:49 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 16:29:55 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 16:31:08 +0200califax(~califax@user/califx)
2024-05-16 16:35:06 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-16 16:38:14 +0200billchenchina(~billchenc@103.152.35.21) (Remote host closed the connection)
2024-05-16 16:38:47 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2024-05-16 16:38:56 +0200billchenchina(~billchenc@103.152.35.21)
2024-05-16 16:41:00 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-16 16:43:45 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 16:47:18 +0200Square2(~Square4@user/square) (Ping timeout: 256 seconds)
2024-05-16 16:48:17 +0200califax(~califax@user/califx)
2024-05-16 16:49:51 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 16:51:27 +0200random-jellyfish(~developer@2a02:2f04:11e:c600:4e7a:622:23f0:da46)
2024-05-16 16:51:27 +0200random-jellyfish(~developer@2a02:2f04:11e:c600:4e7a:622:23f0:da46) (Changing host)
2024-05-16 16:51:27 +0200random-jellyfish(~developer@user/random-jellyfish)
2024-05-16 16:51:52 +0200califax(~califax@user/califx)
2024-05-16 16:56:41 +0200Square2(~Square4@user/square)
2024-05-16 17:02:33 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 256 seconds)
2024-05-16 17:03:23 +0200ocra8(ocra8@user/ocra8)
2024-05-16 17:04:30 +0200Guest13(~Guest13@cpc93370-hers8-2-0-cust590.6-3.cable.virginm.net)
2024-05-16 17:05:25 +0200zzz(~yin@user/zero) (Ping timeout: 255 seconds)
2024-05-16 17:08:23 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 17:10:16 +0200califax(~califax@user/califx)
2024-05-16 17:14:18 +0200chele(~chele@user/chele) (Remote host closed the connection)
2024-05-16 17:15:01 +0200califax(~califax@user/califx) (Remote host closed the connection)
2024-05-16 17:18:28 +0200Square2(~Square4@user/square) (Ping timeout: 260 seconds)
2024-05-16 17:18:33 +0200neiluj(~neiluj@193.203.71.162)
2024-05-16 17:18:48 +0200califax(~califax@user/califx)
2024-05-16 17:21:36 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 255 seconds)
2024-05-16 17:23:23 +0200 <Guest13> hi, how can I memoize recursive calls that aren't simple like the fibonacci. I see on the wiki for memoization there is an example memo_fib= (map fib [1..] !!), but the problem I am trying to solve has the recursive calls in an order I don't necessarily know
2024-05-16 17:24:21 +0200 <Guest13> it is the sort of problem where I would want to have a map to store previous calls
2024-05-16 17:28:48 +0200 <ski> so use a map ?
2024-05-16 17:29:08 +0200 <ski> .. or how large is your domain ?
2024-05-16 17:30:46 +0200 <ski> (oh, and jfyi, that `memo_fib' still uses `fib' (but not `memo_fib') for each individual call, so not reusing the list resulting from the `map' as a cache)
2024-05-16 17:32:32 +0200 <ski> anyway, if you already know from the start (perhaps from the initial parameters) how large domain you need for the recursive calls corresponding to subproblems of that initial problem, you can allocate a map (recursively defined) that has an association mapping each element of your domain to the corresponding result value (lazily computed)
2024-05-16 17:33:37 +0200 <ski> .. but if your domain is large, the map would also be large. sometimes you can allocate the association structure itself, lazily, incrementally (like the infinite linked list above)
2024-05-16 17:36:42 +0200zzz(~yin@user/zero)
2024-05-16 17:37:26 +0200 <Guest13> I understand to use a map but I don't know how I would implement it
2024-05-16 17:38:01 +0200 <Guest13> I can't think about it functionally very well, I am thinking that each time it does a call it updates an internal "state"
2024-05-16 17:38:24 +0200 <Guest13> ie adds to the map, or checks the map
2024-05-16 17:38:50 +0200 <Guest13> I've seen the rec keyword but this is also something I am unsure about
2024-05-16 17:40:41 +0200 <ski> there is no state, adding to the map, unless you express this with state in some fashion .. and it's probably better to avoid that, if you can
2024-05-16 17:41:02 +0200 <ski> `rec' is for something else (recursive bindings in `do')
2024-05-16 17:42:21 +0200 <ski> @let tabulate :: Ix i => (i,i) -> (i -> e) -> Array i e; tabulate ix f = listArray ix [f i | i <- range ix]
2024-05-16 17:42:22 +0200 <lambdabot> Defined.
2024-05-16 17:43:49 +0200 <ski> > L.tabulate (-2,3) (\i -> i^2) -- construct an array, with each element based on its index
2024-05-16 17:43:51 +0200 <lambdabot> array (-2,3) [(-2,4),(-1,1),(0,0),(1,1),(2,4),(3,9)]
2024-05-16 17:46:32 +0200 <ski> > let memoFib n | n >= 0 = fibs ! n where fibs = L.tabulate (0,n) fib; fib 0 = 0; fib 1 = 1; fib n = fibs ! (n - 1) + fibs ! (n - 2) in memoFib 12
2024-05-16 17:46:33 +0200 <lambdabot> 144
2024-05-16 17:48:01 +0200 <Guest13> the problem I have is that each recursive call is defined by [Int], Int, [Int]
2024-05-16 17:48:12 +0200 <ski> Guest13 : can you follow that ^ example ? given a (non-negative) integer `n', it builds an array (`fibs') with `n+1' elements (indexed from `0' to `1'), with elements set by the fibonacci function (`fib') where recursive calls look up results in the array, and so will be cached (the array elements are lazily computed)
2024-05-16 17:48:44 +0200 <ski> the array `fibs' and the function `fib' are mutually recursively defined. you can inline one into the other as
2024-05-16 17:49:28 +0200 <ski> > let memoFib n | n >= 0 = fibs ! n where fibs = L.tabulate (0,n) (\n -> case n of 0 -> 0; 1 -> 1; n -> fibs ! (n - 1) + fibs ! (n - 2)) in memoFib 12 -- array `fibs' is (lazily) recursively defined in terms of itself
2024-05-16 17:49:30 +0200 <lambdabot> 144
2024-05-16 17:49:36 +0200 <Guest13> im not sure I can, the state I have is 2 arrays which im comparing to each other and an integer to denote a counter and a string
2024-05-16 17:50:00 +0200 <Guest13> if it helps, I can explain the problem
2024-05-16 17:50:34 +0200 <ski> are `[Int]',`Int',`[Int]' your parameter types ?
2024-05-16 17:50:57 +0200 <ski> are you sure you have two arrays, and not two lists ?
2024-05-16 17:51:25 +0200 <ski> when you call recursively, which parameters (may) change ?
2024-05-16 17:51:48 +0200 <ski> explaining it may help, possibly
2024-05-16 17:51:53 +0200danse-nr3(~danse-nr3@151.43.160.43) (Remote host closed the connection)
2024-05-16 17:52:17 +0200danse-nr3(~danse-nr3@151.43.160.43)
2024-05-16 17:53:19 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1)
2024-05-16 17:54:59 +0200Guest13(~Guest13@cpc93370-hers8-2-0-cust590.6-3.cable.virginm.net) (Ping timeout: 250 seconds)
2024-05-16 17:56:46 +0200jrm(~jrm@user/jrm) (Quit: ciao)
2024-05-16 17:57:22 +0200 <EvanR> "use a map" could be ambiguous
2024-05-16 17:57:41 +0200 <EvanR> the function map, the Data.Map container
2024-05-16 17:57:43 +0200 <ski> hm, i guess
2024-05-16 17:57:58 +0200 <EvanR> both could be used for memoizing
2024-05-16 17:58:17 +0200jrm(~jrm@user/jrm)
2024-05-16 17:58:59 +0200 <EvanR> at least other functionalish languages are being consistent in this jargon xD
2024-05-16 17:59:12 +0200 <EvanR> map vs map
2024-05-16 18:00:24 +0200 <ski> hm ?
2024-05-16 18:02:32 +0200 <EvanR> it's been a while since I didn't know jargon but I have to wonder if noobs are confused by the collision of map function and map data structure
2024-05-16 18:02:46 +0200 <EvanR> in not just haskell
2024-05-16 18:03:26 +0200 <dolio> I can't recall it ever being confusing.
2024-05-16 18:04:57 +0200danse-nr3(~danse-nr3@151.43.160.43) (Read error: Connection reset by peer)
2024-05-16 18:04:59 +0200 <ski> i wonder about the etymology of the `map' function
2024-05-16 18:05:21 +0200 <ski> did LISP 1.5 have `MAPCAR' ?
2024-05-16 18:05:31 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2024-05-16 18:06:07 +0200 <dolio> I think it goes pretty far back in lisp.
2024-05-16 18:09:12 +0200 <dolio> The lisp 1.6 manual has it.
2024-05-16 18:09:43 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:c695:1779:f1ed:a0d3) (Remote host closed the connection)
2024-05-16 18:10:30 +0200 <ski> anyway, for the data structure, surely "(finite) map" is because it's representing a "map" (or "mapping"), being a word that's basically a synonym for "function","transform", the "finite" part referring to that it has a finite domain, or that it's a partial function defined on a finite subset of the domain (sometimes representing a function with "finite support" meaning that it only maps to "nonzero" on a
2024-05-16 18:10:37 +0200 <ski> finite subset of the domain)
2024-05-16 18:11:01 +0200 <ski> i guess 1.5 probably does then, too
2024-05-16 18:11:28 +0200kuribas`(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2024-05-16 18:12:07 +0200 <ski> if you think of the list as representing a subset, then the `map' function computes the (existential/direct) image of the function on that subset .. not sure why one would call this "map"
2024-05-16 18:13:11 +0200 <dolio> Lists aren't subsets, though.
2024-05-16 18:14:28 +0200 <c_wraith> is Int overflow behavior actually specified on overflow?
2024-05-16 18:14:40 +0200 <ski> > [0,1,0,2,0,1,0,3] \\ [2,1,0]
2024-05-16 18:14:42 +0200 <lambdabot> [0,0,1,0,3]
2024-05-16 18:14:46 +0200 <c_wraith> wow, good sentence construction there.
2024-05-16 18:14:58 +0200Guest13(~Guest13@cpc93370-hers8-2-0-cust590.6-3.cable.virginm.net)
2024-05-16 18:15:15 +0200 <Guest13> sorry ski I had to pick my mum up from station
2024-05-16 18:15:27 +0200 <dolio> Anyhow, 'map' doesn't just mean 'function' it's also the act of associating or carrying an input to an output by a function.
2024-05-16 18:15:58 +0200 <Guest13> yes, [Int] [Int] int String are the parameters
2024-05-16 18:16:11 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds)
2024-05-16 18:16:20 +0200 <Guest13> or at least what I had in the recursive call
2024-05-16 18:16:30 +0200 <dolio> And that's what 'map' does on all elements of some container.
2024-05-16 18:16:40 +0200 <dolio> Lists in the case of old lisp.
2024-05-16 18:16:57 +0200 <ski> i guess that's the connection, then
2024-05-16 18:17:10 +0200manwithluck(~manwithlu@149.102.244.20) (Read error: Connection reset by peer)
2024-05-16 18:17:11 +0200 <ski> Guest13 : and which of those are actually changing ?
2024-05-16 18:17:19 +0200 <Guest13> all of them
2024-05-16 18:18:02 +0200 <Guest13> I can simplify it to Int Int [Int] String
2024-05-16 18:18:06 +0200 <ski> are you sure dynamic programming would make sense, for your problem, then ?
2024-05-16 18:18:21 +0200 <Guest13> yes, but I am probably framing it badly
2024-05-16 18:18:29 +0200 <ski> .. or are you just looking for caching results of calls, to avoid recomputing later ?
2024-05-16 18:18:33 +0200 <Guest13> to make it easy I just wanted to cache results of calls
2024-05-16 18:18:35 +0200 <Guest13> yes
2024-05-16 18:19:47 +0200 <ski> oh, and when i asked "which of those are actually changing ?", i specifically had *recursive* calls in mind (not initial/top calls from other places)
2024-05-16 18:20:07 +0200 <Guest13> can you explain what is the difference?
2024-05-16 18:20:53 +0200 <Guest13> the recursive call changes all of the above, and the top call I believe will start at 0 0 [Int] String
2024-05-16 18:21:26 +0200 <Guest13> I could frame it as Int Int Int and have [Int] and String as references
2024-05-16 18:22:10 +0200 <ski> if only some of the parameters changed in recursive calls, then you could, within a single toplevel call, only cache for the changing parameters, thereby simplifying the datastructure needed to cache results
2024-05-16 18:22:24 +0200 <Guest13> this would be ideal
2024-05-16 18:22:35 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 256 seconds)
2024-05-16 18:22:38 +0200 <Guest13> I can formulate it as Int Int Int, with constant [Int] and String
2024-05-16 18:22:53 +0200 <ski> (for each new toplevel call, you'd generate a fresh/new cache, from scratch, whose results would only be reused for recursive calls stemming from that particular toplevel call)
2024-05-16 18:24:25 +0200 <ski> ok, maybe it would make sense to cache in a three-dimensional array, or (if you only need sparse inputs) maybe use a `Map (Int,Int,Int) Result' or something like that (that'd still require you to know upfront which triples would be needed, which might not be ideal)
2024-05-16 18:24:35 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 268 seconds)
2024-05-16 18:24:49 +0200 <ski> (or `Map Int (Map Int (Map Int Result))', i guess ..)
2024-05-16 18:24:55 +0200 <Guest13> can be sparse or dense depending on input
2024-05-16 18:25:20 +0200 <Guest13> I don't know upfront which triples are needed
2024-05-16 18:25:27 +0200 <ski> if you're okay with a dense caching space, you could try caching with an array
2024-05-16 18:26:10 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2024-05-16 18:26:32 +0200 <ski> but if your ranges (?) of `Int's are large, the array would contain a lot of elements, take a lot of space (the array itself would be allocated eagerly, only the array elements would be lazily evaluated)
2024-05-16 18:27:00 +0200 <Guest13> the ranges aren't large
2024-05-16 18:27:20 +0200 <Guest13> at most like 20
2024-05-16 18:27:21 +0200 <ski> so, maybe try `Array (Int,Int,Int) Result' ?
2024-05-16 18:27:31 +0200 <Guest13> ok, how can I use this to cache
2024-05-16 18:27:35 +0200tomboy64(~tomboy64@user/tomboy64)
2024-05-16 18:27:45 +0200manwithluck(~manwithlu@149.102.244.20)
2024-05-16 18:27:57 +0200 <Guest13> I understand the map f [1..] for fib, and even the tabulate version you showed me but I don't understand this one
2024-05-16 18:28:03 +0200 <Guest13> im not really doing dp
2024-05-16 18:28:06 +0200 <ski> you can use `listArray' (or `array'), or the `tabulate' i defined above, to (lazily) populate the array with elements, based on their indices
2024-05-16 18:28:54 +0200 <ski> oh, you said "yes, but I am probably framing it badly" just after i asked "are you sure dynamic programming would make sense, for your problem, then ?", so i was taking that for granted
2024-05-16 18:28:58 +0200 <Guest13> so I can do a \(x,y,z) -> f x y-1 z + f x-1 y z
2024-05-16 18:29:20 +0200euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2024-05-16 18:29:25 +0200 <Guest13> I think I get how to do it
2024-05-16 18:30:11 +0200 <Guest13> im trying to count the ways of doing something
2024-05-16 18:31:37 +0200 <ski> (i guess you actually meant `f x (y-1) z + f (x-1) y z', btw)
2024-05-16 18:32:10 +0200 <Guest13> I will have a go at this
2024-05-16 18:32:25 +0200 <Guest13> I need to think about how to implement the "dead ends" of the recursive call
2024-05-16 18:32:56 +0200 <Guest13> its basically a "ways if go left" + "ways if go right" recursion
2024-05-16 18:33:11 +0200 <Guest13> and you have some calls where you say it has gone wrong and ways = 0
2024-05-16 18:34:55 +0200 <ski> base cases / dead ends, i guess
2024-05-16 18:35:09 +0200 <Guest13> this would be setting the value to 0
2024-05-16 18:35:20 +0200 <mauke> dead ends are where the recursion dies :-)
2024-05-16 18:35:38 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net)
2024-05-16 18:35:53 +0200euphores(~SASL_euph@user/euphores)
2024-05-16 18:35:55 +0200 <Guest13> yeah, for some reason it being in a table confused me
2024-05-16 18:37:05 +0200 <Guest13> I think I get it though, my program will query 0 0 0 in the table which will spawn recursive calls and the base case is n m 0 = 1
2024-05-16 18:37:48 +0200 <Guest13> I will try this now thank you for the help ski
2024-05-16 18:39:44 +0200 <Guest13> do I need to define my own 3d tabulate?
2024-05-16 18:43:30 +0200 <ski> the above should work
2024-05-16 18:44:55 +0200hueso(~root@user/hueso) (Read error: Connection reset by peer)
2024-05-16 18:45:20 +0200 <ski> (there are instances like `(Ix a,Ix b,Ix c) => Ix (a,b,c)')
2024-05-16 18:45:44 +0200 <ski> > range ((0,0),(1,3))
2024-05-16 18:45:45 +0200 <lambdabot> [(0,0),(0,1),(0,2),(0,3),(1,0),(1,1),(1,2),(1,3)]
2024-05-16 18:45:55 +0200 <ski> @type range
2024-05-16 18:45:56 +0200 <lambdabot> Ix a => (a, a) -> [a]
2024-05-16 18:46:05 +0200hueso(~root@user/hueso)
2024-05-16 18:46:08 +0200 <Guest13> I see
2024-05-16 18:46:21 +0200 <ski> that's all indices in a rectangle, with upper left corner `(0,0)', lower right corner `(1,3)'
2024-05-16 18:47:00 +0200 <ski> .. and `tabulate' calls `listArray' with a list defined using `range' to generate elements for all valid indices
2024-05-16 18:47:08 +0200 <ski> @type listArray
2024-05-16 18:47:09 +0200 <lambdabot> Ix i => (i, i) -> [e] -> Array i e
2024-05-16 18:47:15 +0200 <ski> @type array
2024-05-16 18:47:16 +0200 <lambdabot> Ix i => (i, i) -> [(i, e)] -> Array i e
2024-05-16 18:48:40 +0200 <ski> (`listArray' is for when you just want to list the array elements (in proper index enumeration order, as given by e.g. `range'. `array' allows you to give the elements in arbitrary order, but then you have to pair up each element with its corresponding index, and it's also possible to repeat an index (in which case, iirc, it will just pick the last association pair))
2024-05-16 18:48:46 +0200 <Guest13> "where fibs = L.tabulate (0,n) (\n -> case n of 0 -> 0; 1 -> 1; n -> fibs ! (n - 1) + fibs ! (n - 2))" is crazy
2024-05-16 18:48:58 +0200 <ski> it's just a recursivelt defined array
2024-05-16 18:49:03 +0200 <Guest13> yeah I like it
2024-05-16 18:49:25 +0200 <ski> it automatically gives you top-down dynamic programming, through lazy caching of the array elements
2024-05-16 18:49:40 +0200 <Guest13> I can never get top down vs bottom up lol
2024-05-16 18:49:52 +0200 <Guest13> I know one goes from leaves other from root but idk
2024-05-16 18:50:16 +0200 <ski> bottom-up means that you start at the "base cases" of the recursion, building your way upwards. for fibonacci, this would be starting at `0' and `1'
2024-05-16 18:50:43 +0200 <Guest13> but when you call it you start at the top?
2024-05-16 18:50:51 +0200 <Guest13> and then work your way down to the bottom
2024-05-16 18:50:55 +0200 <Guest13> and then back up to the top
2024-05-16 18:51:01 +0200 <ski> it requires knowing which results will depend on which other results, so that you can make sure to initialize the latter results before the former ones need them
2024-05-16 18:51:26 +0200 <ski> top-down means that you start at the top desired result, and then let demand determine which sub-results are actually demanded
2024-05-16 18:51:54 +0200 <Guest13> ok so fib (n-1) + fib (n-2) is top down
2024-05-16 18:51:59 +0200 <ski> (and those are then cached, so that if they're needed in a sibling branch of the call-tree, they won't be recomputed, but just looked up)
2024-05-16 18:52:51 +0200 <Guest13> what is an example of bottom up, I know bottom up parsing where you look at "leaves" of the grammar and then say this must be this production rule and so on
2024-05-16 18:52:58 +0200 <Guest13> but not other cases
2024-05-16 18:53:48 +0200 <ski> yea. if you do `fib n = fibLoop 0 1 n where fibLoop a b 0 = a; fibLoop a !b n = fibLoop b (a + b) (n-1)', then that's bottom-up (but keeping just the last two results around, since for fibonacci we know we don't need any previous ones any longer)
2024-05-16 18:54:39 +0200 <Guest13> ah I see
2024-05-16 18:54:47 +0200 <Guest13> bottom up is usually better surely
2024-05-16 18:54:53 +0200 <Guest13> if you can do it
2024-05-16 18:56:01 +0200neiluj(~neiluj@193.203.71.162) (Ping timeout: 256 seconds)
2024-05-16 18:57:21 +0200 <Guest13> is it convention to put the changing values in the recursive call before or after the static ones?
2024-05-16 18:57:26 +0200 <ski> > let memoFib n | n >= 0 = fib n where ((!) . L.tabulate (0,n) -> fib) = \case 0 -> 0; 1 -> 1; n -> fib (n-1) + fib (n-2) in memoFib 12
2024-05-16 18:57:28 +0200 <lambdabot> 144
2024-05-16 18:57:30 +0200 <ski> ^ a cute way to, instead of inlining the function `fib' into the array `fibs', inlining the array `fibs' into the function `fib', using `ViewPatterns' to pass the function `\case ...' through `L.tabulate (0,n)' (giving back an array), and then also through `(!)' (indexing the array, giving back a function), before naming that function `fib' .. while `\case ...' already uses that `fib', recursively
2024-05-16 18:58:18 +0200 <ski> @let memoArray :: Ix i => (i,i) -> (i -> e) -> (i -> e); memoArray ix f = (L.tabulate ix f !)
2024-05-16 18:58:19 +0200 <lambdabot> Defined.
2024-05-16 18:58:35 +0200 <ski> > let memoFib n | n >= 0 = fib n where (memoArray (0,n) -> fib) = \case 0 -> 0; 1 -> 1; n -> fib (n-1) + fib (n-2) in memoFib 12 -- same thing, just slightly clearer
2024-05-16 18:58:37 +0200 <lambdabot> 144
2024-05-16 19:00:39 +0200 <Guest13> not sure I understand this one
2024-05-16 19:00:42 +0200 <ski> Guest13 : "bottom up is usually better surely","if you can do it" -- depends. if you know which results will be needed, beforehand, i'll probably be a little more efficient, i suppose. but if there may be large swathes of subresults that may not actually be needed, then it's hard to avoid computing them anyway with bottom-up, so in that case you may be doing quite a bit more work than for top-down
2024-05-16 19:01:13 +0200 <Guest13> ((!) . tabulate (0,n) -> fib) = \case 0 -> 0; 1 -> 1; n -> fib (n-1) + fib (n-2) I don't understand
2024-05-16 19:01:23 +0200 <ski> Guest13 : well, basically we just splice a memoization/caching lookup inbetween each recursive call
2024-05-16 19:01:50 +0200 <ski> `(<expr> -> <pat>)' is a, so-called, view pattern
2024-05-16 19:01:50 +0200 <Guest13> I don't understand the assignment
2024-05-16 19:02:12 +0200 <Guest13> we are assigning a function to the left
2024-05-16 19:02:24 +0200 <ski> my use of the view pattern above is rather unusual .. normally view patterns are used in function (formal) parameter patterns
2024-05-16 19:02:31 +0200 <ski> e.g.
2024-05-16 19:02:52 +0200 <ski> > let last (reverse -> x:_) = x in last [2,3,5,7]
2024-05-16 19:02:54 +0200 <lambdabot> 7
2024-05-16 19:03:31 +0200 <ski> this will call `reverse' on the input `[2,3,5,7]', before trying to match it with the pattern `x:_'. so we actually match the list `[7,5,3,2]' with the pattern `x:_', so `x' becomes `7'
2024-05-16 19:03:56 +0200 <ski> that example makes sense to you ?
2024-05-16 19:04:17 +0200 <Guest13> I understand what it is doing
2024-05-16 19:04:22 +0200 <ski> oh
2024-05-16 19:04:25 +0200 <Guest13> but not how the syntax reflects that
2024-05-16 19:04:25 +0200 <ski> in general
2024-05-16 19:04:36 +0200 <ski> foo (f -> y) = ..y..
2024-05-16 19:04:41 +0200 <Guest13> yeah
2024-05-16 19:04:49 +0200 <ski> can be refactored/rewritten as
2024-05-16 19:04:56 +0200 <ski> foo x = ..y..
2024-05-16 19:04:58 +0200 <ski> where
2024-05-16 19:05:01 +0200 <ski> y = f x
2024-05-16 19:05:55 +0200 <ski> (.. except that if `y' is a complex pattern, rather than a simple variable, then failure to match that pattern will cause the whole defining equation `foo (f -> y) = ...' to fail (trying the next defining equation instead), while with the `where'-version above, this doesn't happen)
2024-05-16 19:06:19 +0200 <ski> or, more generally, we can say that
2024-05-16 19:06:23 +0200 <ski> (f -> y) = x
2024-05-16 19:06:28 +0200 <ski> amounts to the same thing as
2024-05-16 19:06:32 +0200 <ski> y = f x
2024-05-16 19:07:01 +0200 <Guest13> I see how applying f to both sides does that
2024-05-16 19:07:02 +0200 <ski> (input `x', matched against the view-pattern `(f -> y)', will call `f' on the input `x', and match the result of that to the pattern `y')
2024-05-16 19:07:11 +0200 <ski> so, in my example
2024-05-16 19:07:20 +0200 <ski> (memoArray (0,n) -> fib) = \case 0 -> 0; 1 -> 1; n -> fib (n-1) + fib (n-2)
2024-05-16 19:07:26 +0200 <ski> this is actually the same thing as
2024-05-16 19:07:36 +0200 <ski> fib = memoArray (0,n) (\case 0 -> 0; 1 -> 1; n -> fib (n-1) + fib (n-2))
2024-05-16 19:07:59 +0200 <Guest13> is there a reason to phrase it like that?
2024-05-16 19:08:04 +0200 <ski> cuteness
2024-05-16 19:08:08 +0200 <Guest13> lol
2024-05-16 19:08:31 +0200 <Guest13> I understood the below one immediately but the top was super confusing lol
2024-05-16 19:08:38 +0200 <Guest13> I think I get it now though
2024-05-16 19:08:58 +0200 <Guest13> you are saying that to get x in (f -> x) = y you need to call f on y
2024-05-16 19:09:17 +0200 <ski> well, we're also avoiding wrapping the whole `\case ...' in brackets. so when we break that over multiple lines in the source file, we don't need a closing bracket at the end, that may look a bit unclear which opening bracket it is matching, multiple lines up
2024-05-16 19:09:35 +0200 <ski> it would perhaps be even more fun, if we could write
2024-05-16 19:09:48 +0200 <ski> (memoArray (0,n) -> fib) 0 = 0
2024-05-16 19:09:51 +0200 <ski> (memoArray (0,n) -> fib) 1 = 1
2024-05-16 19:09:55 +0200 <ski> (memoArray (0,n) -> fib) n = fib (n-1) + fib (n-2)
2024-05-16 19:10:24 +0200 <Guest13> what does memoArray do again?
2024-05-16 19:10:25 +0200 <ski> .. but my unintended usage of view patterns, above, doesn't support this style of defining `fib'
2024-05-16 19:10:45 +0200 <Guest13> ! . tabulate
2024-05-16 19:10:47 +0200 <ski> (and .. it might be unclear whether there'd be only a single call to `memoArray' here, or three separate calls)
2024-05-16 19:11:19 +0200 <ski> `tabulate (0,n)' converts the function to an array that lists the results of the function, for each input in the range `(0,n)'
2024-05-16 19:11:30 +0200 <ski> `(!)' converts back from that array, to the function
2024-05-16 19:11:42 +0200 <Guest13> ok ok
2024-05-16 19:12:03 +0200 <ski> so, `(!) . tabulate (0,n)' allocates a single array, and makes a new function that, when called, will indirect through this array before calling the original function
2024-05-16 19:12:26 +0200ft(~ft@p508db8fc.dip0.t-ipconnect.de)
2024-05-16 19:12:28 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi)
2024-05-16 19:12:43 +0200 <ski> btw .. note that we should not use
2024-05-16 19:13:07 +0200 <ski> fib n = memoArray (0,n) fib (n-1) + memoArray (0,n) fib (n-2)
2024-05-16 19:13:08 +0200 <ski> or
2024-05-16 19:13:18 +0200 <ski> fib n = fib' (n-1) + fib' (n-2)
2024-05-16 19:13:20 +0200 <ski> where
2024-05-16 19:13:32 +0200 <ski> fib' = memoArray (0,n) fib
2024-05-16 19:13:35 +0200 <Guest13> because these are two different arrays
2024-05-16 19:13:50 +0200 <ski> since this would call `memoArray' once for each recursive call, allocating a new array on each recursive call
2024-05-16 19:13:58 +0200 <Guest13> ok I see
2024-05-16 19:14:01 +0200 <ski> we only want to allocate an array on the initial/top call
2024-05-16 19:14:15 +0200 <Guest13> so defining it as f -> x = y is good
2024-05-16 19:14:40 +0200 <ski> well .. it does look a bit neat
2024-05-16 19:14:56 +0200 <ski> of course, there's nothing wrong with naming the intermediate array cache, as well
2024-05-16 19:14:58 +0200patrl(~patrl@user/patrl) (Remote host closed the connection)
2024-05-16 19:16:01 +0200 <Guest13> I gotta go cook dinner, but I will let you know how the problem goes
2024-05-16 19:16:11 +0200 <Guest13> I think I understand it fairly well know
2024-05-16 19:16:12 +0200 <Guest13> now
2024-05-16 19:16:41 +0200 <ski> but i suppose one reason i played around with view patterns here (or rather, a more complcated function, involving a two-dimensional array, for matching a pattern string inside a text string), was to try to keep the memoized code version as close as possible to the original, non-memoized code
2024-05-16 19:19:54 +0200 <Guest13> so you can reuse the non memoized code?
2024-05-16 19:20:06 +0200 <Guest13> or separate the logic
2024-05-16 19:20:08 +0200 <ski> no, not really
2024-05-16 19:20:26 +0200 <Guest13> so it is clear where the memoization happens and where the recursion happens
2024-05-16 19:20:28 +0200 <ski> but i localize the differences to a minimal numer of places
2024-05-16 19:20:49 +0200 <ski> well .. that too. but it's not that unclear for the more elaborated versions, either
2024-05-16 19:21:23 +0200 <ski> it's more to clearly seee that you haven't accidentally introduced some bug change in the memoized version
2024-05-16 19:22:02 +0200 <ski> and also to easily be able to ignore the memoization when reading (when thinking about what it does, without concern for the memoization optimiztion)
2024-05-16 19:22:59 +0200 <Guest13> (y) thank you for the help! ill see if I can let you know how my solution goes, and maybe send it to this channel at some point
2024-05-16 19:23:00 +0200 <ski> because i keep the recursive calls `fib (n-1) + fib (n-2)', rather than replacing them with array lookups `fibs ! (n-1) + fib ! (n-2)'
2024-05-16 19:23:23 +0200 <Guest13> its much cleaner like that
2024-05-16 19:23:32 +0200 <ski> well ..
2024-05-16 19:23:42 +0200 <ski> .. you should use whichever version is clearer to you
2024-05-16 19:24:11 +0200 <ski> if you think the view pattern version is too clever, or obscure, then you probably shouldn't use it
2024-05-16 19:24:47 +0200billchenchina(~billchenc@103.152.35.21) (Ping timeout: 256 seconds)
2024-05-16 19:43:19 +0200Guest13(~Guest13@cpc93370-hers8-2-0-cust590.6-3.cable.virginm.net) (Ping timeout: 250 seconds)
2024-05-16 19:44:48 +0200halloy9814(~halloy981@103.144.93.164)
2024-05-16 19:45:09 +0200halloy9814suvid
2024-05-16 19:45:15 +0200 <suvid> hi
2024-05-16 19:46:28 +0200suvid(~halloy981@103.144.93.164) (Remote host closed the connection)
2024-05-16 19:50:05 +0200ph88(~ph88@2a02:8109:9e26:c800:801e:36ad:9367:33b9)
2024-05-16 19:51:46 +0200jcarpenter2(~lol@2603:3016:1e01:b940:892b:2549:5c20:9c9b)
2024-05-16 19:54:40 +0200euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2024-05-16 20:00:18 +0200euphores(~SASL_euph@user/euphores)
2024-05-16 20:02:59 +0200polyphem(~rod@p4fc2c1da.dip0.t-ipconnect.de)
2024-05-16 20:06:40 +0200suvid(~suvid@103.144.93.164)
2024-05-16 20:07:22 +0200 <suvid> hi
2024-05-16 20:08:05 +0200xnyhps(~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (Ping timeout: 240 seconds)
2024-05-16 20:08:19 +0200xnyhps(~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288)
2024-05-16 20:10:21 +0200random-jellyfish(~developer@user/random-jellyfish) (Ping timeout: 255 seconds)
2024-05-16 20:11:42 +0200suvid(~suvid@103.144.93.164) (Remote host closed the connection)
2024-05-16 20:14:30 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-16 20:24:31 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2024-05-16 20:38:55 +0200jjnkn(~jjnkn@46.150.73.222.kyiv.volia.net) (Remote host closed the connection)
2024-05-16 20:50:06 +0200philopsos(~caecilius@user/philopsos)
2024-05-16 20:50:34 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 20:54:41 +0200danse-nr3(~danse-nr3@151.47.136.223)
2024-05-16 20:55:36 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-16 20:56:38 +0200sawilagar(~sawilagar@user/sawilagar) (Ping timeout: 256 seconds)
2024-05-16 21:12:36 +0200sprout(~quassel@84-80-106-227.fixed.kpn.net) (Read error: Connection reset by peer)
2024-05-16 21:12:49 +0200sprout(~quassel@2a02-a448-3a80-0-4d25-a983-a243-75e.fixed6.kpn.net)
2024-05-16 21:13:28 +0200puke(~puke@user/puke) (Remote host closed the connection)
2024-05-16 21:13:41 +0200bsima(~bsima@2604:a880:400:d0::19f1:7001) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-16 21:14:01 +0200MironZ(~MironZ@nat-infra.ehlab.uk) (Quit: Ping timeout (120 seconds))
2024-05-16 21:14:13 +0200bsima(~bsima@143.198.118.179)
2024-05-16 21:14:20 +0200MironZ(~MironZ@nat-infra.ehlab.uk)
2024-05-16 21:14:25 +0200sprout(~quassel@2a02-a448-3a80-0-4d25-a983-a243-75e.fixed6.kpn.net) (Read error: Connection reset by peer)
2024-05-16 21:14:35 +0200titibandit(~user@user/titibandit) (Read error: Connection reset by peer)
2024-05-16 21:15:01 +0200Athas(athas@sigkill.dk) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-16 21:15:02 +0200poscat(~poscat@user/poscat) (Quit: Bye)
2024-05-16 21:15:09 +0200titibandit(~user@user/titibandit)
2024-05-16 21:15:22 +0200poscat(~poscat@user/poscat)
2024-05-16 21:15:28 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001) (Read error: Connection reset by peer)
2024-05-16 21:15:30 +0200jinsun_(~jinsun@user/jinsun)
2024-05-16 21:15:34 +0200driib3(~driib@vmi931078.contaboserver.net)
2024-05-16 21:15:35 +0200dagi85299(~dagit@24.21.226.72)
2024-05-16 21:15:42 +0200Riviera_(Riviera@user/riviera)
2024-05-16 21:15:47 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001)
2024-05-16 21:15:55 +0200Riviera(Riviera@user/riviera) (Killed (NickServ (GHOST command used by Riviera_)))
2024-05-16 21:15:57 +0200caubert(~caubert@user/caubert) (Read error: Connection reset by peer)
2024-05-16 21:15:58 +0200fr33domlover(~fr33domlo@towards.vision) (Quit: Ping timeout (120 seconds))
2024-05-16 21:15:59 +0200puke(~puke@user/puke)
2024-05-16 21:16:05 +0200Riviera_Riviera
2024-05-16 21:16:06 +0200acidjnk_new(~acidjnk@p5dd87bdf.dip0.t-ipconnect.de)
2024-05-16 21:16:07 +0200sprout(~quassel@84-80-106-227.fixed.kpn.net)
2024-05-16 21:16:23 +0200remexre_(~remexre@user/remexre)
2024-05-16 21:16:28 +0200Athas(athas@2a01:7c8:aaac:1cf:a4c:e787:a74:d356)
2024-05-16 21:16:35 +0200bsima1(9d7e39c8ad@2a03:6000:1812:100::dd) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200fgaz_(1ff9197ed6@2a03:6000:1812:100::11ea) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200jleightcap(7bc4014b62@user/jleightcap) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200brettgilio(a35ba67324@2a03:6000:1812:100::260) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200cpli(77fc530071@2a03:6000:1812:100::252) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200whereiseveryone(206ba86c98@2a03:6000:1812:100::2e4) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200Ankhers(e99e97ef8e@2a03:6000:1812:100::2a2) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200kuruczgy(55b66dd3ae@2a03:6000:1812:100::127f) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200henrytill(e0180937c3@2a03:6000:1812:100::e8c) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200JoelMcCracken(5ea8252fbb@2a03:6000:1812:100::10e3) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200chaitlatte0(ea29c0bb16@user/chaitlatte0) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200rselim(ce261f06ff@user/milesrout) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200eso(a0662dfd5e@2a03:6000:1812:100::1266) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200lukec(9dfd4d094e@2a03:6000:1812:100::10e) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200evanrelf(3addc196af@2a03:6000:1812:100::f0) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200jmcantrell(644f1bed9a@user/jmcantrell) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200shreyasminocha(51fdc93eda@user/shreyasminocha) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200samhh(7569f027cf@2a03:6000:1812:100::e4) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200probie(cc0b34050a@user/probie) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200aniketd(32aa4844cd@2a03:6000:1812:100::dcb) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200akspecs(00cc8321af@sourcehut/user/akspecs) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200fluffyballoon(45ce440a48@2a03:6000:1812:100::e2) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200fn_lumi(3d621153a5@2a03:6000:1812:100::df7) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200arcadewise(52968ed80d@2a03:6000:1812:100::3df) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200filwisher(2e6936c793@2a03:6000:1812:100::170) (Read error: Connection reset by peer)
2024-05-16 21:16:35 +0200samhh_samhh
2024-05-16 21:16:37 +0200ursa-major(114efe6c39@2a03:6000:1812:100::11f3) (Read error: Connection reset by peer)
2024-05-16 21:16:40 +0200mht-wtf(~mht@2a03:b0c0:3:e0::1e2:c001) (Ping timeout: 246 seconds)
2024-05-16 21:16:42 +0200chessai(sid225296@id-225296.lymington.irccloud.com) (Read error: Connection reset by peer)
2024-05-16 21:16:43 +0200systemfault(sid267009@about/typescript/member/systemfault) (Read error: Connection reset by peer)
2024-05-16 21:16:46 +0200integral(sid296274@user/integral) (Read error: Connection reset by peer)
2024-05-16 21:16:56 +0200driib(~driib@vmi931078.contaboserver.net) (Read error: Connection reset by peer)
2024-05-16 21:16:57 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Ping timeout: 268 seconds)
2024-05-16 21:16:57 +0200xsarnik(xsarnik@lounge.fi.muni.cz) (Ping timeout: 268 seconds)
2024-05-16 21:17:02 +0200aforemny_(~aforemny@2001:9e8:6cd4:e700:d233:e5e6:582d:855) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-16 21:17:34 +0200xstill_(xstill@fimu/xstill) (Ping timeout: 268 seconds)
2024-05-16 21:17:35 +0200lambdap2371(~lambdap@static.167.190.119.168.clients.your-server.de) (Quit: Ping timeout (120 seconds))
2024-05-16 21:17:43 +0200bsima1(9d7e39c8ad@2a03:6000:1812:100::dd)
2024-05-16 21:17:44 +0200fgaz_(1ff9197ed6@2a03:6000:1812:100::11ea)
2024-05-16 21:17:44 +0200lukec(9dfd4d094e@2a03:6000:1812:100::10e)
2024-05-16 21:17:44 +0200filwisher(2e6936c793@2a03:6000:1812:100::170)
2024-05-16 21:17:44 +0200brettgilio(a35ba67324@2a03:6000:1812:100::260)
2024-05-16 21:17:44 +0200fluffyballoon(45ce440a48@2a03:6000:1812:100::e2)
2024-05-16 21:17:44 +0200fn_lumi(3d621153a5@2a03:6000:1812:100::df7)
2024-05-16 21:17:44 +0200shreyasminocha(51fdc93eda@user/shreyasminocha)
2024-05-16 21:17:44 +0200aniketd(32aa4844cd@2a03:6000:1812:100::dcb)
2024-05-16 21:17:44 +0200eso(a0662dfd5e@2a03:6000:1812:100::1266)
2024-05-16 21:17:44 +0200jleightcap(7bc4014b62@user/jleightcap)
2024-05-16 21:17:44 +0200xigua_(~xigua@user/xigua)
2024-05-16 21:17:44 +0200haritz(~hrtz@user/haritz) (Remote host closed the connection)
2024-05-16 21:17:44 +0200econo__(uid147250@id-147250.tinside.irccloud.com)
2024-05-16 21:17:44 +0200chessai_(sid225296@id-225296.lymington.irccloud.com)
2024-05-16 21:17:44 +0200aspen__(sid449115@id-449115.helmsley.irccloud.com)
2024-05-16 21:17:44 +0200systemfault_(sid267009@about/typescript/member/systemfault)
2024-05-16 21:17:44 +0200 <ski> whee
2024-05-16 21:17:44 +0200EvanR_(~EvanR@user/evanr)
2024-05-16 21:17:44 +0200haritz(~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220)
2024-05-16 21:17:44 +0200Pent(sid313808@id-313808.lymington.irccloud.com) (Read error: Connection reset by peer)
2024-05-16 21:17:44 +0200Boarders____(sid425905@id-425905.lymington.irccloud.com)
2024-05-16 21:17:44 +0200integral_(sid296274@user/integral)
2024-05-16 21:17:44 +0200dagit(~dagit@2001:558:6025:38:71c6:9d58:7252:8976) (Remote host closed the connection)
2024-05-16 21:17:44 +0200dy_(sid3438@user/dy)
2024-05-16 21:17:44 +0200amir_(sid22336@user/amir)
2024-05-16 21:17:44 +0200hugo(znc@quicksilver.lysator.liu.se) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
2024-05-16 21:17:44 +0200scav(sid309693@user/scav) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200h2t(~h2t@user/h2t) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200_0xa_(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Quit: ZNC 1.7.5+deb4 - https://znc.in)
2024-05-16 21:17:44 +0200pierrot(~pi@user/pierrot) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200joeyh(joeyh@kitenet.net) (Quit: ZNC 1.8.2+deb3+b4 - https://znc.in)
2024-05-16 21:17:44 +0200darkling(~darkling@2001-ba8-1f1-f0e6-0-0-0-2.autov6rev.bitfolk.space) (Remote host closed the connection)
2024-05-16 21:17:44 +0200hugo(znc@quicksilver.lysator.liu.se)
2024-05-16 21:17:44 +0200h2t_(~h2t@user/h2t)
2024-05-16 21:17:44 +0200darksatanic(~darkling@savella.carfax.org.uk)
2024-05-16 21:17:44 +0200rvalue(~rvalue@user/rvalue) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200yandere(sid467876@id-467876.ilkley.irccloud.com) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200carter(sid14827@id-14827.helmsley.irccloud.com) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200edwardk(sid47016@haskell/developer/edwardk) (Ping timeout: 256 seconds)
2024-05-16 21:17:44 +0200yandere_(sid467876@id-467876.ilkley.irccloud.com)
2024-05-16 21:17:44 +0200alanz_(sid110616@id-110616.uxbridge.irccloud.com)
2024-05-16 21:17:44 +0200nek0(~nek0@user/nek0) (Quit: Ping timeout (120 seconds))
2024-05-16 21:17:44 +0200PotatoGim(sid99505@id-99505.lymington.irccloud.com) (Read error: Connection reset by peer)
2024-05-16 21:17:44 +0200Boarders___(sid425905@id-425905.lymington.irccloud.com) (Read error: Connection reset by peer)
2024-05-16 21:17:44 +0200amir(sid22336@user/amir) (Read error: Connection reset by peer)
2024-05-16 21:17:44 +0200bw_____(sid2730@id-2730.ilkley.irccloud.com) (Read error: Connection reset by peer)
2024-05-16 21:17:44 +0200mauke(~mauke@user/mauke) (Ping timeout: 246 seconds)
2024-05-16 21:17:44 +0200cln_(cln@wtf.cx) (Ping timeout: 246 seconds)
2024-05-16 21:17:44 +0200amir_amir
2024-05-16 21:17:44 +0200alanz(sid110616@id-110616.uxbridge.irccloud.com) (Ping timeout: 246 seconds)
2024-05-16 21:17:44 +0200driib3driib
2024-05-16 21:17:44 +0200chessai_chessai
2024-05-16 21:17:44 +0200systemfault_systemfault
2024-05-16 21:17:44 +0200econo__econo_
2024-05-16 21:17:44 +0200integral_integral
2024-05-16 21:17:44 +0200gaze___(sid387101@id-387101.helmsley.irccloud.com)
2024-05-16 21:17:44 +0200edwardk(sid47016@haskell/developer/edwardk)
2024-05-16 21:17:44 +0200alanz_alanz
2024-05-16 21:17:50 +0200Fangs_(sid141280@id-141280.hampstead.irccloud.com)
2024-05-16 21:17:52 +0200remexre(~remexre@user/remexre) (Ping timeout: 268 seconds)
2024-05-16 21:17:54 +0200nek0(~nek0@2a01:4f8:222:2b41::12)
2024-05-16 21:17:54 +0200nek0(~nek0@2a01:4f8:222:2b41::12) (Changing host)
2024-05-16 21:17:54 +0200nek0(~nek0@user/nek0)
2024-05-16 21:17:56 +0200Pent(sid313808@id-313808.lymington.irccloud.com)
2024-05-16 21:17:57 +0200remexre_remexre
2024-05-16 21:18:00 +0200dmj`_(sid72307@id-72307.hampstead.irccloud.com)
2024-05-16 21:18:03 +0200PotatoGim_(sid99505@id-99505.lymington.irccloud.com)
2024-05-16 21:18:04 +0200Pozyomka(~pyon@user/pyon) (Ping timeout: 246 seconds)
2024-05-16 21:18:04 +0200riatre(~quassel@2001:310:6000:f::5198:1) (Ping timeout: 246 seconds)
2024-05-16 21:18:07 +0200carter_(sid14827@id-14827.helmsley.irccloud.com)
2024-05-16 21:18:07 +0200aspen(sid449115@id-449115.helmsley.irccloud.com) (Ping timeout: 256 seconds)
2024-05-16 21:18:07 +0200landonf(landonf@mac68k.info) (Ping timeout: 256 seconds)
2024-05-16 21:18:08 +0200coldtom(~coldtom@coldrick.cc) (Quit: Ping timeout (120 seconds))
2024-05-16 21:18:08 +0200aspen__aspen
2024-05-16 21:18:08 +0200Goodbye_Vincent(cyvahl@freakshells.net) (Quit: Ping timeout (120 seconds))
2024-05-16 21:18:09 +0200rvalue(~rvalue@user/rvalue)
2024-05-16 21:18:10 +0200bw_____(sid2730@id-2730.ilkley.irccloud.com)
2024-05-16 21:18:11 +0200xigua(~xigua@user/xigua) (Ping timeout: 268 seconds)
2024-05-16 21:18:11 +0200dmj`(sid72307@id-72307.hampstead.irccloud.com) (Ping timeout: 268 seconds)
2024-05-16 21:18:11 +0200xigua_xigua
2024-05-16 21:18:11 +0200dmj`_dmj`
2024-05-16 21:18:18 +0200xsarnik(xsarnik@lounge.fi.muni.cz)
2024-05-16 21:18:19 +0200coldtom(~coldtom@coldrick.cc)
2024-05-16 21:18:20 +0200aforemny(~aforemny@2001:9e8:6cd4:e700:d233:e5e6:582d:855)
2024-05-16 21:18:22 +0200Pozyomka(~pyon@user/pyon)
2024-05-16 21:18:23 +0200xstill_(xstill@fimu/xstill)
2024-05-16 21:18:25 +0200Goodbye_Vincent(cyvahl@freakshells.net)
2024-05-16 21:18:25 +0200lambdap2371(~lambdap@static.167.190.119.168.clients.your-server.de)
2024-05-16 21:18:29 +0200EvanR(~EvanR@user/evanr) (Ping timeout: 268 seconds)
2024-05-16 21:18:31 +0200mht-wtf(~mht@mht.wtf)
2024-05-16 21:18:37 +0200scav(sid309693@user/scav)
2024-05-16 21:18:39 +0200fr33domlover(~fr33domlo@towards.vision)
2024-05-16 21:18:45 +0200whereiseveryone(206ba86c98@2a03:6000:1812:100::2e4)
2024-05-16 21:18:46 +0200ursa-major(114efe6c39@2a03:6000:1812:100::11f3)
2024-05-16 21:18:48 +0200acidjnk(~acidjnk@p200300d6e714dc32b43b4fa4bda78a3a.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2024-05-16 21:18:48 +0200remmie(ianremsen@tilde.team) (Ping timeout: 268 seconds)
2024-05-16 21:18:48 +0200dy(sid3438@user/dy) (Ping timeout: 268 seconds)
2024-05-16 21:18:48 +0200gaze__(sid387101@id-387101.helmsley.irccloud.com) (Ping timeout: 268 seconds)
2024-05-16 21:18:48 +0200Fangs(sid141280@id-141280.hampstead.irccloud.com) (Ping timeout: 268 seconds)
2024-05-16 21:18:48 +0200haritz(~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host)
2024-05-16 21:18:48 +0200haritz(~hrtz@user/haritz)
2024-05-16 21:18:48 +0200gaze___gaze__
2024-05-16 21:18:48 +0200dy_dy
2024-05-16 21:18:48 +0200Fangs_Fangs
2024-05-16 21:18:51 +0200arcadewise(52968ed80d@2a03:6000:1812:100::3df)
2024-05-16 21:18:53 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 240 seconds)
2024-05-16 21:18:53 +0200_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc)
2024-05-16 21:18:53 +0200_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Changing host)
2024-05-16 21:18:53 +0200_0xa(~user@user/0xa/x-3134607)
2024-05-16 21:18:55 +0200mauke(~mauke@user/mauke)
2024-05-16 21:18:56 +0200rselim(ce261f06ff@user/milesrout)
2024-05-16 21:18:58 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Quit: So long and thanks for all the fish)
2024-05-16 21:18:58 +0200Ankhers(e99e97ef8e@2a03:6000:1812:100::2a2)
2024-05-16 21:19:04 +0200riatre(~quassel@2001:310:6000:f::5198:1)
2024-05-16 21:19:05 +0200cpli(77fc530071@2a03:6000:1812:100::252)
2024-05-16 21:19:05 +0200akspecs(00cc8321af@sourcehut/user/akspecs)
2024-05-16 21:19:10 +0200jmcantrell(644f1bed9a@user/jmcantrell)
2024-05-16 21:19:11 +0200mhatta(~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection)
2024-05-16 21:19:11 +0200kuruczgy(55b66dd3ae@2a03:6000:1812:100::127f)
2024-05-16 21:19:13 +0200henrytill(e0180937c3@2a03:6000:1812:100::e8c)
2024-05-16 21:19:14 +0200joeyh(~joeyh@kitenet.net)
2024-05-16 21:19:19 +0200caubert(~caubert@user/caubert)
2024-05-16 21:19:19 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2024-05-16 21:19:22 +0200samhh_(7569f027cf@2a03:6000:1812:100::e4)
2024-05-16 21:19:23 +0200mhatta(~mhatta@www21123ui.sakura.ne.jp)
2024-05-16 21:19:25 +0200JoelMcCracken(5ea8252fbb@2a03:6000:1812:100::10e3)
2024-05-16 21:19:26 +0200manwithluck(~manwithlu@149.102.244.20) (Remote host closed the connection)
2024-05-16 21:19:27 +0200probie(cc0b34050a@user/probie)
2024-05-16 21:19:27 +0200Noinia(~Frank@77-162-168-71.fixed.kpn.net) (Read error: Connection reset by peer)
2024-05-16 21:19:28 +0200Dykam(Dykam@dykam.nl) (Remote host closed the connection)
2024-05-16 21:19:29 +0200cln_(cln@wtf.cx)
2024-05-16 21:19:37 +0200chaitlatte0(ea29c0bb16@user/chaitlatte0)
2024-05-16 21:19:41 +0200Noinia(~Frank@77-162-168-71.fixed.kpn.net)
2024-05-16 21:19:41 +0200evanrelf(3addc196af@2a03:6000:1812:100::f0)
2024-05-16 21:20:35 +0200pierrot(~pi@user/pierrot)
2024-05-16 21:20:37 +0200Dykam(Dykam@dykam.nl)
2024-05-16 21:20:50 +0200darksatanicdarkling
2024-05-16 21:20:57 +0200APic(apic@apic.name) (Ping timeout: 268 seconds)
2024-05-16 21:22:11 +0200APic(apic@apic.name)
2024-05-16 21:22:53 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 240 seconds)
2024-05-16 21:23:09 +0200landonf(landonf@mac68k.info)
2024-05-16 21:32:00 +0200bsima(~bsima@143.198.118.179) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-16 21:32:01 +0200remmie(ianremsen@tilde.team)
2024-05-16 21:32:34 +0200bsima(~bsima@2604:a880:400:d0::19f1:7001)
2024-05-16 21:32:54 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Quit: oo_miguel)
2024-05-16 21:35:36 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds)
2024-05-16 21:39:25 +0200sudden(~cat@user/sudden) (Ping timeout: 272 seconds)
2024-05-16 21:44:08 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-16 21:50:14 +0200immae(~immae@2a01:4f8:141:53e7::) (Quit: WeeChat 3.3)
2024-05-16 21:51:04 +0200sudden(~cat@user/sudden)
2024-05-16 21:51:58 +0200immae(~immae@2a01:4f8:141:53e7::)
2024-05-16 21:52:22 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 246 seconds)
2024-05-16 21:56:36 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2024-05-16 21:57:47 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds)
2024-05-16 21:58:57 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 22:00:54 +0200L29Ah(~L29Ah@wikipedia/L29Ah) ()
2024-05-16 22:02:23 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-16 22:08:56 +0200danse-nr3(~danse-nr3@151.47.136.223) (Read error: Connection reset by peer)
2024-05-16 22:09:06 +0200danse-nr3(~danse-nr3@rm-19-5-133.service.infuturo.it)
2024-05-16 22:10:15 +0200talismanick(~user@2601:644:937c:ed10::ae5)
2024-05-16 22:10:44 +0200kadir(~kadir@88.251.51.100)
2024-05-16 22:13:45 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2024-05-16 22:22:28 +0200 <talismanick> Why is there no `Monoid e -> Alternative (Either e)` instance?
2024-05-16 22:22:31 +0200 <talismanick> Is it something to do with kind, as in biasing a choice so it then acts "as if" it were `* -> *` like `Maybe` breaks some law I haven't thought of yet?
2024-05-16 22:24:35 +0200 <talismanick> for context, I'm playing around with a package promising bidirectional parsing <-> prettyprinting on the basis of monadic profunctoriality, but it's bitrotted as GHC has evolved
2024-05-16 22:25:29 +0200 <ski> hmm .. i see `Monoid e => Monoid (Validation e a)'
2024-05-16 22:25:39 +0200 <ski> (doesn't seem to be one for `Alternative', though)
2024-05-16 22:26:12 +0200 <talismanick> relaxing the <4.13 constraint went smoothly, except that newtype-deriving the all-important Alternative and MonadPlus failed with the error "no instance for MonadPlus (Either String)"
2024-05-16 22:27:04 +0200 <talismanick> (deriving these instances for the reversible Printer type, that is)
2024-05-16 22:27:50 +0200 <glguy> so this? instance Monoid e => Alternative (Either e) where empty = Left mempty; Right x <|> _ = Right x; _ <|> Right x = Right x; Left x <|> Left y = Left (x <> y)
2024-05-16 22:27:51 +0200 <talismanick> ski: do you think I maybe need to add some newtype wrappers using Ap to lift Monoid to Alternative?
2024-05-16 22:28:41 +0200 <talismanick> glguy: yeah, that looks right... am I missing something obvious about why this is wrong?
2024-05-16 22:30:44 +0200pavonia(~user@user/siracusa)
2024-05-16 22:31:00 +0200 <talismanick> there is https://github.com/ekmett/bifunctors/issues/126 in the works, which might be enough
2024-05-16 22:31:45 +0200 <talismanick> (if we get Bialternative and it lets us do what we wanted from Alternative/MonadPlus)
2024-05-16 22:32:00 +0200 <ncf> https://gitlab.haskell.org/ghc/ghc/-/issues/9588
2024-05-16 22:33:56 +0200 <glguy> I think there are just too many options for there to be a sensible implementation. Picking one arbitrarily will just lead to surprise bugs
2024-05-16 22:35:34 +0200EvanR_EvanR
2024-05-16 22:35:53 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-16 22:36:53 +0200 <talismanick> so, the right solution is probably to tear out Either altogether and use Error from transformers?
2024-05-16 22:37:24 +0200 <talismanick> I mean, I guess that's a win for convenient typeclass polymorphism anyways
2024-05-16 22:38:43 +0200 <talismanick> err, Except
2024-05-16 22:38:53 +0200 <glguy> The nice solution is to make a new datatype with documented behaviors you rely on. Piecing together behaviors from generic types can be nice in a pinch but it's challenging for the future reader to know what properties of the generic thing are being relied upon later
2024-05-16 22:40:50 +0200califax(~califax@user/califx) (Ping timeout: 260 seconds)
2024-05-16 22:40:50 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds)
2024-05-16 22:41:01 +0200 <talismanick> if anything, that's all the stronger an argument for getting rid of (Either String) and using the transformers package, given that a homegrown error type is liable to be a source of problems itself
2024-05-16 22:41:03 +0200califax_(~califax@user/califx)
2024-05-16 22:42:07 +0200califax_califax
2024-05-16 22:42:09 +0200 <talismanick> I mean, say what you will about transformer stacks with tons of parameters, lens signatures, etc, but I feel like Except is universally understood
2024-05-16 22:42:15 +0200 <glguy> If I'm using transformers it's behind a newtype
2024-05-16 22:42:21 +0200 <talismanick> fair enough
2024-05-16 22:44:24 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2024-05-16 22:47:20 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-16 22:49:07 +0200 <ncf> i'm not sure there are that many options for Alternative (Either e) tbh
2024-05-16 22:49:42 +0200 <ncf> AFAICT you only have to choose a monoid for e and whether to keep the left or the right in Right a <|> Right b
2024-05-16 22:50:15 +0200 <ncf> and it's not like there's a canonical monoid on every type (as opposed to the First semigroup), so you just make it a Monoid e constraint
2024-05-16 22:51:00 +0200danse-nr3(~danse-nr3@rm-19-5-133.service.infuturo.it) (Ping timeout: 255 seconds)
2024-05-16 22:52:36 +0200kadir(~kadir@88.251.51.100) (Quit: WeeChat 4.2.2)
2024-05-16 22:54:53 +0200danza(~francesco@rm-19-5-133.service.infuturo.it)
2024-05-16 22:58:09 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-16 22:59:13 +0200danza(~francesco@rm-19-5-133.service.infuturo.it) (Ping timeout: 246 seconds)
2024-05-16 23:02:19 +0200johnw(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2024-05-16 23:02:45 +0200johnw(~johnw@69.62.242.138)
2024-05-16 23:04:37 +0200mei(~mei@user/mei)
2024-05-16 23:10:13 +0200ph88(~ph88@2a02:8109:9e26:c800:801e:36ad:9367:33b9) (Remote host closed the connection)
2024-05-16 23:10:37 +0200m257(~maaz@bras-base-hspron0502w-grc-15-174-92-92-146.dsl.bell.ca)
2024-05-16 23:13:46 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2024-05-16 23:14:07 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 268 seconds)
2024-05-16 23:15:05 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl)
2024-05-16 23:16:11 +0200polyphem(~rod@p4fc2c1da.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2024-05-16 23:17:20 +0200 <talismanick> ncf: isn't Alternative generally left-biased on mutual success? (pick `Right a` and bail)
2024-05-16 23:18:21 +0200 <talismanick> and, why isn't `Monoid e => Alternative (Either e)` in base, then? That seems like a reasonably conservative-but-useful addition
2024-05-16 23:18:23 +0200 <ncf> i mean Alternative [] isn't left-biased
2024-05-16 23:18:35 +0200 <talismanick> oh, true
2024-05-16 23:18:38 +0200 <ncf> but Either can't just concatenate the Rights, since it has to work parametrically in a
2024-05-16 23:18:54 +0200philopsos1(~caecilius@user/philopsos)
2024-05-16 23:19:07 +0200 <ncf> so it has to pick one, and left seems like the favoured one because english
2024-05-16 23:20:12 +0200 <talismanick> ...but it's not unlawful, and there's precedent for English bias anyways
2024-05-16 23:21:04 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-16 23:21:14 +0200 <ncf> i mean if you want to convince the Core Libraries Committee that this is the one true God-intended instance for Alternative (Either e), go for it
2024-05-16 23:21:40 +0200 <ncf> from experience this will not be an easy task
2024-05-16 23:27:20 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-16 23:31:46 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds)
2024-05-16 23:54:28 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2024-05-16 23:58:24 +0200fendor(~fendor@2a02:8388:1605:ce00:24e2:c141:1f86:a346) (Remote host closed the connection)