IRCBrowse

2023/12/14

2023-12-14 00:04:44 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-12-14 00:10:03 +0100xdminsy(~xdminsy@117.147.70.160)
2023-12-14 00:13:13 +0100CiaoSen(~Jura@2a05:5800:283:6400:ca4b:d6ff:fec1:99da) (Ping timeout: 255 seconds)
2023-12-14 00:14:37 +0100zetef(~quassel@5.2.182.98) (Remote host closed the connection)
2023-12-14 00:23:41 +0100alp_(~alp@2001:861:e3d6:8f80:39e7:96a1:5110:7e1) (Ping timeout: 256 seconds)
2023-12-14 00:24:41 +0100bratwurst(~blaadsfa@2604:3d09:2083:a200:216:3eff:fe5a:a1f8) (Quit: Leaving)
2023-12-14 00:31:40 +0100YoungFrog(~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) (Ping timeout: 256 seconds)
2023-12-14 00:34:45 +0100YoungFrog(~youngfrog@2a02:a03f:ca07:f900:b851:fee:89b5:e238)
2023-12-14 00:35:53 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-12-14 00:35:54 +0100xdminsy(~xdminsy@117.147.70.160) (Quit: Konversation terminated!)
2023-12-14 00:36:14 +0100maars(uid160334@id-160334.uxbridge.irccloud.com)
2023-12-14 00:36:20 +0100xdminsy(~xdminsy@117.147.70.160)
2023-12-14 00:36:57 +0100fendor(~fendor@2a02:8388:1605:d100:6189:ab4:a618:faec) (Remote host closed the connection)
2023-12-14 00:38:59 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2023-12-14 00:49:52 +0100bratwurst(~blaadsfa@2604:3d09:2083:a200:216:3eff:fe5a:a1f8)
2023-12-14 00:50:03 +0100bratwurst(~blaadsfa@2604:3d09:2083:a200:216:3eff:fe5a:a1f8) (Client Quit)
2023-12-14 00:52:12 +0100bratwurst(~blaadsfa@2604:3d09:2083:a200:216:3eff:fe5a:a1f8)
2023-12-14 00:52:44 +0100bratwurst(~blaadsfa@2604:3d09:2083:a200:216:3eff:fe5a:a1f8) (Client Quit)
2023-12-14 00:57:00 +0100mobivme(~mobivme@112.201.111.217) (Read error: Connection reset by peer)
2023-12-14 01:00:37 +0100mobivme(~mobivme@112.201.111.217)
2023-12-14 01:03:03 +0100Sgeo(~Sgeo@user/sgeo)
2023-12-14 01:07:04 +0100acidjnk_new(~acidjnk@p200300d6e72b9302dc7c5b25c70fbc45.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-12-14 01:13:23 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 260 seconds)
2023-12-14 01:13:35 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 01:22:16 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 276 seconds)
2023-12-14 01:25:59 +0100_xor(~xor@72.49.195.41) (Read error: Connection reset by peer)
2023-12-14 01:26:54 +0100_xor(~xor@72.49.195.41)
2023-12-14 01:29:14 +0100myxos(~myxos@065-028-251-121.inf.spectrum.com) (Quit: myxos)
2023-12-14 01:37:55 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl)
2023-12-14 01:41:22 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 256 seconds)
2023-12-14 01:45:33 +0100_xor(~xor@72.49.195.41) (Read error: Connection reset by peer)
2023-12-14 01:47:51 +0100_xor(~xor@72.49.195.41)
2023-12-14 01:51:18 +0100_xor(~xor@72.49.195.41) (Read error: Connection reset by peer)
2023-12-14 01:53:35 +0100_xor(~xor@72.49.195.41)
2023-12-14 01:58:01 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds)
2023-12-14 02:02:16 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 02:03:51 +0100califax(~califax@user/califx)
2023-12-14 02:13:14 +0100TonyStone(~TonyStone@074-076-057-186.res.spectrum.com)
2023-12-14 02:16:58 +0100myxos(~myxos@065-028-251-121.inf.spectrum.com)
2023-12-14 02:35:02 +0100Square2(~Square4@user/square)
2023-12-14 02:37:51 +0100Square(~Square@user/square) (Ping timeout: 252 seconds)
2023-12-14 02:41:29 +0100Joao003(~Joao003@190.108.99.230) (Quit: Bye!)
2023-12-14 03:17:58 +0100araujo(~araujo@216.73.163.29)
2023-12-14 03:18:33 +0100pavonia(~user@user/siracusa)
2023-12-14 03:18:51 +0100alp_(~alp@2001:861:e3d6:8f80:6d4b:afde:b655:292c)
2023-12-14 03:20:16 +0100xff0x(~xff0x@ai085147.d.east.v6connect.net) (Ping timeout: 246 seconds)
2023-12-14 03:21:32 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 03:26:11 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection)
2023-12-14 03:26:15 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
2023-12-14 03:26:37 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp)
2023-12-14 03:46:37 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net)
2023-12-14 03:47:52 +0100Igloo(~ian@matrix.chaos.earth.li) (Ping timeout: 276 seconds)
2023-12-14 03:51:13 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 256 seconds)
2023-12-14 03:57:32 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 04:00:32 +0100pastly(~pastly@gateway/tor-sasl/pastly) (Remote host closed the connection)
2023-12-14 04:00:32 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-12-14 04:01:06 +0100pastly(~pastly@gateway/tor-sasl/pastly)
2023-12-14 04:01:21 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-12-14 04:05:59 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-12-14 04:12:44 +0100TonyStone(~TonyStone@074-076-057-186.res.spectrum.com) (Quit: Leaving)
2023-12-14 04:16:32 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-12-14 04:16:32 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-12-14 04:16:32 +0100finn_elijaFinnElija
2023-12-14 04:16:44 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 04:19:21 +0100Igloo(~ian@matrix.chaos.earth.li)
2023-12-14 04:19:43 +0100ystael(~ystael@user/ystael) (Ping timeout: 276 seconds)
2023-12-14 04:26:03 +0100johnw(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2023-12-14 04:29:41 +0100dwt_(~dwt_@2601:2c6:8381:e5c:945:c021:4cfd:54e5) (Ping timeout: 240 seconds)
2023-12-14 04:29:52 +0100bilegeek(~bilegeek@2600:1008:b04c:8dbf:230:d76f:f63e:7bf5)
2023-12-14 04:30:26 +0100edr(~edr@user/edr) (Quit: Leaving)
2023-12-14 04:32:45 +0100Ranhir(~Ranhir@157.97.53.139) (Read error: Connection reset by peer)
2023-12-14 04:32:59 +0100td_(~td@i5387093E.versanet.de) (Ping timeout: 264 seconds)
2023-12-14 04:32:59 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:c0d1:ef99:e080:d9) (Remote host closed the connection)
2023-12-14 04:33:15 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-12-14 04:34:15 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net)
2023-12-14 04:34:44 +0100td_(~td@i53870937.versanet.de)
2023-12-14 04:35:34 +0100Inst(~Inst@129.126.215.52)
2023-12-14 04:35:41 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-12-14 04:37:03 +0100Ranhir(~Ranhir@157.97.53.139)
2023-12-14 04:39:17 +0100tri_(~tri@ool-18bc2e74.dyn.optonline.net)
2023-12-14 04:42:36 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-12-14 04:43:46 +0100mobivme(~mobivme@112.201.111.217) (Ping timeout: 276 seconds)
2023-12-14 04:44:59 +0100Inst(~Inst@129.126.215.52) (Leaving)
2023-12-14 04:45:28 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-12-14 04:45:43 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-12-14 04:57:23 +0100alp_(~alp@2001:861:e3d6:8f80:6d4b:afde:b655:292c) (Ping timeout: 256 seconds)
2023-12-14 04:59:12 +0100igemnace(~ian@user/igemnace) (Ping timeout: 252 seconds)
2023-12-14 05:04:13 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-12-14 05:13:50 +0100tomboy64(~tomboy64@user/tomboy64) (Ping timeout: 256 seconds)
2023-12-14 05:16:11 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2023-12-14 05:19:13 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-12-14 05:20:09 +0100rosco(~rosco@42.153.128.116)
2023-12-14 05:23:39 +0100rosco(~rosco@42.153.128.116) (Read error: Connection reset by peer)
2023-12-14 05:23:48 +0100not_reserved(~not_reser@45.88.222.254)
2023-12-14 05:23:49 +0100rosco(~rosco@2001:e68:5411:21b:709e:ff04:8b05:a76c)
2023-12-14 05:24:01 +0100igemnace(~ian@user/igemnace)
2023-12-14 05:31:21 +0100johnw(~johnw@69.62.242.138)
2023-12-14 05:31:42 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection)
2023-12-14 05:34:43 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net)
2023-12-14 05:35:55 +0100aforemny(~aforemny@2001:9e8:6cd0:cf00:ceee:c285:db94:113d)
2023-12-14 05:36:32 +0100aforemny_(~aforemny@i59F516CF.versanet.de) (Ping timeout: 256 seconds)
2023-12-14 05:37:39 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 05:38:48 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 256 seconds)
2023-12-14 05:50:04 +0100tomboy64(~tomboy64@user/tomboy64)
2023-12-14 05:58:49 +0100raym(~ray@user/raym) (Ping timeout: 255 seconds)
2023-12-14 05:59:14 +0100pastly(~pastly@gateway/tor-sasl/pastly) (Read error: Connection reset by peer)
2023-12-14 05:59:14 +0100chiselfuse(~chiselfus@user/chiselfuse) (Read error: Connection reset by peer)
2023-12-14 05:59:15 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2023-12-14 05:59:44 +0100chiselfuse(~chiselfus@user/chiselfuse)
2023-12-14 05:59:47 +0100pastly(~pastly@gateway/tor-sasl/pastly)
2023-12-14 05:59:54 +0100ChaiTRex(~ChaiTRex@user/chaitrex)
2023-12-14 06:00:18 +0100trev(~trev@user/trev)
2023-12-14 06:05:53 +0100raym(~ray@user/raym)
2023-12-14 06:09:12 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-12-14 06:11:59 +0100shOkEy(~shOkEy@92-249-185-141.pool.digikabel.hu) (Ping timeout: 264 seconds)
2023-12-14 06:13:17 +0100shOkEy(~shOkEy@176-241-19-57.pool.digikabel.hu)
2023-12-14 06:14:54 +0100tri(~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection)
2023-12-14 06:17:33 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2023-12-14 06:19:17 +0100tri_(~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-12-14 06:22:45 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 06:23:19 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-12-14 06:25:52 +0100araujo(~araujo@216.73.163.29) (Ping timeout: 268 seconds)
2023-12-14 06:35:44 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds)
2023-12-14 06:35:45 +0100igemnace(~ian@user/igemnace) (Read error: Connection reset by peer)
2023-12-14 06:38:18 +0100 <glguy> Feels like these aoc problems are specially made for Haskell this year ^_^
2023-12-14 06:39:31 +0100 <int-e> Kind of. I misused one of my utility functions though and that cost me a lot of time.
2023-12-14 06:41:42 +0100 <Axman6> Sounds like you need stronger types
2023-12-14 06:42:48 +0100 <glguy> Yeah, dependent types would probably speed you up
2023-12-14 06:43:48 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de)
2023-12-14 06:46:57 +0100not_reserved(~not_reser@45.88.222.254) (Quit: Client closed)
2023-12-14 06:47:16 +0100not_reserved(~not_reser@45.88.222.254)
2023-12-14 06:50:46 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de) (Ping timeout: 256 seconds)
2023-12-14 06:52:50 +0100igemnace(~ian@user/igemnace)
2023-12-14 06:56:22 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds)
2023-12-14 06:56:44 +0100 <xerox> lovely problem today
2023-12-14 06:57:43 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de)
2023-12-14 07:02:27 +0100michalz_(~michalz@185.246.207.222)
2023-12-14 07:02:56 +0100Core6935(~rosco@42.153.140.76)
2023-12-14 07:05:30 +0100rosco(~rosco@2001:e68:5411:21b:709e:ff04:8b05:a76c) (Ping timeout: 256 seconds)
2023-12-14 07:07:29 +0100michalz_(~michalz@185.246.207.222) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 07:07:48 +0100michalz_(~michalz@185.246.207.222)
2023-12-14 07:10:15 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2023-12-14 07:10:52 +0100rosco(~rosco@42.153.135.174)
2023-12-14 07:10:58 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-12-14 07:13:14 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 07:14:14 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 07:14:35 +0100Core6935(~rosco@42.153.140.76) (Ping timeout: 260 seconds)
2023-12-14 07:14:47 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de)
2023-12-14 07:15:09 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 07:15:27 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 07:18:48 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-12-14 07:21:53 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2023-12-14 07:22:47 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 07:26:07 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds)
2023-12-14 07:26:08 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 07:26:51 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 07:32:04 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Quit: BRB testing...)
2023-12-14 07:32:23 +0100Core8308(~rosco@42.153.137.144)
2023-12-14 07:34:01 +0100Core6606(~rosco@42.153.133.247)
2023-12-14 07:35:29 +0100rosco(~rosco@42.153.135.174) (Ping timeout: 256 seconds)
2023-12-14 07:35:36 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net)
2023-12-14 07:36:47 +0100Core8308(~rosco@42.153.137.144) (Ping timeout: 268 seconds)
2023-12-14 07:39:43 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-12-14 07:40:21 +0100jargon(~jargon@32.sub-174-238-226.myvzw.com) (Remote host closed the connection)
2023-12-14 07:42:52 +0100Core6606(~rosco@42.153.133.247) (Read error: Connection reset by peer)
2023-12-14 07:43:06 +0100rosco(~rosco@2001:e68:5411:21b:709e:ff04:8b05:a76c)
2023-12-14 07:44:27 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 07:50:48 +0100igemnace(~ian@user/igemnace) (Quit: WeeChat 4.1.2)
2023-12-14 07:51:03 +0100igemnace(~ian@user/igemnace)
2023-12-14 07:55:57 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 07:56:49 +0100alp_(~alp@2001:861:e3d6:8f80:7cd1:a713:1d11:e2cd)
2023-12-14 08:08:23 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2023-12-14 08:08:30 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de)
2023-12-14 08:11:48 +0100Square2(~Square4@user/square) (Ping timeout: 256 seconds)
2023-12-14 08:12:09 +0100euleritian(~euleritia@dynamic-089-204-137-160.89.204.137.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 08:12:27 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 08:12:53 +0100petrichor(~znc-user@user/petrichor) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 08:16:10 +0100acidjnk(~acidjnk@p200300d6e72b9302007c3ef187da4880.dip0.t-ipconnect.de)
2023-12-14 08:17:16 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-12-14 08:20:11 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2023-12-14 08:27:23 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1)
2023-12-14 08:28:37 +0100maars(uid160334@id-160334.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-12-14 08:29:03 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 08:51:24 +0100shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 268 seconds)
2023-12-14 09:05:12 +0100not_reserved(~not_reser@45.88.222.254) (Ping timeout: 250 seconds)
2023-12-14 09:13:00 +0100not_reserved(~not_reser@154.16.157.96)
2023-12-14 09:16:12 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 09:19:04 +0100sagax(~sagax_nb@user/sagax)
2023-12-14 09:20:46 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 245 seconds)
2023-12-14 09:20:57 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-12-14 09:29:48 +0100akegalj(~akegalj@93-137-124-143.adsl.net.t-com.hr)
2023-12-14 09:34:30 +0100CiaoSen(~Jura@2a05:5800:283:500:ca4b:d6ff:fec1:99da)
2023-12-14 09:37:44 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c)
2023-12-14 09:39:10 +0100vpan(~vpan@mail.elitnet.lt)
2023-12-14 09:39:15 +0100gmg(~user@user/gehmehgeh)
2023-12-14 09:44:28 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-12-14 09:49:25 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2023-12-14 09:50:07 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-12-14 09:50:55 +0100gmg(~user@user/gehmehgeh)
2023-12-14 09:52:08 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-12-14 09:52:31 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 09:52:50 +0100califax(~califax@user/califx)
2023-12-14 09:57:02 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 10:03:34 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds)
2023-12-14 10:05:17 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds)
2023-12-14 10:20:00 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:c0d1:ef99:e080:d9)
2023-12-14 10:21:21 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-12-14 10:23:45 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-12-14 10:30:53 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds)
2023-12-14 10:31:30 +0100euleritian(~euleritia@dynamic-089-204-137-151.89.204.137.pool.telefonica.de)
2023-12-14 10:36:54 +0100rosco(~rosco@2001:e68:5411:21b:709e:ff04:8b05:a76c) (Quit: Gotta go.)
2023-12-14 10:36:55 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 10:37:18 +0100califax(~califax@user/califx)
2023-12-14 10:38:35 +0100rosco(~rosco@175.136.152.56)
2023-12-14 10:42:28 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-12-14 10:44:45 +0100danse-nr3(~danse@151.57.232.210)
2023-12-14 10:46:30 +0100danse-nr3(~danse@151.57.232.210) (Read error: Connection reset by peer)
2023-12-14 10:47:11 +0100danse-nr3(~danse@151.57.245.15)
2023-12-14 10:47:32 +0100danse-nr3(~danse@151.57.245.15) (Remote host closed the connection)
2023-12-14 10:47:56 +0100danse-nr3(~danse@151.57.245.15)
2023-12-14 10:49:16 +0100econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-12-14 10:54:49 +0100Axman6(~Axman6@user/axman6) (*.net *.split)
2023-12-14 10:54:56 +0100ft(~ft@p4fc2ae2b.dip0.t-ipconnect.de) (Quit: leaving)
2023-12-14 10:55:22 +0100mikess(~sam@user/mikess) (Ping timeout: 255 seconds)
2023-12-14 10:56:32 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 10:56:59 +0100califax(~califax@user/califx)
2023-12-14 10:59:13 +0100Axman6(~Axman6@user/axman6)
2023-12-14 11:02:40 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-12-14 11:04:22 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz)
2023-12-14 11:05:29 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-12-14 11:05:34 +0100euleritian(~euleritia@dynamic-089-204-137-151.89.204.137.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 11:05:50 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 11:06:35 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 264 seconds)
2023-12-14 11:11:22 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 11:11:46 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 11:12:06 +0100cfricke(~cfricke@user/cfricke)
2023-12-14 11:13:25 +0100chele(~chele@user/chele)
2023-12-14 11:16:29 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 11:24:45 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 11:25:07 +0100califax(~califax@user/califx)
2023-12-14 11:37:09 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-12-14 11:38:38 +0100bilegeek(~bilegeek@2600:1008:b04c:8dbf:230:d76f:f63e:7bf5) (Quit: Leaving)
2023-12-14 11:43:49 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 256 seconds)
2023-12-14 11:45:56 +0100not_reserved(~not_reser@154.16.157.96) (Quit: Client closed)
2023-12-14 11:46:25 +0100not_reserved(~not_reser@154.16.157.96)
2023-12-14 11:51:42 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-12-14 11:51:42 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-12-14 11:51:42 +0100finn_elijaFinnElija
2023-12-14 11:53:40 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 12:01:14 +0100ubert(~Thunderbi@2a02:8109:ab8a:5a00:c848:40d2:238e:e32b)
2023-12-14 12:02:18 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 12:03:20 +0100__monty__(~toonn@user/toonn)
2023-12-14 12:05:50 +0100xff0x(~xff0x@ai085147.d.east.v6connect.net)
2023-12-14 12:06:39 +0100Pozyomka_(~pyon@user/pyon) (Quit: WeeChat 4.1.1)
2023-12-14 12:26:56 +0100rvalue(~rvalue@user/rvalue) (Ping timeout: 268 seconds)
2023-12-14 12:32:34 +0100CiaoSen(~Jura@2a05:5800:283:500:ca4b:d6ff:fec1:99da) (Ping timeout: 246 seconds)
2023-12-14 12:34:38 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds)
2023-12-14 12:35:06 +0100euleritian(~euleritia@77.22.252.56)
2023-12-14 12:35:35 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2023-12-14 12:36:20 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net)
2023-12-14 12:37:51 +0100alp__(~alp@static-176-175-89-30.ftth.abo.bbox.fr)
2023-12-14 12:40:11 +0100michalz`(~michal.zi@185.246.207.193)
2023-12-14 12:40:16 +0100alp_(~alp@2001:861:e3d6:8f80:7cd1:a713:1d11:e2cd) (Ping timeout: 246 seconds)
2023-12-14 12:41:19 +0100rvalue(~rvalue@user/rvalue)
2023-12-14 12:49:19 +0100califax(~califax@user/califx) (Ping timeout: 240 seconds)
2023-12-14 12:49:26 +0100califax_(~califax@user/califx)
2023-12-14 12:51:45 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-12-14 12:52:25 +0100califax_califax
2023-12-14 12:55:55 +0100alp__(~alp@static-176-175-89-30.ftth.abo.bbox.fr) (Ping timeout: 268 seconds)
2023-12-14 12:56:26 +0100 <danse-nr3> hi all. Regular expressions versus monadic parsing. Is there any paper i could read or library i could use to deepen the theoretical relationship between the two?
2023-12-14 13:02:19 +0100 <Axman6> i think the relationshipmis a lot clearer with applicstive parsing.
2023-12-14 13:02:39 +0100 <danse-nr3> useful clue, thanks
2023-12-14 13:03:00 +0100 <Axman6> and the differences between regular grammars and context sensitive ones
2023-12-14 13:03:12 +0100 <danse-nr3> great
2023-12-14 13:06:39 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2023-12-14 13:07:56 +0100kilolympus(~kilolympu@31.205.200.246)
2023-12-14 13:10:33 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 13:13:17 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-12-14 13:16:44 +0100araujo(~araujo@45.131.194.179)
2023-12-14 13:17:44 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 13:21:34 +0100euleritian(~euleritia@77.22.252.56) (Ping timeout: 246 seconds)
2023-12-14 13:22:27 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
2023-12-14 13:22:36 +0100euleritian(~euleritia@dynamic-089-204-137-151.89.204.137.pool.telefonica.de)
2023-12-14 13:24:01 +0100akegalj(~akegalj@93-137-124-143.adsl.net.t-com.hr) (Ping timeout: 246 seconds)
2023-12-14 13:25:01 +0100euleritian(~euleritia@dynamic-089-204-137-151.89.204.137.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 13:25:18 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 13:26:15 +0100Inst(~Inst@129.126.215.52)
2023-12-14 13:26:28 +0100 <Inst> do you know why servant might fail to display a page? Like, what kind of firewall settings?
2023-12-14 13:27:32 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-12-14 13:27:44 +0100 <danse-nr3> a firewall issue would not reach servant
2023-12-14 13:28:06 +0100califax(~califax@user/califx)
2023-12-14 13:28:10 +0100 <danse-nr3> by the way, what do you referred yesterday with "it is happening"?
2023-12-14 13:28:24 +0100 <Inst> nah, just me going crazy
2023-12-14 13:28:39 +0100 <danse-nr3> alright (:
2023-12-14 13:28:40 +0100 <Inst> type MainPage = Get `[HTML] Html
2023-12-14 13:29:20 +0100 <Inst> type Train = "train" :> Get '[HTML] Html
2023-12-14 13:29:31 +0100 <Inst> type API = MainPage :<|> Train
2023-12-14 13:29:34 +0100 <Inst> any idea how this could go wrong?
2023-12-14 13:30:38 +0100 <danse-nr3> type error or other error? You mentioned a firewall before...
2023-12-14 13:31:36 +0100 <Inst> yeah, it's def a ufw firewall issue
2023-12-14 13:32:51 +0100edr(~edr@user/edr)
2023-12-14 13:34:43 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) (Read error: Connection reset by peer)
2023-12-14 13:35:34 +0100 <Inst> fixed, thanks
2023-12-14 13:35:42 +0100 <danse-nr3> v
2023-12-14 13:36:00 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius)
2023-12-14 13:38:37 +0100CiaoSen(~Jura@2a05:5800:283:500:ca4b:d6ff:fec1:99da)
2023-12-14 13:45:04 +0100Pozyomka(~pyon@user/pyon)
2023-12-14 13:55:02 +0100petrichor(~znc-user@user/petrichor)
2023-12-14 13:55:46 +0100Inst(~Inst@129.126.215.52) (Ping timeout: 256 seconds)
2023-12-14 13:59:18 +0100danse-nr3(~danse@151.57.245.15) (Ping timeout: 252 seconds)
2023-12-14 14:01:54 +0100rosco(~rosco@175.136.152.56) (Quit: Lost terminal)
2023-12-14 14:01:55 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-12-14 14:10:51 +0100Inst(~Inst@129.126.215.52)
2023-12-14 14:12:29 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1)
2023-12-14 14:13:48 +0100alp__(~alp@2001:861:e3d6:8f80:98fe:7956:f8fa:f788)
2023-12-14 14:16:18 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net) (Remote host closed the connection)
2023-12-14 14:16:38 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net)
2023-12-14 14:22:38 +0100 <Inst> stylistically with servant, is it correct to split the APIs up into parts?
2023-12-14 14:23:34 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-12-14 14:28:30 +0100hasevil(~hasevil@host-138-37-254-126.qmul.ac.uk)
2023-12-14 14:29:17 +0100 <hasevil> hello, Is there a way to convert `Data.Either` to `Data.Strict.Either`
2023-12-14 14:29:19 +0100 <hasevil> ?
2023-12-14 14:30:50 +0100 <ncf> either Strict.Left Strict.Right
2023-12-14 14:33:27 +0100 <hasevil> ` let strictResult = either Strict.Left (Left result) Strict.Right (Right result)`
2023-12-14 14:33:32 +0100danse-nr3(~danse@151.43.157.65)
2023-12-14 14:35:29 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 14:37:08 +0100danse-nr3(~danse@151.43.157.65) (Remote host closed the connection)
2023-12-14 14:37:45 +0100danse-nr3(~danse@151.43.157.65)
2023-12-14 14:42:55 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-12-14 14:44:12 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de)
2023-12-14 14:47:01 +0100not_reserved(~not_reser@154.16.157.96) (Quit: Client closed)
2023-12-14 14:47:17 +0100not_reserved(~not_reser@154.16.157.96)
2023-12-14 14:51:54 +0100rosco(~rosco@175.136.152.56)
2023-12-14 14:52:14 +0100 <hasevil> https://paste.tomsmeding.com/Ptsw8YuF
2023-12-14 14:52:27 +0100 <hasevil> ncf: I can't get that to work
2023-12-14 14:59:11 +0100 <ncf> why not?
2023-12-14 15:02:05 +0100 <hasevil> it won't let me convert prelude either to strict either
2023-12-14 15:03:05 +0100 <[exa]> what's the error
2023-12-14 15:04:01 +0100 <[exa]> btw at which point do you want to convert the either? I don't see much places where the strict either would actually need conversion there
2023-12-14 15:07:44 +0100michalz`(~michal.zi@185.246.207.193) (Remote host closed the connection)
2023-12-14 15:10:40 +0100 <danse-nr3> they disappeared?
2023-12-14 15:11:04 +0100shriekingnoise(~shrieking@186.137.175.87)
2023-12-14 15:12:06 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
2023-12-14 15:12:22 +0100 <hasevil> see https://paste.tomsmeding.com/Ptsw8YuF
2023-12-14 15:15:29 +0100img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 15:17:18 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5)
2023-12-14 15:18:24 +0100img(~img@user/img)
2023-12-14 15:20:27 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net) (Remote host closed the connection)
2023-12-14 15:20:45 +0100ncfobserves, but does not see
2023-12-14 15:20:48 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net)
2023-12-14 15:29:16 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2023-12-14 15:29:36 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de)
2023-12-14 15:29:49 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-12-14 15:30:14 +0100thegeekinside(~thegeekin@189.217.90.224)
2023-12-14 15:30:31 +0100CiaoSen(~Jura@2a05:5800:283:500:ca4b:d6ff:fec1:99da) (Ping timeout: 276 seconds)
2023-12-14 15:37:03 +0100Sgeo(~Sgeo@user/sgeo)
2023-12-14 15:37:20 +0100mvk(~mvk@2607:fea8:5c9a:a600::cbc7)
2023-12-14 15:37:24 +0100mvk(~mvk@2607:fea8:5c9a:a600::cbc7) (Client Quit)
2023-12-14 15:38:52 +0100hasevil(~hasevil@host-138-37-254-126.qmul.ac.uk) (Quit: nyaa~)
2023-12-14 15:41:51 +0100 <kuribas> Why would you need Strict Either?
2023-12-14 15:42:06 +0100 <kuribas> Feels like premature optimization to me.
2023-12-14 15:42:50 +0100 <danse-nr3> they would not answer to questions, just prompt us with their code
2023-12-14 15:45:23 +0100 <kuribas> yeah, posing a vague, poorly specified question, then pasting some code, is for sure going to be getting you meaningful help.
2023-12-14 15:48:29 +0100zer0bitz_(~zer0bitz@user/zer0bitz)
2023-12-14 15:49:41 +0100 <kuribas> And leaving when you don't get an immediate answer.
2023-12-14 15:52:05 +0100zer0bitz(~zer0bitz@user/zer0bitz) (Ping timeout: 240 seconds)
2023-12-14 15:53:01 +0100tomsavage(~tomsavage@149.40.96.142)
2023-12-14 15:54:08 +0100 <[exa]> imagine the immense time pressure they must have faced!
2023-12-14 15:54:27 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-12-14 16:02:06 +0100ystael(~ystael@user/ystael)
2023-12-14 16:04:55 +0100alp__(~alp@2001:861:e3d6:8f80:98fe:7956:f8fa:f788) (Ping timeout: 256 seconds)
2023-12-14 16:05:16 +0100not_reserved(~not_reser@154.16.157.96) (Quit: Client closed)
2023-12-14 16:07:57 +0100wib_jonas(~wib_jonas@business-37-191-60-209.business.broadband.hu)
2023-12-14 16:09:21 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.0.5)
2023-12-14 16:10:26 +0100michalz_(~michalz@185.246.207.222) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 16:10:45 +0100michalz_(~michalz@185.246.207.193)
2023-12-14 16:14:02 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 16:14:21 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 16:17:03 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c) (Remote host closed the connection)
2023-12-14 16:25:36 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2023-12-14 16:26:05 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de)
2023-12-14 16:34:06 +0100 <kuribas> I am more leaning towards the idea that a language that requires monad transformers or effect systems aren't really practical.
2023-12-14 16:34:43 +0100 <kuribas> Rather, I'd like an imperative language that has purity and side-effect annotations.
2023-12-14 16:34:58 +0100 <kuribas> Where I could do local mutation, but the compiler proves the function pure.
2023-12-14 16:36:25 +0100 <kuribas> So I don't need stacking monads to get the benifits of purity.
2023-12-14 16:37:24 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net) (Remote host closed the connection)
2023-12-14 16:37:36 +0100 <danse-nr3> how does imperative relate to monad transformers or effect system?
2023-12-14 16:37:43 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net)
2023-12-14 16:38:05 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in)
2023-12-14 16:38:48 +0100michalz_(~michalz@185.246.207.193) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 16:39:08 +0100michalz_(~michalz@185.246.207.221)
2023-12-14 16:40:40 +0100 <kuribas> You need monad transformers to mimic effects.
2023-12-14 16:40:54 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c)
2023-12-14 16:41:02 +0100 <dolio> What about all the other monads that aren't just local mutation?
2023-12-14 16:41:03 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 16:41:08 +0100michalz_(~michalz@185.246.207.221) (Client Quit)
2023-12-14 16:41:16 +0100 <kuribas> They could still be monads :)
2023-12-14 16:41:19 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 16:41:27 +0100michalz_(~michalz@185.246.207.221)
2023-12-14 16:41:49 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de)
2023-12-14 16:42:35 +0100 <kuribas> For example, flix has a polymorphic effect system: https://flix.dev/
2023-12-14 16:43:37 +0100 <danse-nr3> does purescript fall in the class you consider more practical?
2023-12-14 16:44:00 +0100 <kuribas> no
2023-12-14 16:44:13 +0100 <kuribas> I would be happy doing purescript though.
2023-12-14 16:45:22 +0100 <kuribas> I'd like to see a language that looks imperative (like python or ruby), but has the benifits of pureity and static types.
2023-12-14 16:45:24 +0100mjs2600(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Ping timeout: 252 seconds)
2023-12-14 16:45:28 +0100 <kuribas> Even dependent types.
2023-12-14 16:47:36 +0100 <kuribas> And algebraic datatypes.
2023-12-14 16:48:15 +0100 <Rembane> Pony?
2023-12-14 16:48:58 +0100 <Rembane> Pony looks strange for a C++ programmer though
2023-12-14 16:49:57 +0100wib_jonas(~wib_jonas@business-37-191-60-209.business.broadband.hu) (Quit: Client closed)
2023-12-14 16:51:45 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 16:52:03 +0100mjs2600(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net)
2023-12-14 16:53:15 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 260 seconds)
2023-12-14 16:55:02 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection)
2023-12-14 16:55:14 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 16:55:17 +0100tri_(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 16:57:27 +0100alp__(~alp@2001:861:e3d6:8f80:ce2d:ed8b:6728:36e0)
2023-12-14 16:58:11 +0100 <d34df00d> danse-nr3: a blog post I enjoyed some time ago slightly in line with your question: https://well-typed.com/blog/2020/06/fix-ing-regular-expressions/
2023-12-14 17:00:05 +0100 <danse-nr3> oh, thank you d34df00d
2023-12-14 17:02:26 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net) (Remote host closed the connection)
2023-12-14 17:02:44 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net)
2023-12-14 17:05:40 +0100vpan(~vpan@mail.elitnet.lt) (Quit: Leaving.)
2023-12-14 17:06:37 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 17:07:12 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 17:11:50 +0100mjs2600(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Ping timeout: 268 seconds)
2023-12-14 17:11:58 +0100mjs2600_(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net)
2023-12-14 17:17:03 +0100mjs2600_(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Ping timeout: 260 seconds)
2023-12-14 17:19:12 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 17:22:19 +0100danse-nr3(~danse@151.43.157.65) (Ping timeout: 276 seconds)
2023-12-14 17:23:46 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
2023-12-14 17:27:29 +0100danse-nr3(~danse@151.19.239.57)
2023-12-14 17:34:28 +0100dhil(~dhil@2001:8e0:2014:3100:2e71:f759:1c5d:e673)
2023-12-14 17:36:46 +0100Inst(~Inst@129.126.215.52) (Quit: Leaving)
2023-12-14 17:48:26 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2023-12-14 17:49:45 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 17:56:23 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:c0d1:ef99:e080:d9) (Remote host closed the connection)
2023-12-14 17:56:39 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:7854:33e:c79:490a)
2023-12-14 17:57:06 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 17:58:16 +0100 <hololeap> I've got a GADT where every constructor has some kind of "children" field, and a class that unifies selecting this field with a getChildren method
2023-12-14 17:58:16 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 17:58:42 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 17:58:47 +0100 <hololeap> is there a convenient way to also create a setChildren or modifyChildren method without explicitly writing it for each constructor?
2023-12-14 18:00:06 +0100 <danse-nr3> did you consider lenses?
2023-12-14 18:01:38 +0100 <hololeap> sure, but how does that help
2023-12-14 18:02:28 +0100 <hololeap> oh, actually not _every_ constructor has children. one does not
2023-12-14 18:02:46 +0100 <danse-nr3> if `getChildren` was `children` instead, returning a lens, you would have the three functions
2023-12-14 18:03:06 +0100 <c_wraith> in that case, it had better be a traversal...
2023-12-14 18:03:36 +0100 <c_wraith> but anyway, it doesn't help with not writing it for evey constructor
2023-12-14 18:04:17 +0100 <c_wraith> But writing it for every constructor is good anyway. It means that if you change the type definition you get a compile error instead of code that still compiles but does something weird.
2023-12-14 18:05:25 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2023-12-14 18:05:46 +0100econo_(uid147250@id-147250.tinside.irccloud.com)
2023-12-14 18:05:58 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 18:06:42 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 18:06:58 +0100 <hololeap> I could create a pattern synonym for every constructor that has this... is it possible to tie a pattern synonym to a class like you can tie types to a class with TypeFamilies, so they all have the same name but each instance has a different definition of the pattern synonym?
2023-12-14 18:07:23 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1))
2023-12-14 18:07:33 +0100 <c_wraith> I'm worried about your use case, with one constructor not having the field.
2023-12-14 18:07:52 +0100 <c_wraith> It's starting to sound like it's setting yourself up for future bugs
2023-12-14 18:08:37 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Client Quit)
2023-12-14 18:08:37 +0100 <hololeap> basically, it's a tree that has exactly five layers, which are named via DataKinds and an enum. the last layer has no children
2023-12-14 18:08:53 +0100 <hololeap> so it doesn't get a HasChildren instance
2023-12-14 18:10:25 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 18:10:31 +0100 <hololeap> also, each layer has a slightly different container for the children
2023-12-14 18:10:37 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-12-14 18:10:42 +0100 <hololeap> class HasChildren (l :: WatchLayer) where type ChildContainer l :: Type -> Type ...
2023-12-14 18:11:13 +0100 <c_wraith> why is this a GADT at all? Are there places where you pass them around not knowing the type and need to recover it via case analysis?
2023-12-14 18:12:29 +0100mjs2600(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net)
2023-12-14 18:13:06 +0100 <hololeap> this is going really deep down a "must be an XY problem" rabbit hole where I have to explain the entire project
2023-12-14 18:13:45 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-12-14 18:13:50 +0100rosco(~rosco@175.136.152.56) (Quit: Lost terminal)
2023-12-14 18:14:28 +0100Square(~Square@user/square)
2023-12-14 18:14:29 +0100 <hololeap> if you are really that interested: https://github.com/hololeap/build-top/blob/main/src/BuildTop/Types.hs
2023-12-14 18:14:43 +0100 <c_wraith> Well, you know how to avoid that. Write down multiple definitions once and then use whatever abstracts over them.
2023-12-14 18:15:47 +0100 <c_wraith> But every time you explain *why* you want things like this, it sets off alarm bells that sound like "I tried that once, it was difficult to work with and didn't provide any real added safety"
2023-12-14 18:16:10 +0100mjs2600_(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net)
2023-12-14 18:16:20 +0100 <danse-nr3> oh, a build monitor for gentoo. Nice
2023-12-14 18:16:50 +0100 <danse-nr3> i recall i was always stressed about not catching errors when building
2023-12-14 18:17:01 +0100mjs2600(~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Ping timeout: 245 seconds)
2023-12-14 18:17:31 +0100 <hololeap> c_wraith: I see
2023-12-14 18:20:08 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-12-14 18:20:27 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-12-14 18:21:11 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 245 seconds)
2023-12-14 18:21:52 +0100 <c_wraith> Like, when I think about your use case (as described), my immediate thought is "use five different data types". When I hear you're using a GADT instead, I ask myself what additional value that gets you, and all I can come up with is.. passing them around with a polymorphic type variable that you intend to refine via case analysis. And that's certainly not something ridiculous to want, but it seems a bit unexpected for a tree with a fixed number of levels.
2023-12-14 18:22:08 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 18:25:20 +0100mikess(~sam@user/mikess)
2023-12-14 18:26:00 +0100 <hololeap> fair enough. using five different data types might work just as well. I'll admit that I _wanted_ to practice GADTs here even if I could have avoided them altogether. having the levels mentioned in the types makes it feel more organized to me, even though it might not be adding any real value.
2023-12-14 18:26:53 +0100qqq(~qqq@92.43.167.61) (Quit: leaving)
2023-12-14 18:27:01 +0100 <hololeap> so far I haven't hit any pain points with it *shrug*
2023-12-14 18:32:38 +0100 <c_wraith> Here's an interesting observation: when code is working correctly, GADTs don't give you additional expressive power over type classes. (they give you pretty different type errors, and a different set of tradeoffs for ease of development, so they're definitely not the same while developing code)
2023-12-14 18:33:34 +0100Joao003(~Joao003@190.108.99.230)
2023-12-14 18:35:38 +0100 <c_wraith> So I see a warning sign when you've got a GADT that you're using a class to provide common functionality over the different constructors.
2023-12-14 18:36:09 +0100 <danse-nr3> "as a class"?
2023-12-14 18:36:51 +0100 <danse-nr3> oh i see
2023-12-14 18:40:19 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 276 seconds)
2023-12-14 18:40:30 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de)
2023-12-14 18:42:34 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 18:42:50 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 18:42:52 +0100tomsavage(~tomsavage@149.40.96.142) (Remote host closed the connection)
2023-12-14 18:43:04 +0100alp__(~alp@2001:861:e3d6:8f80:ce2d:ed8b:6728:36e0) (Ping timeout: 256 seconds)
2023-12-14 18:43:45 +0100 <hololeap> I'll definitely keep that in mind for my next project (or if I ever feel like refactoring this one)
2023-12-14 18:45:24 +0100waldo(~waldo@user/waldo)
2023-12-14 18:47:08 +0100sm[i]sm
2023-12-14 18:48:11 +0100smshakes off the [i]
2023-12-14 18:49:10 +0100 <danse-nr3> well done, ego aint no good
2023-12-14 18:50:55 +0100 <monochrom> This reminds me of how Lean compiles k mutually recursive data types to one GADT-like type that takes an additional type index 1..k.
2023-12-14 18:51:18 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 18:51:58 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 18:53:13 +0100alexherbo2(~alexherbo@2a02-8440-3241-837e-d89e-19b9-2d52-0fce.rev.sfr.net) (Remote host closed the connection)
2023-12-14 18:54:44 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-12-14 18:54:55 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de)
2023-12-14 18:55:15 +0100euleritian(~euleritia@dynamic-089-204-139-121.89.204.139.pool.telefonica.de) (Read error: Connection reset by peer)
2023-12-14 18:55:32 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-12-14 18:56:32 +0100chele(~chele@user/chele) (Remote host closed the connection)
2023-12-14 18:58:28 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-12-14 18:59:44 +0100aruns(~aruns@user/aruns)
2023-12-14 19:01:32 +0100ubert(~Thunderbi@2a02:8109:ab8a:5a00:c848:40d2:238e:e32b) (Remote host closed the connection)
2023-12-14 19:02:14 +0100Guest2(~Guest29@145.136.152.127)
2023-12-14 19:03:43 +0100 <Guest2> Hi everyone, Im new with haskell but I have a question about the syntax. With this function withMVar :: MVar a -> (a -> IO b) -> IO b, is the part of (a-> IO b) a seperate function which u need to give annoted with the brackets '( )' and is this always the case?
2023-12-14 19:03:52 +0100igemnace(~ian@user/igemnace) (Remote host closed the connection)
2023-12-14 19:04:05 +0100Guest2(~Guest29@145.136.152.127) (Client Quit)
2023-12-14 19:04:16 +0100Guest35(~Guest29@145.136.152.127)
2023-12-14 19:04:30 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-12-14 19:04:33 +0100 <Guest35> Ah I dced, but Im guest2 with this question
2023-12-14 19:04:34 +0100 <Guest35> Guest2 19:03:43
2023-12-14 19:04:34 +0100 <Guest35> Hi everyone, Im new with haskell but I have a question about the syntax. With this function withMVar :: MVar a -> (a -> IO b) -> IO b, is the part of (a-> IO b) a seperate function which u need to give annoted with the brackets '( )' and is this always the case?
2023-12-14 19:06:00 +0100 <dminuoso_> Guest35: The parenthesis () are just for syntactical grouping.
2023-12-14 19:06:35 +0100 <dminuoso_> So yes, `withMVar :: MVar a -> (a -> IO b) -> IO b` takes two arguments, the first is of type `MVar a` and the second is a function of type `a -> IO b`
2023-12-14 19:07:09 +0100 <Guest35> But does this mean that the parenthesis, not brackets mb, are always meant for functions?
2023-12-14 19:07:15 +0100 <dminuoso_> No.
2023-12-14 19:07:27 +0100 <dminuoso_> The parenthesis serve the same purpose as parenthesis in mathematical notation.
2023-12-14 19:07:33 +0100 <dminuoso_> Say when I write `(1 + 2) * 3`
2023-12-14 19:07:49 +0100 <dminuoso_> Note that parenthesis can also be redundant:
2023-12-14 19:07:53 +0100 <dminuoso_> (1 * 3) + 2
2023-12-14 19:08:25 +0100 <dminuoso_> Guest35: Maybe (IO a)
2023-12-14 19:08:34 +0100 <dminuoso_> Is an example of a type where you use parenthesis but without a function type.
2023-12-14 19:09:04 +0100 <Guest35> I see
2023-12-14 19:09:46 +0100 <Guest35> Ah okay, i think I understand it
2023-12-14 19:09:51 +0100 <EvanR> the ->'s have right leaning associativity so withMVar can be read as having type MVar a -> ((a -> IO b) -> IO b)
2023-12-14 19:10:11 +0100 <EvanR> one set of parens is unnecessary given that, the other is required
2023-12-14 19:10:22 +0100 <dminuoso_> Guest35: To put things into perspective, even (->) is not special magic, its just an infix type!
2023-12-14 19:10:44 +0100 <Guest35> I see
2023-12-14 19:10:48 +0100 <dminuoso_> Guest35: We could imagine instead of having (->) there was a type `Func` instead, such that rather than `Int -> Double` you would write `Func Int Double`
2023-12-14 19:10:55 +0100 <dminuoso_> With such a type, you would have:
2023-12-14 19:11:27 +0100 <dminuoso_> withMVar :: Func (MVar a) (Func (Func a (IO b)) IO b)
2023-12-14 19:11:38 +0100 <dminuoso_> Oh I missed some parenthesis there
2023-12-14 19:11:41 +0100 <dminuoso_> withMVar :: Func (MVar a) (Func (Func a (IO b)) (IO b))
2023-12-14 19:11:43 +0100 <dminuoso_> This looks right now.
2023-12-14 19:11:52 +0100 <EvanR> clear as mud xD
2023-12-14 19:11:54 +0100 <dminuoso_> Guest35: There's some useful intuition here: See how this literally is a function returning a function?
2023-12-14 19:12:25 +0100 <Guest35> Oh man this is getting a bit confusing
2023-12-14 19:12:31 +0100 <dminuoso_> Okay, then step back and ignore what I wrote.
2023-12-14 19:12:34 +0100 <Guest35> Haha
2023-12-14 19:12:37 +0100 <Guest35> Thank you though
2023-12-14 19:12:56 +0100 <EvanR> IO a is a type
2023-12-14 19:13:03 +0100 <EvanR> Maybe (IO a) is a type, here you need parentheses
2023-12-14 19:13:45 +0100 <dminuoso_> Guest35: So the space can be thought as a left-associative function application operator with the highest precedence.
2023-12-14 19:13:53 +0100 <EvanR> since Maybe IO a would mean the same thing as (Maybe IO) a, which is wrong
2023-12-14 19:14:01 +0100 <dminuoso_> Meaning, if you wrote `Either Int Double`, this really associates as: `(Either Int) Double`
2023-12-14 19:14:16 +0100 <dminuoso_> Not different from the value level, where writing `fmap f x` associates as `(fmap f) x`
2023-12-14 19:14:58 +0100 <Guest35> Hmmmmm
2023-12-14 19:15:15 +0100 <EvanR> f x y z = ((f x) y) z
2023-12-14 19:15:38 +0100 <dminuoso_> Guest35: Now in that sense, (->) is a right-associative operator. Meaning `Int -> Double -> Char` on the other hand associates as: `Int -> (Double -> Char)`
2023-12-14 19:15:42 +0100 <EvanR> a -> b -> c -> c = a -> (b -> (c -> d))
2023-12-14 19:15:48 +0100 <dminuoso_> (A type level operator, of course)
2023-12-14 19:16:04 +0100 <Guest35> Yess
2023-12-14 19:16:07 +0100 <Guest35> I understand
2023-12-14 19:16:45 +0100 <Guest35> The math relation between it makes it understandable
2023-12-14 19:16:52 +0100 <Guest35> Or well
2023-12-14 19:17:10 +0100 <Guest35> not really math, but the function relation
2023-12-14 19:17:29 +0100 <Joao003> What are you talking about here?
2023-12-14 19:17:30 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 19:17:38 +0100 <EvanR> just the role of grouping expressions properly of parentheses, which is used in math too
2023-12-14 19:17:42 +0100 <dminuoso_> Guest35: I think its very valuable to learn about associativity (left/right associative) and precedence.
2023-12-14 19:17:45 +0100 <EvanR> with parentheses
2023-12-14 19:17:55 +0100 <Guest35> Yes, it is very important
2023-12-14 19:18:22 +0100 <EvanR> sometimes you get away without parentheses in math because you can format the expression another way and the grouping is obvious
2023-12-14 19:18:26 +0100 <dminuoso_> Especially in Haskell because we can not only have various operators, but we can define whether a given self created operator is left/right associative and also specify its precedence level.
2023-12-14 19:18:43 +0100 <Joao003> Guest35: And you need to remember how certain functions associate (for example, (:) associates on the right)
2023-12-14 19:18:45 +0100 <dminuoso_> So if you saw something like: foo $ f . g <$> x
2023-12-14 19:19:09 +0100 <dminuoso_> You need to have some kind of implicit knowledge of each operators fixity.
2023-12-14 19:19:14 +0100 <Joao003> Yes.
2023-12-14 19:19:32 +0100 <Joao003> dminuoso_: I have never seen <$>
2023-12-14 19:19:48 +0100 <dminuoso_> Joao003: <$> is an infix fmap, its probably one of the most common operators out there.
2023-12-14 19:19:55 +0100 <Joao003> Nice.
2023-12-14 19:19:59 +0100 <dminuoso_> Definitely in the top 10.
2023-12-14 19:20:23 +0100 <dminuoso_> Intuitively Id rank it on 3 in terms of usage frequency.
2023-12-14 19:20:37 +0100 <Joao003> Do you like coding pointfree?
2023-12-14 19:20:40 +0100 <dminuoso_> No.
2023-12-14 19:20:40 +0100 <EvanR> <*> and <$> are usually what triggers the "too many operators" complaint about haskell among people that don't know haskell
2023-12-14 19:21:05 +0100 <EvanR> which is sad because those form such a great pattern, applicative programming
2023-12-14 19:21:09 +0100 <Guest35> Isn't $ the applying operator
2023-12-14 19:21:12 +0100 <dminuoso_> EvanR: Oh my operator frequency usage is like a bell curve with the peak being after 3 years or so. :-)
2023-12-14 19:21:29 +0100 <EvanR> f $ x = f x
2023-12-14 19:21:32 +0100 <Guest35> yes
2023-12-14 19:21:33 +0100 <Guest35> exactly
2023-12-14 19:21:39 +0100 <Guest35> So what is the use of < >
2023-12-14 19:21:40 +0100 <EvanR> comes in handy sometimes
2023-12-14 19:21:48 +0100 <dminuoso_> Guest35: Oh this is a long story.
2023-12-14 19:21:49 +0100 <EvanR> <$> is the entire operator, < > isn't a thing
2023-12-14 19:22:02 +0100 <EvanR> you can put whatever symbols in a row to make an operator
2023-12-14 19:22:06 +0100 <dminuoso_> Guest35: The <> have become to mean a loose thing that makes sense if you have some practice.
2023-12-14 19:22:17 +0100 <Guest35> Ah
2023-12-14 19:22:31 +0100 <dminuoso_> Guest35: Take a look at this:
2023-12-14 19:22:33 +0100 <Guest35> Well, ill have some practice and come back with more knownledge ;D
2023-12-14 19:22:33 +0100 <dminuoso_> % :t <$>
2023-12-14 19:22:33 +0100 <yahb2> <interactive>:1:1: error: parse error on input ‘<$>’
2023-12-14 19:22:34 +0100igemnace(~ian@user/igemnace)
2023-12-14 19:22:39 +0100 <dminuoso_> :t (<$>)
2023-12-14 19:22:40 +0100 <lambdabot> Functor f => (a -> b) -> f a -> f b
2023-12-14 19:22:42 +0100 <dminuoso_> :t ($)
2023-12-14 19:22:43 +0100 <lambdabot> (a -> b) -> a -> b
2023-12-14 19:22:47 +0100 <EvanR> Guest35, f <$> x = fmap f x
2023-12-14 19:22:56 +0100 <EvanR> or f `fmap` x
2023-12-14 19:22:57 +0100 <dminuoso_> Guest35: If you squint a bit, `fmap` is for applying functions (under a functor).
2023-12-14 19:23:04 +0100 <Joao003> <$> is $ for Functor
2023-12-14 19:23:12 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in)
2023-12-14 19:23:13 +0100 <Guest35> What is a Functor
2023-12-14 19:23:16 +0100 <dminuoso_> Guest35: this is why you have a $ in that. Its just a hint because of the similarity.
2023-12-14 19:23:21 +0100 <dminuoso_> Guest35: Something you can fmap over.
2023-12-14 19:23:27 +0100 <Guest35> I see
2023-12-14 19:23:31 +0100 <EvanR> Functor is a type class with one method: fmap
2023-12-14 19:23:35 +0100 <dminuoso_> (In some sensible fashion)
2023-12-14 19:23:42 +0100 <Joao003> Guest35: Functor is defined as the class of types with fmap
2023-12-14 19:23:57 +0100 <dminuoso_> Guest35: So anyway. So with that in mind, let me present you with a zoo of related combinators
2023-12-14 19:24:01 +0100 <Guest35> Thank you guys, you're all very usefull ;D
2023-12-14 19:24:02 +0100 <dminuoso_> :t (<$>)
2023-12-14 19:24:02 +0100 <EvanR> > fmap ord "hello"
2023-12-14 19:24:03 +0100 <lambdabot> Functor f => (a -> b) -> f a -> f b
2023-12-14 19:24:04 +0100 <dminuoso_> :t ($>)
2023-12-14 19:24:04 +0100 <lambdabot> [104,101,108,108,111]
2023-12-14 19:24:05 +0100 <lambdabot> error:
2023-12-14 19:24:05 +0100 <lambdabot> • Variable not in scope: $>
2023-12-14 19:24:05 +0100 <lambdabot> • Perhaps you meant one of these:
2023-12-14 19:24:10 +0100 <dminuoso_> % import Data.Functor
2023-12-14 19:24:10 +0100 <yahb2> <no output>
2023-12-14 19:24:12 +0100 <EvanR> rofl
2023-12-14 19:24:15 +0100 <dminuoso_> % :t (<$>)
2023-12-14 19:24:15 +0100 <yahb2> (<$>) :: Functor f => (a -> b) -> f a -> f b
2023-12-14 19:24:17 +0100 <dminuoso_> % :t (<$)
2023-12-14 19:24:17 +0100 <yahb2> (<$) :: Functor f => a -> f b -> f a
2023-12-14 19:24:19 +0100 <dminuoso_> % :t ($>)
2023-12-14 19:24:19 +0100 <yahb2> ($>) :: Functor f => f a -> b -> f b
2023-12-14 19:24:20 +0100 <Joao003> fmap takes the value out of a functor, applies a functor to it and puts it back into a functor
2023-12-14 19:24:23 +0100 <dminuoso_> % :t ($)
2023-12-14 19:24:23 +0100 <yahb2> ($) :: (a -> b) -> a -> b
2023-12-14 19:24:29 +0100 <dminuoso_> Guest35: ^- do you see the pattern here?
2023-12-14 19:24:46 +0100 <Joao003> applies a function*
2023-12-14 19:25:03 +0100 <EvanR> not always, for example the IO functor
2023-12-14 19:25:03 +0100 <Joao003> % :t <*>
2023-12-14 19:25:03 +0100 <yahb2> <interactive>:1:1: error: parse error on input ‘<*>’
2023-12-14 19:25:09 +0100 <Joao003> % :t (<*>)
2023-12-14 19:25:09 +0100 <yahb2> (<*>) :: Applicative f => f (a -> b) -> f a -> f b
2023-12-14 19:25:25 +0100 <dminuoso_> Guest35: Ignore for a second what these may possibly do. Just take note at the argument on which a `<` or `>` appears, also has an `f`. and if the `<` or `>` is missing, that respective side has no f either.
2023-12-14 19:25:30 +0100 <EvanR> there's no way to take out a value from the IO functor
2023-12-14 19:25:59 +0100 <dminuoso_> Guest35: So this has become a kind of Haskellism, where we design the operator characters in such a way, that you can somehow infer things visually from it.
2023-12-14 19:26:20 +0100 <Guest35> so, for my newled brain, it means that u can apply a function in different ways, its like a mix of left and right associative operator
2023-12-14 19:26:21 +0100 <dminuoso_> similarly, we have <*>, <* and *>. Though we have no (*) equivalent.
2023-12-14 19:26:31 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-12-14 19:26:34 +0100 <Joao003> Because (*) is multiplication
2023-12-14 19:26:35 +0100thegeekinside(~thegeekin@189.217.90.224) (Remote host closed the connection)
2023-12-14 19:26:56 +0100 <Guest35> Oh man
2023-12-14 19:26:59 +0100 <EvanR> * is supposed to make you think about product
2023-12-14 19:27:09 +0100 <EvanR> but <*> is really applicative
2023-12-14 19:27:16 +0100 <EvanR> ff <*> xx
2023-12-14 19:27:22 +0100 <dminuoso_> Guest35: The point Im trying to make, there is often systems behind the operator names that will make it easier to read them.
2023-12-14 19:27:34 +0100 <EvanR> but there's an equivalent formulation of Applicative in terms of products
2023-12-14 19:27:45 +0100 <dminuoso_> Guest35: You're not required to memorize any of this right now. :)
2023-12-14 19:27:49 +0100 <Guest35> Haha
2023-12-14 19:27:49 +0100 <Joao003> > [(+3),(*4)] <*> [2]
2023-12-14 19:27:50 +0100 <lambdabot> [5,8]
2023-12-14 19:28:02 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 19:28:26 +0100 <Guest35> Well guys
2023-12-14 19:28:32 +0100 <Guest35> I appreciate the help, I do understand more
2023-12-14 19:28:49 +0100 <EvanR> great
2023-12-14 19:28:57 +0100 <Guest35> I'ma code and probably give u guys more questions in the future :D
2023-12-14 19:29:05 +0100 <Guest35> Thanks
2023-12-14 19:29:13 +0100 <Joao003> Guys, how do you pronounce operators like (>>=) and (<*>)?
2023-12-14 19:29:22 +0100 <Rembane> Joao003: bind, fancy star
2023-12-14 19:29:29 +0100Guest35(~Guest29@145.136.152.127) (Quit: Client closed)
2023-12-14 19:29:40 +0100 <EvanR> @quote pronounce
2023-12-14 19:29:40 +0100 <lambdabot> DougBagley says: The Koan of Lazy Evaluation: Michel Mauny was giving a guest lecture to new computer science students. After the students were seated, Michel pronounced "Today's lecture will be
2023-12-14 19:29:40 +0100 <lambdabot> about Lazy Evaluation", he paused for a moment then concluded with, "Are there any questions?"
2023-12-14 19:29:46 +0100 <EvanR> oof
2023-12-14 19:30:00 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2023-12-14 19:30:23 +0100 <EvanR> >>= is bind, <*> is "ap"
2023-12-14 19:30:30 +0100 <EvanR> not that I pronounce either one
2023-12-14 19:30:45 +0100 <EvanR> existing purely within the world of IRC in complete silence
2023-12-14 19:31:04 +0100 <EvanR> :t ap
2023-12-14 19:31:05 +0100 <lambdabot> Monad m => m (a -> b) -> m a -> m b
2023-12-14 19:31:23 +0100 <EvanR> this operation predates Applicative it's so old
2023-12-14 19:31:39 +0100 <Joao003> Rembane: I pronounce (>>=) as "insert", because you can do `reverse >>= (==)' and it becomes `\x -> (reverse x) == x'
2023-12-14 19:32:42 +0100 <Joao003> > (reverse >>= (==)) "racecar" -- palindrome check
2023-12-14 19:32:42 +0100 <EvanR> that's about as nonsensical as bind, so fair xD
2023-12-14 19:32:43 +0100 <lambdabot> True
2023-12-14 19:33:12 +0100 <Joao003> I got lambdabot to agree with you XD
2023-12-14 19:34:46 +0100 <EvanR> insert is also the opposite of extract
2023-12-14 19:35:05 +0100 <EvanR> which is the wrong corresponding operation in Comonad
2023-12-14 19:35:09 +0100waldo(~waldo@user/waldo) (Ping timeout: 256 seconds)
2023-12-14 19:35:17 +0100 <Joao003> And I pronounce <*> as "multimap", because it can do multiple maps at once
2023-12-14 19:35:33 +0100 <Joao003> > [Left, Right] <*> [2,3]
2023-12-14 19:35:34 +0100 <lambdabot> [Left 2,Left 3,Right 2,Right 3]
2023-12-14 19:35:57 +0100 <dminuoso_> Joao003: And on ZipList?
2023-12-14 19:36:01 +0100 <dminuoso_> Or on IO?
2023-12-14 19:36:05 +0100 <EvanR> wouldn't that be multi-ap
2023-12-14 19:36:11 +0100 <EvanR> multiple applications at once
2023-12-14 19:36:21 +0100 <dminuoso_> The most general description you can give <*> is a very loose and rough "parallel ap"
2023-12-14 19:36:27 +0100 <Joao003> Yes
2023-12-14 19:36:37 +0100 <dminuoso_> Though it takes some mind twisting to see the "parallel" in examples.
2023-12-14 19:36:42 +0100 <Joao003> Yes
2023-12-14 19:36:54 +0100 <dminuoso_> In list it works if you think of a list as modelling non-determinsm
2023-12-14 19:37:14 +0100 <Joao003> <$> is "fmap" of course
2023-12-14 19:37:36 +0100 <EvanR> > cycle [Left,Right] <*> cycle [2,3]
2023-12-14 19:37:37 +0100 <lambdabot> [Left 2,Left 3,Left 2,Left 3,Left 2,Left 3,Left 2,Left 3,Left 2,Left 3,Left ...
2023-12-14 19:38:10 +0100 <Joao003> Only the first function maps because you're mapping onto an infinite list
2023-12-14 19:38:27 +0100 <EvanR> now I see why you think it's a map
2023-12-14 19:38:33 +0100 <EvanR> Left 2, Left 3
2023-12-14 19:39:10 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds)
2023-12-14 19:39:22 +0100 <Joao003> Though the * tells you that it's going to do multiple things at once
2023-12-14 19:39:30 +0100 <EvanR> haha, now it's a kleene star
2023-12-14 19:39:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:7854:33e:c79:490a) (Remote host closed the connection)
2023-12-14 19:39:52 +0100alp__(~alp@2001:861:e3d6:8f80:f550:1f70:2377:c233)
2023-12-14 19:40:25 +0100 <EvanR> the * is probably a consequence of Applicatives product alternative formulation, f a -> f b -> f (a,b) and there being not other good ascii characters to use for that
2023-12-14 19:40:30 +0100 <EvanR> since $ is taken
2023-12-14 19:41:12 +0100 <EvanR> .oO(<@>)
2023-12-14 19:41:18 +0100 <Joao003> what about #?
2023-12-14 19:41:40 +0100 <EvanR> # seems like it would be used for numbers
2023-12-14 19:42:10 +0100 <EvanR> back when applicative was invented hashtag was not a thing
2023-12-14 19:42:14 +0100 <Joao003> Oh
2023-12-14 19:42:29 +0100 <Joao003> EvanR: You mean octothorpe?
2023-12-14 19:42:42 +0100 <EvanR> there you go again pronouncing stuff
2023-12-14 19:43:10 +0100 <hc> *reading backlog* lol@ that lazy evaluation lecure story :-)
2023-12-14 19:43:44 +0100 <Joao003> ò_ô
2023-12-14 19:51:33 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de)
2023-12-14 19:52:31 +0100 <Joao003> If <$> is "fmap", then why is <$ a "replace everything with this one thing"?
2023-12-14 19:53:27 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de) (Client Quit)
2023-12-14 19:54:39 +0100 <int-e> The way I remember this is... <* takes from the left, *> takes from the right, <*> takes from both sides and does something with it (apply). <$ is a variant of <* and <$> is a variant of <*>.
2023-12-14 19:55:36 +0100 <int-e> (So the < and > are arrows to my mind.)
2023-12-14 19:55:59 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 19:57:29 +0100 <Joao003> int-e: Same with >>= and =<<
2023-12-14 19:59:46 +0100 <EvanR> :t (<*)
2023-12-14 19:59:47 +0100 <lambdabot> Applicative f => f a -> f b -> f a
2023-12-14 20:00:02 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de)
2023-12-14 20:00:04 +0100 <Joao003> > [1..3] <* [1..3]
2023-12-14 20:00:05 +0100 <lambdabot> [1,1,1,2,2,2,3,3,3]
2023-12-14 20:00:11 +0100 <Joao003> > [1..3] *> [1..3]
2023-12-14 20:00:12 +0100 <lambdabot> [1,2,3,1,2,3,1,2,3]
2023-12-14 20:00:53 +0100danse-nr3(~danse@151.19.239.57) (Ping timeout: 240 seconds)
2023-12-14 20:03:15 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:7854:33e:c79:490a)
2023-12-14 20:04:24 +0100 <Joao003> For functions, <* picks the left and *> picks the right
2023-12-14 20:04:40 +0100 <Joao003> So I pronounce them "pickleft" and "pickright" :)
2023-12-14 20:05:45 +0100 <dminuoso_> Also, maybe they were just picked at random
2023-12-14 20:06:14 +0100 <dminuoso_> Some things were just put in place without much of a thought. Case in point: fixity of ($)
2023-12-14 20:06:17 +0100 <monochrom> I know it's a lost cause but I still like to roast: Why are you obsessed with converting code to voice? Are you a dial-up modem?
2023-12-14 20:06:42 +0100 <int-e> I like the fixity of $
2023-12-14 20:07:54 +0100 <int-e> Mainly I like being able to write `pure $` and then start thinking about the value that I want to return. Of course if `$` has a different fixity I never would have developed this particular habit.
2023-12-14 20:08:02 +0100 <monochrom> (The deeper possibility is that perhaps people aren't visual learners after all, but rather auditory learners.)
2023-12-14 20:08:25 +0100 <int-e> Or maybe they just learn if they actively engage with a topic.
2023-12-14 20:08:28 +0100 <dminuoso_> int-e: Of course you would. Im not debating its precedence, but ($) should have been infixl not infixr.
2023-12-14 20:08:40 +0100 <dminuoso_> It would for the most part be still usable in the same way.
2023-12-14 20:08:41 +0100ft(~ft@p4fc2ae2b.dip0.t-ipconnect.de)
2023-12-14 20:08:52 +0100 <int-e> dminuoso_: But then I couldn't write pure $ foo . bar $ x
2023-12-14 20:09:06 +0100 <int-e> dminuoso_: which is part of the habit I mentioned
2023-12-14 20:09:27 +0100waldo(~waldo@user/waldo)
2023-12-14 20:09:40 +0100 <int-e> I'd have to go back and change the first $ into a .
2023-12-14 20:10:25 +0100 <hc> Hey, I need to amend that lazy evaluation joke: "When a student raised their hand and asked a question, the lecturer responded: Okay, thank you for your question; if you would excuse me for a while, I will start to prepare the talk and in the process I will finally be able to get rid of the thousand books I've accumulated over the years" :D
2023-12-14 20:10:42 +0100 <Joao003> lol
2023-12-14 20:11:50 +0100 <int-e> cue loud thunking noises from the whole building including the attic, and several garbage trucks coming by and driving off again
2023-12-14 20:13:02 +0100 <dminuoso_> By far the best lazy evaluation joke is this one: https://ro-che.info/ccc/11
2023-12-14 20:16:29 +0100 <dminuoso_> int-e: I think left-associativity on ($) is still better on average. It matches the associativity of the function application operator (which it extends on), which means inserting/removing it wont change the visual "scanning path" for reading code.
2023-12-14 20:16:52 +0100 <hc> dminuoso_: Hmm, they only asked him to implement the function. They never asked him to *show* the result ;p
2023-12-14 20:17:32 +0100igemnace(~ian@user/igemnace) (Remote host closed the connection)
2023-12-14 20:17:43 +0100 <hc> So actually his strictness analyser *is* broken =)
2023-12-14 20:18:03 +0100 <monochrom> It is very optimistic to assume that the student question triggers cleanup. The other possibility that people actually experience and complain bitterly about is that the student question triggers buying a lot of books to help work on the question. This is fondly known as "space leak".
2023-12-14 20:18:08 +0100 <dminuoso_> hc: That wouldnt be a strictness analyzer bug, but an evaluation bug.
2023-12-14 20:18:22 +0100todi(~todi@p5dca55c4.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in)
2023-12-14 20:18:28 +0100 <dminuoso_> Or well. Would it?
2023-12-14 20:18:39 +0100 <dminuoso_> hc: Nothing in the Haskell Report prevents speculative execution.
2023-12-14 20:19:07 +0100 <dminuoso_> In fact, given that the Haskell report is careful to not use the term "lazy" but "non-strict" instead suggests it even openly embraces speculative execution.
2023-12-14 20:19:11 +0100waldo(~waldo@user/waldo) (Ping timeout: 264 seconds)
2023-12-14 20:19:13 +0100 <hc> Yeah, actually, haskell is not as nonstrict as one might think
2023-12-14 20:19:33 +0100 <hc> Some programs that we have come to expect to behave in a certain way might theoretically not work/terminate in a specific haskell implementation
2023-12-14 20:19:39 +0100 <hc> Just like it is with C ;d
2023-12-14 20:20:01 +0100 <hc> s/d$/b/
2023-12-14 20:21:02 +0100 <dminuoso_> hc: So yeah, Ill claim what the interviewee is doing is just speculative execution.
2023-12-14 20:21:11 +0100 <dminuoso_> If anything, that "speculation analyzer" seems to be working just fine.
2023-12-14 20:21:34 +0100 <hc> Yes indeed, he's expecting them to want to see his implementation, but since they were asking about haskell, he might have been wrong about that ;)
2023-12-14 20:26:38 +0100 <monochrom> Here is a simpler explanation. The interviewee still needs to answer "yes" or "no", and that triggers evaluation.
2023-12-14 20:28:36 +0100 <int-e> they should've come prepared and left behind a black hole in their stead
2023-12-14 20:30:22 +0100shapr(~user@2600:1700:c640:3100:8636:87c:743f:950a)
2023-12-14 20:30:40 +0100danza(~danza@151.19.239.57)
2023-12-14 20:31:48 +0100 <monochrom> Also, I take the view that the Haskell Report secretly wants to say "lazy". The clue is from having seq. seq is John Hughes's addition, and he said in an interview his addition is for saving space. The premise "seq helps save space" requires lazy evaluation.
2023-12-14 20:38:36 +0100juri_(~juri@implicitcad.org) (Ping timeout: 252 seconds)
2023-12-14 20:39:32 +0100 <hc> So it's lazy by implication
2023-12-14 20:40:13 +0100 <dminuoso_> monochrom: Though seq by specification doesnt mandate lazy evaluation, its why we have pseq.
2023-12-14 20:40:22 +0100 <int-e> "It's not lazy, it violates the left-most outermost evaluation order! And sometimes it even breaks sharing!!1elevne"
2023-12-14 20:40:43 +0100juri_(~juri@79.140.115.48)
2023-12-14 20:42:39 +0100 <monochrom> I have discussed this before. Here it goes again.
2023-12-14 20:43:25 +0100 <int-e> for me? you shouldn't :P
2023-12-14 20:43:55 +0100 <int-e> (maybe it's not too late for this spark to fizzle out)
2023-12-14 20:44:09 +0100 <monochrom> The C standard, for example, allows a compiler to decide to compile "unsigned f(unsigned x, unsigned y) { return x; }" to take Ω(2^y) time.
2023-12-14 20:44:51 +0100 <monochrom> The only reason no one actually does that is because competition. Who would use that compiler when other choices gives you sweet O(1) time?
2023-12-14 20:45:31 +0100waldo(~waldo@user/waldo)
2023-12-14 20:46:37 +0100 <monochrom> The lesson is that most standards feel like leaving open efficiency, hoping that compiler vendors don't troll you because why would they.
2023-12-14 20:47:48 +0100 <monochrom> seq is not standardized to be eager or whatever, but in practice compiler writers are driven to make it eager or very much close enough.
2023-12-14 20:49:16 +0100 <int-e> . o O ( Hardcore C compiler/computer... whenever you trigger undefined behavior, your computer explodes )
2023-12-14 20:50:36 +0100 <EvanR> that would end the fun quite early. Instead it should deliver electric shock to the user
2023-12-14 20:50:49 +0100 <int-e> The contract that ghc tries to abide by is basically not to force any unneeded bottoms. Which mostly covers expensive computations too because the compiler generally can't prove that those terminate.
2023-12-14 20:51:01 +0100 <int-e> EvanR: That's the normal game mode, not the hardcore one.
2023-12-14 20:51:09 +0100 <dminuoso_> monochrom: Your analogy is flawed: a non-strict seq is not a performance loss, its the opposite, its potential for better performance.
2023-12-14 20:51:14 +0100 <EvanR> oh ok, ultra violence < nightmare
2023-12-14 20:51:44 +0100 <dminuoso_> (or well, non-lazy I should say)
2023-12-14 20:51:45 +0100 <monochrom> Rather than "flawed", the better position is "it cuts both ways".
2023-12-14 20:51:45 +0100juri_(~juri@79.140.115.48) (Read error: Connection reset by peer)
2023-12-14 20:52:07 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-12-14 20:52:59 +0100juri_(~juri@79.140.115.48)
2023-12-14 20:53:11 +0100 <dminuoso_> So I guess this goes into int-e's portion of "not forcing unneeed bottoms"
2023-12-14 20:53:24 +0100 <EvanR> oh now we're non-lazy too? I'm getting sick of non-semantics xD
2023-12-14 20:53:37 +0100 <dminuoso_> Introducing any fancy speculative execution + non-strict seq would be cool, but also break tons of code.
2023-12-14 20:53:51 +0100 <dminuoso_> While I think much of ghc/base is covered correctly, the same cannot be said of most hackage.
2023-12-14 20:53:51 +0100 <hc> By the way, speaking of compiler vendors, any of you guys know bluespec? It's a haskell verilog, basically. I've just started to have a look at it and find it quite interesting :)
2023-12-14 20:54:57 +0100 <int-e> monochrom: `seq` is just another dependency injection, only this time it's an artificial data dependency :)
2023-12-14 20:55:02 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 20:55:22 +0100 <int-e> (You were joking about dependency injection the other day, or maybe EvanR was?)
2023-12-14 20:55:54 +0100 <monochrom> EvanR. (->)r is the dependency injection functor.
2023-12-14 20:56:38 +0100 <EvanR> data dependency injection
2023-12-14 20:56:41 +0100 <int-e> toy `seq` groceries ...that toy that the child really *needed* that has been sitting on the shelf ever since
2023-12-14 20:57:29 +0100 <EvanR> if it's an exploding toy, then you necessarily explode before making it out of the store
2023-12-14 20:57:29 +0100juri_(~juri@79.140.115.48) (Read error: Connection reset by peer)
2023-12-14 20:57:52 +0100 <int-e> who's stocking that place? ACME?
2023-12-14 20:57:59 +0100juri_(~juri@79.140.115.48)
2023-12-14 20:58:02 +0100 <int-e> these jokes are increasingly forced
2023-12-14 20:58:27 +0100 <EvanR> joke parametricity?
2023-12-14 20:58:29 +0100 <hc> No one here knows bluespec? I am really surprised no one knows it. I guess most people interested in hardware design aren't interested in haskell and vice versa?
2023-12-14 20:58:50 +0100 <EvanR> real hardware is scary
2023-12-14 20:58:53 +0100 <int-e> hc: I bet a lot of people have /heard/ of it but not used it.
2023-12-14 20:59:11 +0100 <hc> EvanR: True, and fascinating :)
2023-12-14 20:59:19 +0100 <int-e> (It is one of the more visible Haskell projects.)
2023-12-14 20:59:22 +0100 <EvanR> abstract perfectly behaving functional hardware sounds fun
2023-12-14 20:59:44 +0100 <hc> int-e: oh, is it? Okay :) I can recommend to play around with it, I really enjoy doing so
2023-12-14 21:01:47 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2023-12-14 21:03:03 +0100 <Joao003> Tell me some jokes
2023-12-14 21:03:19 +0100 <monochrom> My point is this. Or rather, my beef is this. People have this question, they wrote "sum acc (x:xs) = sum (acc+x) xs", why does it take so much space? why does seq help? And the converse holds too, "sins (x:xs) = let r = sins xs in seq r (sin x : r)", why is that bad, why deleting seq helps?
2023-12-14 21:04:14 +0100 <monochrom> So when it comes to space and time questions, I must use an operational model, or at least that's the best approach we have for now.
2023-12-14 21:04:53 +0100 <monochrom> But along come do-gooder smart*ss who will say, no no no, the standard does not require lazy evaluation, it does not require seq to increase eagerness.
2023-12-14 21:05:08 +0100 <monochrom> OK sure smart*ass, so how do you answer that question?
2023-12-14 21:05:13 +0100 <int-e> sure, in practice you're working with, 99% of the time, ghc.
2023-12-14 21:05:28 +0100 <EvanR> that was the position of most people on the decision to make sum use foldl and not foldl'
2023-12-14 21:05:28 +0100 <dolio> Exactly specifying the evaluation behavior of seq could easily give sub-optimal results.
2023-12-14 21:05:28 +0100 <monochrom> with all your high-horse denotational domains.
2023-12-14 21:06:13 +0100m1dnight_(~christoph@78-22-4-67.access.telenet.be)
2023-12-14 21:06:27 +0100 <dolio> Like: ack 5 5 `seq` error "bomb" `seq` ()
2023-12-14 21:06:35 +0100 <tomsmeding> the standard may not require lazy evaluation, but it certainly doesn't require strict evaluation either -- and when the standard leaves something unspecified, and the question is about the operational behaviour of a compiled program, the only thing one CAN turn to is what the compiler does
2023-12-14 21:06:40 +0100 <tomsmeding> or some model of that
2023-12-14 21:06:49 +0100m1dnight_(~christoph@78-22-4-67.access.telenet.be) (Client Quit)
2023-12-14 21:07:05 +0100 <tomsmeding> turns out there's a neat approximation that explains most of these shenanigans, i.e. (I think) monochrom's "operational model"
2023-12-14 21:08:08 +0100juri_(~juri@79.140.115.48) (Ping timeout: 256 seconds)
2023-12-14 21:08:11 +0100 <int-e> The point goes deeper though, you need an operational model to use `seq` effectively.
2023-12-14 21:08:45 +0100 <tomsmeding> is it surprising that you need something that is more precise than the standard if the standard doesn't pin down the operational behaviour you're trying to influence? :p
2023-12-14 21:08:53 +0100 <int-e> Because in the end it's just a tweak of the order of evaluation.
2023-12-14 21:09:06 +0100 <Joao003> What does `seq' do? I don't know.
2023-12-14 21:09:35 +0100juri_(~juri@implicitcad.org)
2023-12-14 21:09:39 +0100 <int-e> as a first approximation, not entirely correct, a `seq` b evaluates a before returning the value of b.
2023-12-14 21:09:49 +0100 <monochrom> In this context, I am surprised that people use the standard to FUD against talking operationally.
2023-12-14 21:10:05 +0100 <int-e> (`pseq` intends to do exactly that, but the difference between pseq and seq is really quite subtle)
2023-12-14 21:10:30 +0100 <tomsmeding> Joao003: "a `seq` b" evaluates a and b (in some order), and then returns b
2023-12-14 21:10:49 +0100 <int-e> (so subtle, I don't quite know how to explain it without talking about strictness analysis in the compiler)
2023-12-14 21:11:02 +0100 <Joao003> % putStrLn "a" `seq` putStrLn "b"
2023-12-14 21:11:02 +0100 <yahb2> b
2023-12-14 21:11:11 +0100 <mauke> it took me a while to understand why pseq can't be implemented in terms of seq
2023-12-14 21:11:20 +0100 <tomsmeding> "evaluate" as in "force this lazy-evaluated thing"
2023-12-14 21:11:23 +0100 <tomsmeding> not as in "do IO"
2023-12-14 21:11:23 +0100 <Joao003> % (putStrLn "a") `seq` (putStrLn "b")
2023-12-14 21:11:23 +0100 <yahb2> b
2023-12-14 21:11:38 +0100 <tomsmeding> % error "oops!" `seq` 10
2023-12-14 21:11:38 +0100 <yahb2> *** Exception: oops! ; CallStack (from HasCallStack): ; error, called at <interactive>:31:1 in interactive:Ghci5
2023-12-14 21:11:51 +0100 <tomsmeding> % let unused = error "oops!" in 10
2023-12-14 21:11:51 +0100 <yahb2> 10
2023-12-14 21:11:58 +0100 <tomsmeding> % let unused = error "oops!" in unused `seq` 10
2023-12-14 21:11:58 +0100 <yahb2> *** Exception: oops! ; CallStack (from HasCallStack): ; error, called at <interactive>:35:14 in interactive:Ghci6
2023-12-14 21:12:12 +0100 <tomsmeding> % let unused = "safe" in unused `seq` 10
2023-12-14 21:12:13 +0100 <yahb2> 10
2023-12-14 21:12:13 +0100 <Joao003> % let unused = error "oops!" in const unused 10
2023-12-14 21:12:13 +0100 <yahb2> *** Exception: oops! ; CallStack (from HasCallStack): ; error, called at <interactive>:39:14 in interactive:Ghci7
2023-12-14 21:12:18 +0100 <geekosaur> Joao003, don't confuse evaluation with execution. `seq` doesn't execute anything, so you won't see "a" printed
2023-12-14 21:12:39 +0100 <int-e> > const 10 undefined -- do you have the arguments in the right order?
2023-12-14 21:12:41 +0100 <lambdabot> 10
2023-12-14 21:12:45 +0100 <EvanR> > error "1" `seq` error "2"
2023-12-14 21:12:46 +0100 <lambdabot> *Exception: 1
2023-12-14 21:12:53 +0100 <Joao003> % let unused = error "oops!" in const 10 unuse
2023-12-14 21:12:53 +0100 <yahb2> <interactive>:41:40: error: ; • Variable not in scope: unuse ; • Perhaps you meant ‘unused’ (line 41)
2023-12-14 21:12:55 +0100 <Joao003> % let unused = error "oops!" in const 10 unused
2023-12-14 21:12:55 +0100 <yahb2> 10
2023-12-14 21:13:33 +0100 <EvanR> % error "1" `seq` error "2"
2023-12-14 21:13:33 +0100 <yahb2> *** Exception: 1 ; CallStack (from HasCallStack): ; error, called at <interactive>:45:1 in interactive:Ghci8
2023-12-14 21:13:53 +0100 <mauke> (seq a b) is a value that has a spurious data dependency on a (and a non-spurious dependency on b)
2023-12-14 21:14:07 +0100 <Joao003> If you had to use \x y -> y, would you do `const id' or `flip const'?
2023-12-14 21:14:30 +0100 <EvanR> or something from aviary bird combinators
2023-12-14 21:14:47 +0100 <tomsmeding> \_ y -> y
2023-12-14 21:14:53 +0100 <mauke> chaotic evil: pure ask
2023-12-14 21:14:53 +0100alp__(~alp@2001:861:e3d6:8f80:f550:1f70:2377:c233) (Ping timeout: 256 seconds)
2023-12-14 21:15:05 +0100 <mauke> actually, that's probably the wrong type
2023-12-14 21:15:17 +0100 <tomsmeding> no need to save one character and type "const id" instead of "\_ y -> y"
2023-12-14 21:15:23 +0100 <EvanR> :t const id
2023-12-14 21:15:24 +0100 <lambdabot> b -> a -> a
2023-12-14 21:15:29 +0100 <EvanR> kite :: a -> b -> b
2023-12-14 21:15:41 +0100 <Joao003> chaotic eviler: seq
2023-12-14 21:15:45 +0100 <EvanR> Ki - kite. Corresponds to the encoding of false in the lambda calculus.
2023-12-14 21:15:51 +0100 <tomsmeding> has someone already made that @pl alternative that uses only birds
2023-12-14 21:16:19 +0100 <Joao003> holy now i want that
2023-12-14 21:16:29 +0100 <int-e> tomsmeding: ap const and id?
2023-12-14 21:17:11 +0100 <tomsmeding> int-e: hm?
2023-12-14 21:17:12 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:7854:33e:c79:490a) (Remote host closed the connection)
2023-12-14 21:17:15 +0100 <int-e> (I blame @pl for the fact that I've internalized ap = S. const = K and id = I are more obvious.)
2023-12-14 21:17:17 +0100 <tomsmeding> :t ap const and id
2023-12-14 21:17:18 +0100 <lambdabot> error:
2023-12-14 21:17:18 +0100 <lambdabot> • No instance for (Foldable ((->) Bool))
2023-12-14 21:17:18 +0100 <lambdabot> arising from a use of ‘and’
2023-12-14 21:17:44 +0100 <mauke> :t pure $fix$ pure
2023-12-14 21:17:45 +0100 <lambdabot> error:
2023-12-14 21:17:45 +0100 <lambdabot> • Occurs check: cannot construct the infinite type: a ~ f1 a
2023-12-14 21:17:45 +0100 <lambdabot> Expected type: f1 a -> f1 a
2023-12-14 21:17:48 +0100 <int-e> tomsmeding: no, `and` was from the english language. I should've added commas. And/or maybe backticks.
2023-12-14 21:17:52 +0100 <EvanR> starling kestrel and idiot xD
2023-12-14 21:17:59 +0100phma_(phma@2001:5b0:211f:ca48:659b:29e6:dda5:53ee)
2023-12-14 21:18:07 +0100 <int-e> . o O ( idiom bird )
2023-12-14 21:18:17 +0100 <tomsmeding> int-e: then I initially parsed your message correctly but I still don't know what you meant :p
2023-12-14 21:18:23 +0100 <int-e> Which, of course, would be `ap`, just to add to the confusion.
2023-12-14 21:18:46 +0100 <int-e> ap = (<*>) which is the core primitive of Applicative = Idiom
2023-12-14 21:19:03 +0100 <int-e> pure is just their to make a point
2023-12-14 21:19:04 +0100 <int-e> *there
2023-12-14 21:19:09 +0100 <tomsmeding> :p
2023-12-14 21:19:15 +0100 <tomsmeding> OH
2023-12-14 21:19:22 +0100 <mauke> :t pure $fix<$> pure
2023-12-14 21:19:24 +0100 <lambdabot> Applicative f => f (b -> b)
2023-12-14 21:19:24 +0100 <tomsmeding> it was a list with three elements
2023-12-14 21:19:28 +0100tomsmedingnow understands
2023-12-14 21:19:44 +0100iqubic(~avi@2601:602:9502:c70:ace6:f806:3e8:12)
2023-12-14 21:19:48 +0100 <EvanR> but how many commas would you need
2023-12-14 21:19:53 +0100 <tomsmeding> one
2023-12-14 21:19:57 +0100 <int-e> tomsmeding: I can't blame you, as I said, I should've used more punctuation
2023-12-14 21:19:58 +0100phma(phma@2001:5b0:210f:1c58:794a:9822:66f3:ee9) (Read error: Connection reset by peer)
2023-12-14 21:20:09 +0100 <tomsmeding> two, if you're feeling smug
2023-12-14 21:20:17 +0100 <EvanR> ap, const, and id,
2023-12-14 21:20:18 +0100 <int-e> EvanR: if oxford then 2 else 1
2023-12-14 21:20:19 +0100 <mauke> ap,, const and id
2023-12-14 21:20:31 +0100 <EvanR> putting a trailing comma is all the rage these days
2023-12-14 21:20:34 +0100 <tomsmeding> % let oxford = \_ y -> y
2023-12-14 21:20:34 +0100 <yahb2> <no output>
2023-12-14 21:20:39 +0100 <int-e> EvanR: in English?
2023-12-14 21:20:43 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-12-14 21:20:45 +0100 <iqubic> what did I miss here?
2023-12-14 21:20:48 +0100 <EvanR> in language of the week
2023-12-14 21:20:50 +0100 <int-e> :t (1,2,) -- still not a pair
2023-12-14 21:20:51 +0100 <lambdabot> (Num t1, Num t2) => t3 -> (t1, t2, t3)
2023-12-14 21:21:05 +0100 <Joao003> (,) ap $ (,) const id
2023-12-14 21:21:10 +0100 <int-e> iqubic: we were talking about birds
2023-12-14 21:21:17 +0100int-eruns
2023-12-14 21:21:22 +0100 <monochrom> Revisionist history: [s,k] = [ap, pure] for Applicative, is that why functional programming was called applicative programming? >:)
2023-12-14 21:21:23 +0100 <int-e> (there are logs)
2023-12-14 21:21:39 +0100 <mauke> bird tracks are used in .lhs files
2023-12-14 21:21:48 +0100 <probie> I like the clojure/graphql approach - the comma is another whitespace character
2023-12-14 21:21:56 +0100 <EvanR> bird combinators are intended for illustration (and the type signatures) and not utility. That would be the batman combinator
2023-12-14 21:22:01 +0100 <int-e> mauke: unless they're wrapped in latex
2023-12-14 21:22:03 +0100 <iqubic> monochrom: Is that real?
2023-12-14 21:22:16 +0100 <mauke> no, revisionist
2023-12-14 21:22:18 +0100 <monochrom> s/for Applicative// # that was a typo and also made the whole thing confusing.
2023-12-14 21:22:57 +0100 <monochrom> Well the whole sentence "The following is revisionist history: ..." is true honest and real.
2023-12-14 21:22:59 +0100 <tomsmeding> I appreciate that you used the contextually correct (sed) comment marker
2023-12-14 21:23:10 +0100 <mauke> s/sed/perl/
2023-12-14 21:23:15 +0100 <tomsmeding> sed
2023-12-14 21:23:48 +0100 <iqubic> Speaking of birds:
2023-12-14 21:23:58 +0100 <iqubic> @hackage aviary
2023-12-14 21:23:58 +0100 <lambdabot> https://hackage.haskell.org/package/aviary
2023-12-14 21:23:59 +0100 <mauke> perl is a supersed
2023-12-14 21:24:03 +0100 <iqubic> https://hackage.haskell.org/package/data-aviary
2023-12-14 21:24:08 +0100 <iqubic> It's actually that.
2023-12-14 21:24:12 +0100 <EvanR> ikr
2023-12-14 21:24:13 +0100 <int-e> mauke: awk-ward
2023-12-14 21:24:22 +0100 <tomsmeding> iqubic: that was what this bird stuff was inspired by ;)
2023-12-14 21:24:39 +0100trev(~trev@user/trev) (Quit: trev)
2023-12-14 21:25:01 +0100 <EvanR> the original question is how to say \x y -> y
2023-12-14 21:25:10 +0100 <EvanR> other than that way I guess
2023-12-14 21:25:15 +0100 <monochrom> flip pure >:)
2023-12-14 21:25:21 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
2023-12-14 21:25:45 +0100 <EvanR> :t flip pure
2023-12-14 21:25:46 +0100 <lambdabot> b -> c -> c
2023-12-14 21:25:55 +0100 <mauke> :t [const id, flip const, pure $fix<$> pure]
2023-12-14 21:25:56 +0100 <lambdabot> [b -> a -> a]
2023-12-14 21:26:02 +0100 <EvanR> touché
2023-12-14 21:26:15 +0100 <iqubic> :t const
2023-12-14 21:26:15 +0100 <monochrom> ooohhh const id is a surprise
2023-12-14 21:26:16 +0100 <lambdabot> a -> b -> a
2023-12-14 21:26:25 +0100 <int-e> :t ap const
2023-12-14 21:26:26 +0100 <lambdabot> (b -> a) -> b -> b
2023-12-14 21:26:33 +0100 <tomsmeding> monochrom: it's the only one yet that is shorter than '\_ y -> y'
2023-12-14 21:26:42 +0100 <Joao003> map (\f -> f 1 2) [const id, flip const, pure $fix<$> pure]
2023-12-14 21:26:47 +0100 <EvanR> kite is shorter
2023-12-14 21:26:47 +0100 <Joao003> > map (\f -> f 1 2) [const id, flip const, pure $fix<$> pure]
2023-12-14 21:26:49 +0100 <lambdabot> [2,2,2]
2023-12-14 21:26:50 +0100 <int-e> (that is \x y -> y but the type is restricted, isn't it beautiful)
2023-12-14 21:26:56 +0100 <Joao003> > map (\f -> f 1 2) [const id, flip const, pure $fix<$> pure, flip pure]
2023-12-14 21:26:58 +0100 <lambdabot> [2,2,2,2]
2023-12-14 21:27:08 +0100 <mauke> flip const = flip pure
2023-12-14 21:27:11 +0100 <mauke> since pure = const
2023-12-14 21:27:19 +0100 <iqubic> monochrom: const id x y = (const id x) y = id y = y
2023-12-14 21:27:32 +0100 <Joao003> How is pure const then, mauke?
2023-12-14 21:27:38 +0100 <int-e> > pure "bs" :: [String]
2023-12-14 21:27:39 +0100 <lambdabot> ["bs"]
2023-12-14 21:27:47 +0100 <mauke> Joao003: instance Applicative ((->) e)
2023-12-14 21:27:57 +0100 <iqubic> > pure 1 2
2023-12-14 21:27:58 +0100 <monochrom> But I'm more interested in using pure and id to freak out people "wait why are they even relevant?!" >:)
2023-12-14 21:27:58 +0100 <lambdabot> 1
2023-12-14 21:28:03 +0100 <Joao003> pure 1 2
2023-12-14 21:28:08 +0100 <Joao003> > pure 1 2
2023-12-14 21:28:09 +0100 <lambdabot> 1
2023-12-14 21:28:14 +0100 <Joao003> :t pure 1
2023-12-14 21:28:15 +0100 <lambdabot> (Applicative f, Num a) => f a
2023-12-14 21:28:23 +0100 <iqubic> > pure id 1 2
2023-12-14 21:28:25 +0100 <lambdabot> 2
2023-12-14 21:28:39 +0100 <mauke> let f = ((->) e), then f a = (->) e a = e -> a
2023-12-14 21:28:50 +0100 <Joao003> > pure [1] [2]
2023-12-14 21:28:52 +0100 <lambdabot> [1]
2023-12-14 21:28:53 +0100 <EvanR> > id id id id 2
2023-12-14 21:28:54 +0100 <lambdabot> 2
2023-12-14 21:28:55 +0100 <tomsmeding> ooh, that would be the shortest (pure id)
2023-12-14 21:28:58 +0100 <tomsmeding> (ignoring kite)
2023-12-14 21:29:10 +0100 <EvanR> kite sad
2023-12-14 21:29:14 +0100 <tomsmeding> sorry kite
2023-12-14 21:29:15 +0100 <iqubic> @check \x y -> pure x y == pure id x y
2023-12-14 21:29:16 +0100 <lambdabot> +++ OK, passed 100 tests.
2023-12-14 21:29:20 +0100 <int-e> > curry snd
2023-12-14 21:29:21 +0100 <lambdabot> error:
2023-12-14 21:29:21 +0100 <lambdabot> • No instance for (Typeable a0)
2023-12-14 21:29:21 +0100 <lambdabot> arising from a use of ‘show_M10958710501189713508’
2023-12-14 21:29:24 +0100 <int-e> :t curry snd
2023-12-14 21:29:24 +0100 <monochrom> In particular the equation "flip pure = pure id" is on the order of "2+2 = 2*2 = 2^2" :)
2023-12-14 21:29:25 +0100 <lambdabot> a -> c -> c
2023-12-14 21:29:32 +0100 <mauke> nice
2023-12-14 21:29:44 +0100 <int-e> (adds some spice)
2023-12-14 21:29:50 +0100 <mauke> I like my curry without sand
2023-12-14 21:30:09 +0100 <int-e> but how else do you get the extra crunchiness
2023-12-14 21:30:13 +0100danza(~danza@151.19.239.57) (Ping timeout: 268 seconds)
2023-12-14 21:30:17 +0100 <monochrom> :( haha
2023-12-14 21:30:30 +0100 <iqubic> I love quick check. I wonder if it's actually testing the thing correctly.
2023-12-14 21:30:36 +0100 <EvanR> in 10023 they will look at our code (and unix commands) and wonder what happened to the vowels
2023-12-14 21:30:52 +0100 <mauke> iqubic: probably using () as the type
2023-12-14 21:30:52 +0100 <EvanR> as in egyptian
2023-12-14 21:30:53 +0100Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds)
2023-12-14 21:30:58 +0100 <tomsmeding> @check \x y -> pure (x :: Int) (y :: Int) == pure id x y
2023-12-14 21:31:00 +0100 <lambdabot> *** Failed! Falsifiable (after 2 tests and 1 shrink):
2023-12-14 21:31:00 +0100 <lambdabot> -1 0
2023-12-14 21:31:07 +0100 <monochrom> Oh my unix-and-c students are already wondering about that.
2023-12-14 21:31:16 +0100 <tomsmeding> @check \x y -> pure (x :: ()) (y :: ()) == pure id x y
2023-12-14 21:31:17 +0100 <lambdabot> +++ OK, passed 100 tests.
2023-12-14 21:31:34 +0100 <mauke> uneiform
2023-12-14 21:31:40 +0100 <iqubic> Why did it fail when you specialize to Int?
2023-12-14 21:31:46 +0100 <Joao003> > pure id 1 2
2023-12-14 21:31:48 +0100 <lambdabot> 2
2023-12-14 21:31:52 +0100 <Joao003> > pure id [1] [2]
2023-12-14 21:31:54 +0100 <lambdabot> [2]
2023-12-14 21:31:56 +0100 <tomsmeding> because pure == const and pure id == flip const
2023-12-14 21:32:03 +0100 <tomsmeding> and it was using () before, probably, due to defaulting
2023-12-14 21:32:08 +0100 <int-e> iqubic: does it have to do with univalency? I'll show myself out.
2023-12-14 21:32:18 +0100 <mauke> @check \x y -> x == y
2023-12-14 21:32:19 +0100 <lambdabot> +++ OK, passed 100 tests.
2023-12-14 21:32:23 +0100 <Joao003> tomsmeding AND WHY IS PURE == CONST
2023-12-14 21:32:26 +0100 <iqubic> Oh. It was a false postive
2023-12-14 21:32:31 +0100 <tomsmeding> Joao003: BECAUSE IT ISNT
2023-12-14 21:32:35 +0100 <tomsmeding> oh
2023-12-14 21:32:35 +0100 <tomsmeding> it is
2023-12-14 21:32:37 +0100 <tomsmeding> I misread
2023-12-14 21:32:44 +0100 <int-e> const is pure, but pure isn't const
2023-12-14 21:32:45 +0100 <tomsmeding> because (r ->) is a monad
2023-12-14 21:32:51 +0100 <EvanR> pure = const if f = (->) r
2023-12-14 21:33:19 +0100 <iqubic> Please never use do notation with Monad ((->] r(
2023-12-14 21:33:36 +0100 <EvanR> you don't like Reader?
2023-12-14 21:33:49 +0100 <iqubic> Wait?!?! That's just Reader?!?!
2023-12-14 21:33:51 +0100 <iqubic> How?!?!
2023-12-14 21:33:54 +0100 <EvanR> lol
2023-12-14 21:33:56 +0100 <probie> Yes
2023-12-14 21:33:56 +0100 <iqubic> TIL.
2023-12-14 21:34:12 +0100 <tomsmeding> @unmtl Reader r a
2023-12-14 21:34:12 +0100 <monochrom> Reader is a newtype wrapper around (->)r.
2023-12-14 21:34:12 +0100 <lambdabot> r -> a
2023-12-14 21:34:28 +0100 <monochrom> "newtype Reader a = Ctor (r -> a)
2023-12-14 21:34:39 +0100 <monochrom> At least in old versions of the library.
2023-12-14 21:34:44 +0100 <Joao003> @src Reader
2023-12-14 21:34:44 +0100 <lambdabot> type Reader r = ReaderT r Identity
2023-12-14 21:34:44 +0100 <lambdabot> --OR
2023-12-14 21:34:44 +0100 <lambdabot> data Reader r a = Reader { runReader :: r -> a }
2023-12-14 21:34:54 +0100 <EvanR> DependencyInjection r a
2023-12-14 21:35:19 +0100 <probie> "dependency injection" - you mean taking an additional parameter
2023-12-14 21:35:25 +0100 <iqubic> What do the types of join and (>>=) look like when you specialize to m = ((->) r)?
2023-12-14 21:35:37 +0100 <tomsmeding> :t (>>=)
2023-12-14 21:35:38 +0100 <lambdabot> Monad m => m a -> (a -> m b) -> m b
2023-12-14 21:35:40 +0100 <monochrom> But it turns out that you don't need the newtype wrapper in principle.
2023-12-14 21:35:45 +0100 <tomsmeding> (r -> a) -> (a -> r -> b) -> r -> b
2023-12-14 21:35:51 +0100 <EvanR> taking an additional parameter, how pedestrian
2023-12-14 21:36:05 +0100 <iqubic> what does join look like?
2023-12-14 21:36:10 +0100 <tomsmeding> @pl \f g r -> g (f r) r
2023-12-14 21:36:10 +0100 <lambdabot> flip flip id . (ap .) . flip (.)
2023-12-14 21:36:11 +0100 <EvanR> do not disrespect the UML diagrams
2023-12-14 21:36:16 +0100 <mauke> iqubic: join f x = f x x
2023-12-14 21:36:17 +0100 <iqubic> :t join
2023-12-14 21:36:18 +0100 <lambdabot> Monad m => m (m a) -> m a
2023-12-14 21:36:20 +0100 <probie> (>>=) :: (b -> a) -> (a -> b -> c) -> (b -> c)
2023-12-14 21:36:23 +0100 <int-e> EvanR: user mode linux has diagrams?
2023-12-14 21:36:29 +0100 <tomsmeding> (r -> r -> a) -> r -> a
2023-12-14 21:36:35 +0100 <tomsmeding> % join (+) 3
2023-12-14 21:36:36 +0100 <yahb2> <interactive>:63:1: error: ; Variable not in scope: join :: (a0 -> a0 -> a0) -> t0 -> t
2023-12-14 21:36:40 +0100 <tomsmeding> > join (+) 3
2023-12-14 21:36:41 +0100 <lambdabot> 6
2023-12-14 21:36:44 +0100 <Joao003> tomsmeding: I was going to say that
2023-12-14 21:36:46 +0100 <haskellbridge> 12<C​elestial> UML diagrams 😭😭😭
2023-12-14 21:37:07 +0100 <haskellbridge> 12<C​elestial> I have a whole module dedicated to that in uni ... it sucks
2023-12-14 21:37:15 +0100 <int-e> @quote UML
2023-12-14 21:37:15 +0100 <lambdabot> ScottAaronson says: One of the best predictors of success in mathematical logic is having an umlaut in your name.
2023-12-14 21:37:22 +0100 <iqubic> join f x = f x x
2023-12-14 21:37:24 +0100 <monochrom> hahaha
2023-12-14 21:37:29 +0100Maxdamantus(~Maxdamant@user/maxdamantus)
2023-12-14 21:37:34 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection)
2023-12-14 21:38:03 +0100 <Joao003> @quote Haskell
2023-12-14 21:38:03 +0100 <lambdabot> Haskell says: "Some half dozen persons have written technically on combinatory logic, and most of these, including ourselves, have published something erroneous. Since some of our fellow sinners are
2023-12-14 21:38:03 +0100 <lambdabot> among the most careful and competent logicians on the contemporary scene, we regard this as evidence that the subject is refractory. " -- Haskell B. Curry
2023-12-14 21:38:23 +0100 <iqubic> That's just the W combinator.
2023-12-14 21:38:36 +0100 <mauke> I'll take that W
2023-12-14 21:38:41 +0100 <Joao003> Haha
2023-12-14 21:38:44 +0100 <iqubic> join for ((->) r) is just the W combinator
2023-12-14 21:39:17 +0100 <Joao003> More combinators: fix is Y
2023-12-14 21:39:18 +0100 <tomsmeding> pity that (>>=) and (>=>) don't become a neat combinator
2023-12-14 21:39:44 +0100 <mauke> join: \c x -> c x x
2023-12-14 21:39:46 +0100 <monochrom> I'm sure there is a letter left for it if we add it now.
2023-12-14 21:39:53 +0100 <mauke> (<*>): \c g x -> c x (g x)
2023-12-14 21:40:02 +0100 <haskellbridge> 12<C​elestial> isn't `f >>= g = \x -> g (f x) x`
2023-12-14 21:40:05 +0100 <mauke> (=<<): \c f x -> c (f x) x
2023-12-14 21:40:12 +0100 <tomsmeding> Celestial: true
2023-12-14 21:40:19 +0100 <mauke> liftA2: \c f g x -> c (f x) (g x)
2023-12-14 21:40:54 +0100 <int-e> Y does nobody teach T? (T = T0 T0 where T0 = \t0 f -> f (t0 t0 f), and you actually get T f -> f (T f) with no awkward backward step)
2023-12-14 21:41:03 +0100 <haskellbridge> 12<C​elestial> monochrom: maybe an umlaut, so that all the english people will have trouble typing it
2023-12-14 21:41:13 +0100 <Joao003> What is the type of <*> for f as (->) r?
2023-12-14 21:41:25 +0100 <tomsmeding> S
2023-12-14 21:41:56 +0100tri_(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 268 seconds)
2023-12-14 21:41:56 +0100 <mauke> hence: (=<<) c f = liftA2 c f id; (<*>) c g = liftA2 c id g
2023-12-14 21:42:03 +0100 <monochrom> (r -> a -> b) -> (r -> a) -> (r -> b)
2023-12-14 21:42:12 +0100 <Joao003> (r -> a -> b) -> (r -> a) -> r -> b
2023-12-14 21:42:32 +0100 <haskellbridge> 12<C​elestial> rabrarb
2023-12-14 21:42:48 +0100danza(~danza@151.47.209.192)
2023-12-14 21:45:27 +0100 <EvanR> % :t (<*>) @((->) Int)
2023-12-14 21:45:27 +0100 <yahb2> (<*>) @((->) Int) :: (Int -> (a -> b)) -> (Int -> a) -> Int -> b
2023-12-14 21:45:36 +0100 <Joao003> return and pure are the stupidest names for functions ever
2023-12-14 21:45:54 +0100 <EvanR> they both make sense given suitable context
2023-12-14 21:45:55 +0100 <iqubic> pure is a good name. return is just shit.
2023-12-14 21:46:09 +0100 <tomsmeding> should have called them η
2023-12-14 21:46:15 +0100 <EvanR> return makes your code look like imperative code
2023-12-14 21:46:20 +0100 <Joao003> True
2023-12-14 21:46:22 +0100 <EvanR> pure indicates there's no effect
2023-12-14 21:46:25 +0100 <probie> int-e: I remember tutoring some students at my local university, and in their lambda calculus section either this year, or last year (time is a blur), that was the fixed point combinator they used (previous iterations of the course used Y)
2023-12-14 21:46:25 +0100 <Joao003> Yes
2023-12-14 21:46:26 +0100 <tomsmeding> "warm fuzzy thing" -- SPJ
2023-12-14 21:46:36 +0100 <Joao003> I'd call it wrap
2023-12-14 21:46:42 +0100 <int-e> probie: cool!
2023-12-14 21:46:49 +0100 <iqubic> I want GHC to make the Monad of No Return a real thing.
2023-12-14 21:46:51 +0100 <monochrom> Meaningful names are the stupidest names ever.
2023-12-14 21:47:13 +0100 <Joao003> Every single person ever: no
2023-12-14 21:47:51 +0100 <monochrom> What you want is mnemonic names (and especially admitting that they should not be taken literally).
2023-12-14 21:47:57 +0100 <iqubic> I just looked at my code for Advent of Code and found a function called loeb. I don't know why this function works, but I know how to use it.
2023-12-14 21:48:07 +0100 <probie> How about pointed-joinable functors?
2023-12-14 21:48:47 +0100 <mauke> I call it "cons"
2023-12-14 21:48:51 +0100 <iqubic> loeb :: Functor f => f (f a -> a) -> f a
2023-12-14 21:48:59 +0100 <iqubic> loeb x = go where go = fmap ($ go) x
2023-12-14 21:49:18 +0100 <EvanR> seems like you can understand how it works by equational reasoning
2023-12-14 21:49:26 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection)
2023-12-14 21:49:35 +0100 <mauke> I remember that one. the spreadsheet combinator
2023-12-14 21:49:38 +0100 <EvanR> since there's no seq in there xD
2023-12-14 21:49:49 +0100 <iqubic> loeb x = let go = fmap (\f -> f go) x in go
2023-12-14 21:49:49 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-12-14 21:49:58 +0100 <Joao003> fmap is composition under (->) r
2023-12-14 21:50:04 +0100 <monochrom> tomsmeding: For decades I had not memorized which one is η which one is µ. Recently I realized "µ -> m -> multiply" so that must be join and so the other must be pure. :)
2023-12-14 21:50:22 +0100 <haskellbridge> 12<C​elestial> iqubic: why would you have the let bind there?
2023-12-14 21:50:36 +0100 <mauke> recursion
2023-12-14 21:50:38 +0100 <haskellbridge> 12<C​elestial> oh I see, I think
2023-12-14 21:51:08 +0100 <iqubic> You don't need let binding
2023-12-14 21:51:09 +0100 <mauke> missed opportunity to use flip id, though
2023-12-14 21:51:10 +0100 <tomsmeding> monochrom: yes :) I noticed that a bit earlier fortunately
2023-12-14 21:51:20 +0100 <monochrom> You want to reuse whatever data structure go is. This is memoization.
2023-12-14 21:51:23 +0100 <EvanR> @pl f x = let go = fmap (\f -> f go) x in go
2023-12-14 21:51:23 +0100 <lambdabot> f = fix . flip (fmap . flip id)
2023-12-14 21:51:37 +0100 <mauke> see? pl agrees
2023-12-14 21:51:44 +0100 <iqubic> Thanks... I hate it!!!
2023-12-14 21:52:02 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 21:52:03 +0100 <Joao003> @check \f g x -> fmap f g x == (f . g) x
2023-12-14 21:52:05 +0100 <lambdabot> error:
2023-12-14 21:52:05 +0100 <lambdabot> • No instance for (Typeable a0) arising from a use of ‘myquickcheck’ • In th...
2023-12-14 21:52:08 +0100 <iqubic> @pl loeb x = go where go = fmap ($ go) x
2023-12-14 21:52:08 +0100 <lambdabot> (line 1, column 23):
2023-12-14 21:52:08 +0100 <lambdabot> unexpected " "
2023-12-14 21:52:08 +0100 <lambdabot> expecting operator
2023-12-14 21:52:18 +0100 <Franciman> why doesn't ghc implement fully lazy sharing by default?
2023-12-14 21:52:22 +0100 <Joao003> @check \f g x -> (fmap f g x) == ((f . g) x)
2023-12-14 21:52:22 +0100 <EvanR> that command was pointless
2023-12-14 21:52:23 +0100 <Franciman> but only when optimizing?
2023-12-14 21:52:24 +0100 <lambdabot> error:
2023-12-14 21:52:24 +0100 <lambdabot> • No instance for (Typeable a0) arising from a use of ‘myquickcheck’ • In th...
2023-12-14 21:52:36 +0100 <mauke> :t fmap fix (flip (fmap fmap (flip id)))
2023-12-14 21:52:36 +0100 <iqubic> @pl \f x -> go where go = fmap ($ go) x
2023-12-14 21:52:36 +0100 <lambdabot> (line 1, column 22):
2023-12-14 21:52:36 +0100 <lambdabot> unexpected " "
2023-12-14 21:52:36 +0100 <lambdabot> expecting operator
2023-12-14 21:52:37 +0100 <lambdabot> Functor f => f (f b -> b) -> f b
2023-12-14 21:52:40 +0100 <monochrom> iqubic: https://www.vex.net/~trebla/tmp/Loeb.hs is my own study notes on loeb.
2023-12-14 21:52:41 +0100 <Franciman> well, actually when optimizing the docs says it still doesn't fully use fully lazy sharing
2023-12-14 21:52:55 +0100 <EvanR> fully lazy sharing = full laziness?
2023-12-14 21:53:02 +0100 <Franciman> sì
2023-12-14 21:53:04 +0100 <Franciman> yes
2023-12-14 21:53:06 +0100 <Franciman> :P sorry
2023-12-14 21:53:31 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:7854:33e:c79:490a)
2023-12-14 21:53:49 +0100 <iqubic> moeb :: (((a -> b) -> b) -> c -> a) -> c -> a
2023-12-14 21:53:56 +0100 <iqubic> moeb f x = let go = f ($ go) x in go
2023-12-14 21:54:08 +0100 <Joao003> we need noeb now
2023-12-14 21:54:13 +0100 <iqubic> loeb = moeb fmap
2023-12-14 21:54:15 +0100 <probie> I've never actually worked out if löb in Haskell is actually related to löb's theroem, or if it's just that it looks superficially similar, with "provable in PA" replaced with an arbitrary functor
2023-12-14 21:54:53 +0100 <monochrom> I think no one have. :)
2023-12-14 21:55:03 +0100 <int-e> maybe you can trigger edwardk into explaining that one?
2023-12-14 21:55:09 +0100 <iqubic> probie: according to the Curry-Howard Isomorphism, they are the same.
2023-12-14 21:55:11 +0100 <iqubic> https://www.lesswrong.com/posts/jshdZw3xofq9wgE7T/a-proof-of-loeb-s-theorem-in-haskell
2023-12-14 21:55:23 +0100 <monochrom> ooohhh lazy evaluation applied to edwardk >:)
2023-12-14 21:55:33 +0100tri_(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 21:56:11 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 245 seconds)
2023-12-14 21:56:35 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-12-14 21:56:58 +0100 <monochrom> I don't think a post using Agda/Idris/Lean/... is understandable to a narrower audience.
2023-12-14 21:57:14 +0100 <monochrom> It is not like the post would make you write your own code in Agda.
2023-12-14 21:57:24 +0100 <monochrom> It just needs you to read and guess.
2023-12-14 21:57:34 +0100 <iqubic> Does moeb foldMap have any uses?
2023-12-14 21:57:48 +0100 <iqubic> @let moeb f x = let go = f ($ go) x in go
2023-12-14 21:57:50 +0100 <lambdabot> Defined.
2023-12-14 21:58:02 +0100 <iqubic> :t moeb foldMap
2023-12-14 21:58:03 +0100 <lambdabot> (Foldable t, Monoid a) => t (a -> a) -> a
2023-12-14 21:58:13 +0100Joao003(~Joao003@190.108.99.230) (Quit: Bye!)
2023-12-14 21:58:15 +0100 <iqubic> What?!??!
2023-12-14 21:58:28 +0100juri__(~juri@79.140.115.48)
2023-12-14 21:58:45 +0100 <probie> Is provability in PA a functor? I surely can't just `fmap (const PAIsSound) (proof that 1 = 1)`?
2023-12-14 21:59:07 +0100 <int-e> :t foldMap Endo
2023-12-14 21:59:07 +0100 <iqubic> :t foldl' (.) id
2023-12-14 21:59:08 +0100 <lambdabot> Foldable t => t (a -> a) -> Endo a
2023-12-14 21:59:09 +0100 <lambdabot> Foldable t => t (c -> c) -> c -> c
2023-12-14 21:59:23 +0100 <int-e> :t appEndo . foldMap Endo
2023-12-14 21:59:24 +0100 <lambdabot> Foldable t => t (a -> a) -> a -> a
2023-12-14 21:59:39 +0100 <iqubic> moeb foldMap is not quite any of those.
2023-12-14 21:59:56 +0100tri_(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 245 seconds)
2023-12-14 22:00:00 +0100 <tomsmeding> iqubic: isn't that just modus ponens
2023-12-14 22:00:08 +0100 <iqubic> What?
2023-12-14 22:00:10 +0100 <tomsmeding> oh, no
2023-12-14 22:00:17 +0100 <int-e> > appEndo (foldMap Endo [(+ -4),(*2)]) 23
2023-12-14 22:00:19 +0100 <lambdabot> error:
2023-12-14 22:00:19 +0100 <lambdabot> The operator ‘+’ [infixl 6] of a section
2023-12-14 22:00:19 +0100 <lambdabot> must have lower precedence than that of the operand,
2023-12-14 22:00:21 +0100 <tomsmeding> ignore what I said :)
2023-12-14 22:00:29 +0100 <int-e> > appEndo (foldMap Endo [(-4+),(*2)]) 23
2023-12-14 22:00:30 +0100 <lambdabot> 42
2023-12-14 22:00:50 +0100 <EvanR> t (a -> a) -> a seems to be impossible, unless bottom?
2023-12-14 22:00:58 +0100 <int-e> :t fix
2023-12-14 22:00:59 +0100 <lambdabot> (a -> a) -> a
2023-12-14 22:01:07 +0100 <int-e> :t fix . foldr (.) id
2023-12-14 22:01:08 +0100 <lambdabot> Foldable t => t (c -> c) -> c
2023-12-14 22:01:18 +0100 <iqubic> It's that, yeah.
2023-12-14 22:01:24 +0100 <EvanR> er
2023-12-14 22:01:26 +0100 <iqubic> Is that just bottom?
2023-12-14 22:01:39 +0100juri_(~juri@implicitcad.org) (Ping timeout: 252 seconds)
2023-12-14 22:01:48 +0100 <int-e> > fix . foldr (.) id $ [(1:), (2:)]
2023-12-14 22:01:50 +0100 <lambdabot> [1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2...
2023-12-14 22:02:03 +0100 <iqubic> What?!?!
2023-12-14 22:02:11 +0100 <mauke> > moeb foldMap [const "A", const "B", const "C"]
2023-12-14 22:02:13 +0100 <lambdabot> "ABC"
2023-12-14 22:02:22 +0100 <iqubic> How does that work?!?!
2023-12-14 22:02:30 +0100 <int-e> iqubic: it's called laziness
2023-12-14 22:02:31 +0100int-eruns
2023-12-14 22:02:45 +0100 <int-e> > fix ((1:) . (2:))
2023-12-14 22:02:46 +0100 <lambdabot> [1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2...
2023-12-14 22:02:51 +0100 <iqubic> I'm so confused. These are some strange loops we find oureself in.
2023-12-14 22:03:00 +0100 <int-e> > fix (\x -> 1:2:x)
2023-12-14 22:03:01 +0100 <lambdabot> [1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2...
2023-12-14 22:03:05 +0100 <mauke> > moeb foldMap [const "A", const "B", ('C' :)]
2023-12-14 22:03:07 +0100 <lambdabot> "ABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABCABC...
2023-12-14 22:03:50 +0100 <iqubic> > moeb foldMap [const "A", ('B' :), ('C' :)]
2023-12-14 22:03:51 +0100 <lambdabot> "ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABA...
2023-12-14 22:03:52 +0100maukeunderstands
2023-12-14 22:03:53 +0100 <int-e> :t moeb
2023-12-14 22:03:54 +0100 <lambdabot> (((a -> b) -> b) -> t -> a) -> t -> a
2023-12-14 22:04:26 +0100 <iqubic> How does foldMap have the right signature to work there?
2023-12-14 22:04:31 +0100 <iqubic> :t foldMap
2023-12-14 22:04:32 +0100 <lambdabot> (Foldable t, Monoid m) => (a -> m) -> t a -> m
2023-12-14 22:05:02 +0100 <iqubic> Oh... Is this using the Monoid instance for fuctions?
2023-12-14 22:05:15 +0100 <mauke> functions don't monoid
2023-12-14 22:05:27 +0100thegeekinside(~thegeekin@189.217.90.224)
2023-12-14 22:06:16 +0100 <mauke> but also, the result is a list
2023-12-14 22:06:20 +0100 <iqubic> https://hackage.haskell.org/package/base-4.19.0.0/docs/src/GHC.Base.html#line-398
2023-12-14 22:06:26 +0100 <iqubic> I think they do.
2023-12-14 22:06:27 +0100 <EvanR> though there is Monoid m => Monoid (a -> m)
2023-12-14 22:06:32 +0100 <mauke> there is? dang
2023-12-14 22:06:51 +0100 <mauke> m = [Char]
2023-12-14 22:07:55 +0100 <probie> m ~ [Char], a ~ ([Char] -> [Char]), t ~ []
2023-12-14 22:08:07 +0100juri__(~juri@79.140.115.48) (Ping timeout: 255 seconds)
2023-12-14 22:09:53 +0100 <iqubic> Can "moeb foldMap" produce anything that isn't infinite?
2023-12-14 22:09:58 +0100juri_(~juri@79.140.115.48)
2023-12-14 22:10:18 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 268 seconds)
2023-12-14 22:10:46 +0100 <int-e> > moeb foldMap [const "A"]
2023-12-14 22:10:48 +0100 <lambdabot> "A"
2023-12-14 22:10:52 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-12-14 22:11:01 +0100 <int-e> (it has been done above already)
2023-12-14 22:11:17 +0100 <int-e> specializing types, we have
2023-12-14 22:11:20 +0100 <int-e> moeb :: (Foldable t, Monoid m) => (((m -> m) -> m) -> t (m -> m) -> m) -> t (m -> m) -> m
2023-12-14 22:11:23 +0100 <int-e> foldMap :: (Foldable t, Monoid m) => ((m -> m) -> m) -> t (m -> m) -> m
2023-12-14 22:11:30 +0100 <iqubic> Can this be used to compute interesting results?
2023-12-14 22:11:41 +0100 <mauke> > moeb foldMap [const "A", const "B", pure . head]
2023-12-14 22:11:42 +0100 <lambdabot> "ABA"
2023-12-14 22:12:11 +0100 <iqubic> So, it's a spreadsheet, but it mappends the results?
2023-12-14 22:12:50 +0100phma_phma
2023-12-14 22:12:52 +0100 <mauke> yes
2023-12-14 22:12:58 +0100 <iqubic> > moeb foldMap [const "A", const "B", pure . last]
2023-12-14 22:13:00 +0100 <lambdabot> "AB*Exception: <<loop>>
2023-12-14 22:13:03 +0100 <EvanR> it's a spreadsheet? Does that mean it's just FRP? xD
2023-12-14 22:13:26 +0100 <mauke> > moeb foldMap [const "A", const "B", take 5]
2023-12-14 22:13:28 +0100 <lambdabot> "ABABABA"
2023-12-14 22:13:55 +0100 <iqubic> why does that work?
2023-12-14 22:14:18 +0100 <mauke> because 5/4 is a cool time signature
2023-12-14 22:14:27 +0100 <monochrom> Ooohhhh interesting. A spreadsheet serialized to one single string...
2023-12-14 22:14:39 +0100 <iqubic> What... It is?!? How?!?
2023-12-14 22:14:47 +0100 <monochrom> Haha damn you with your 5/4 time.
2023-12-14 22:15:01 +0100 <int-e> > moeb foldMap [take 5 . ('A':), take 5 . ('B':), take 15 . ('C':)]
2023-12-14 22:15:03 +0100 <lambdabot> "AAAAABAAAACAAAAABAAAACAAA"
2023-12-14 22:15:03 +0100juri_(~juri@79.140.115.48) (Read error: Connection reset by peer)
2023-12-14 22:15:07 +0100 <int-e> no clue wtf that really does
2023-12-14 22:15:09 +0100 <probie> > let x = mconcat $ map ($ x) [const "A", const "B", take 5] in x
2023-12-14 22:15:10 +0100 <lambdabot> "ABABABA"
2023-12-14 22:15:22 +0100 <monochrom> "ABABABA" = concat ["A", "B", "ABABA"]
2023-12-14 22:15:27 +0100juri_(~juri@79.140.115.48)
2023-12-14 22:15:51 +0100 <iqubic> > moeb foldMap [const "A", const "B", drop 5]
2023-12-14 22:15:53 +0100 <lambdabot> "AB*Exception: <<loop>>
2023-12-14 22:16:20 +0100 <mauke> you can't read ahead of the writer
2023-12-14 22:16:28 +0100 <iqubic> I see that now.
2023-12-14 22:16:48 +0100 <iqubic> oldMap [const "A", const "B", (!! 1)]
2023-12-14 22:16:57 +0100 <EvanR> you can only read ahead of the writer in the tardis monad
2023-12-14 22:16:59 +0100 <mauke> infinite type
2023-12-14 22:17:13 +0100 <iqubic> > moeb foldMap [const "A", const "B", (!! 1)]
2023-12-14 22:17:15 +0100 <lambdabot> error:
2023-12-14 22:17:15 +0100 <lambdabot> • Couldn't match type ‘Char’ with ‘[Char]’
2023-12-14 22:17:15 +0100 <lambdabot> Expected type: [Char] -> [Char]
2023-12-14 22:17:31 +0100 <iqubic> Why is that an infinite type?
2023-12-14 22:17:43 +0100 <mauke> solve Char = [Char] for Char
2023-12-14 22:17:53 +0100 <EvanR> the infinite type message is gone?
2023-12-14 22:17:59 +0100 <iqubic> > moeb foldMap [const "A", const "B", pure . (!! 1)]
2023-12-14 22:18:01 +0100 <lambdabot> "ABB"
2023-12-14 22:19:10 +0100 <mauke> :t \f -> [f, f ()]
2023-12-14 22:19:11 +0100 <lambdabot> error:
2023-12-14 22:19:11 +0100 <lambdabot> • Occurs check: cannot construct the infinite type: t ~ () -> t
2023-12-14 22:19:11 +0100 <lambdabot> • In the expression: f ()
2023-12-14 22:19:29 +0100 <mauke> :t \f -> [f, f !! 1]
2023-12-14 22:19:30 +0100 <lambdabot> error:
2023-12-14 22:19:30 +0100 <lambdabot> • Occurs check: cannot construct the infinite type: a ~ [a]
2023-12-14 22:19:30 +0100 <lambdabot> • In the expression: f !! 1
2023-12-14 22:19:31 +0100 <iqubic> This is just madness.
2023-12-14 22:19:45 +0100 <geekosaur> I think it is gone in later ghc though?
2023-12-14 22:19:58 +0100 <int-e> moeb foldMap [f, g, h] = [fix f, fix (g . (fix f <>)), fix (h . (fix (g . (fix f <>)) <>)] etc?
2023-12-14 22:20:06 +0100 <geekosaur> % :t \f -> [f, f !! 1]
2023-12-14 22:20:06 +0100 <yahb2> <interactive>:1:11: error: ; • Couldn't match expected type ‘[a]’ with actual type ‘a’ ; ‘a’ is a rigid type variable bound by ; the inferred type of it :: a -> [a] ; at <...
2023-12-14 22:20:26 +0100 <int-e> it's weird
2023-12-14 22:20:33 +0100 <mauke> int-e: I think there's only one fix
2023-12-14 22:20:34 +0100 <iqubic> What is the Dual newtype wrapper do?
2023-12-14 22:20:59 +0100rvalue(~rvalue@user/rvalue) (Ping timeout: 264 seconds)
2023-12-14 22:21:07 +0100rvalue-(~rvalue@user/rvalue)
2023-12-14 22:21:36 +0100 <iqubic> Oh. I see it just reverses the order of arguments to mappend
2023-12-14 22:22:14 +0100 <iqubic> (Dual x) <> (Dual y) = Dual (y <> x)
2023-12-14 22:22:44 +0100 <iqubic> mempty (Dual x) = Dual (mempty x)
2023-12-14 22:22:45 +0100 <int-e> Oh wait, `msum` that final list what I wrote.
2023-12-14 22:22:53 +0100 <int-e> mauke: no, there must be several
2023-12-14 22:23:05 +0100 <int-e> > take 10 $ moeb foldMap [('A':), ('B':)]
2023-12-14 22:23:07 +0100 <lambdabot> "AAAAAAAAAA"
2023-12-14 22:23:12 +0100 <int-e> > take 10 $ moeb foldMap [take 2 . ('A':), ('B':)]
2023-12-14 22:23:14 +0100 <lambdabot> "AABAABAABA"
2023-12-14 22:23:42 +0100 <mauke> why?
2023-12-14 22:23:47 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1)
2023-12-14 22:23:59 +0100 <int-e> > fix (take 2 . ('A':) . ('B':))
2023-12-14 22:24:01 +0100 <lambdabot> "AB"
2023-12-14 22:24:25 +0100 <mauke> x = mconcat (map ($ x) fs)
2023-12-14 22:24:27 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-12-14 22:24:30 +0100 <mauke> solve for x
2023-12-14 22:25:02 +0100rvalue-rvalue
2023-12-14 22:25:08 +0100 <lambdabot> *squawk*
2023-12-14 22:25:08 +0100 <EvanR> you would need a Group for that
2023-12-14 22:25:16 +0100 <int-e> > let x = mconcat (map ($ x) [take 2 . ('A':), ('B':)]) in take 10 x
2023-12-14 22:25:18 +0100 <lambdabot> "AABAABAABA"
2023-12-14 22:25:46 +0100 <iqubic> What does the ST of runST stand for?
2023-12-14 22:25:51 +0100 <mauke> state thread
2023-12-14 22:25:51 +0100 <int-e> fair enough I guess
2023-12-14 22:27:15 +0100 <iqubic> How does runST work?
2023-12-14 22:27:16 +0100 <int-e> mauke: but I wanted to get a better understanding of how the result is constructed using the functions from fs. In particular, if `fix (head fs)` is already infinite then the remaining functions won't ever get to run
2023-12-14 22:27:26 +0100 <int-e> magic
2023-12-14 22:27:42 +0100 <int-e> I mean, which answer do you want? What is your real question?
2023-12-14 22:28:19 +0100 <int-e> You can imagine a pure implementation of ST that uses stuff like Data.Array and Data.Map and some really awkward coercions.
2023-12-14 22:28:25 +0100 <iqubic> Is there anywhere I can go to look at the API for STArrays?
2023-12-14 22:29:09 +0100 <int-e> But the actual implementation in GHC is basically a restricted version of IO.
2023-12-14 22:29:54 +0100 <iqubic> I don't get what the magical `s' of `forall s. ST s' means...
2023-12-14 22:29:55 +0100 <int-e> With runST being like unsafePerformIO but safe because it only allocates memory and modifies memory created within the same action.
2023-12-14 22:30:31 +0100 <int-e> All mutable data associated with the state thread is tagged with `s`. You can't use it in any other state thread.
2023-12-14 22:30:32 +0100 <mauke> iqubic: that's a type system trick to make sure references allocated in one ST block cannot escape to other blocks
2023-12-14 22:32:01 +0100 <ncf> why did the robot say *squawk*
2023-12-14 22:32:04 +0100 <int-e> (It /can/ escape, but to do that you have to quantify `s` existentially and it won't unify with the `s` from any other `runST`)
2023-12-14 22:32:21 +0100 <mauke> the point of ST is to allow mutable variables, but only "inside". the final ST action as a whole must have a pure interface
2023-12-14 22:32:31 +0100 <iqubic> Oh. I see.
2023-12-14 22:32:32 +0100 <mauke> or in other words, the mutable variables of ST are all local
2023-12-14 22:32:59 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-12-14 22:33:02 +0100 <mauke> if you could allocate STRefs in one action, but read/write them in another, that would break purity
2023-12-14 22:33:59 +0100 <mauke> you could enforce that with a runtime check, but the s parameter (and the weird type of runST) turn violations of this property into a type error
2023-12-14 22:34:47 +0100 <iqubic> I see. That makes sense.
2023-12-14 22:34:58 +0100waldo(~waldo@user/waldo) (Ping timeout: 276 seconds)
2023-12-14 22:37:59 +0100juri_(~juri@79.140.115.48) (Read error: Connection reset by peer)
2023-12-14 22:38:54 +0100juri_(~juri@79.140.115.48)
2023-12-14 22:41:37 +0100 <EvanR> if you use impure techniques within a function in a way that no one can ever find out about it, then you can still claim you wrote a pure function. ST lets you do a safe limited form of that
2023-12-14 22:42:55 +0100 <int-e> EvanR: apparently "how does it work" was about the type, not the internal workings.
2023-12-14 22:45:14 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2023-12-14 22:45:59 +0100 <EvanR> unsafePerformIO is less limited and less safe, standard haskell code is more limited but not more safe than ST, ST is a win win, or a win tie
2023-12-14 22:46:13 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-12-14 22:48:18 +0100 <EvanR> see also the safe vs useless chart from SPJ "haskell is useless" xD
2023-12-14 22:48:50 +0100juri_(~juri@79.140.115.48) (Ping timeout: 268 seconds)
2023-12-14 22:49:44 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 22:50:02 +0100juri_(~juri@implicitcad.org)
2023-12-14 22:54:06 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 256 seconds)
2023-12-14 22:54:49 +0100cimento(CO2@gateway/vpn/protonvpn/cimento) (Quit: WeeChat 4.1.2)
2023-12-14 23:00:01 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 23:04:19 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 246 seconds)
2023-12-14 23:04:29 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-12-14 23:05:11 +0100danza(~danza@151.47.209.192) (Ping timeout: 268 seconds)
2023-12-14 23:08:27 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Quit: oo_miguel)
2023-12-14 23:14:53 +0100aruns(~aruns@user/aruns) (Ping timeout: 240 seconds)
2023-12-14 23:19:21 +0100tri(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 23:19:55 +0100 <monochrom> Oh yeah I learned the hard way that Americans say "how does it work?" to just mean how to be an end user.
2023-12-14 23:23:53 +0100tri_(~tri@ool-18bbef1a.static.optonline.net)
2023-12-14 23:26:59 +0100tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds)
2023-12-14 23:27:59 +0100tri_(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 252 seconds)
2023-12-14 23:28:09 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c) (Remote host closed the connection)
2023-12-14 23:31:25 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-12-14 23:34:41 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-12-14 23:37:53 +0100michalz_(~michalz@185.246.207.221) (Quit: ZNC 1.8.2 - https://znc.in)
2023-12-14 23:39:02 +0100 <probie> monochrom: As a non-American, but native English speaker, I must be the bearer of bad news and inform you that that usage of "how does it work?" is not restricted to Americans
2023-12-14 23:40:05 +0100acidjnk(~acidjnk@p200300d6e72b9302007c3ef187da4880.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-12-14 23:41:11 +0100 <monochrom> The silver lining is that it is simpler to remember "all English dialects do this" than "case dialect of American -> ... ; British -> ... ; Australian -> ..."
2023-12-14 23:41:45 +0100 <monochrom> Have I told you: Every silver lining has tarnish. >:)
2023-12-14 23:41:59 +0100 <monochrom> https://www.vex.net/~trebla/humour/pessimisms.html
2023-12-14 23:42:00 +0100 <juri_> oddly, i've been using "how does it work mechanically", when i want to actuallly know how something works.
2023-12-14 23:46:05 +0100dhil(~dhil@2001:8e0:2014:3100:2e71:f759:1c5d:e673) (Ping timeout: 240 seconds)
2023-12-14 23:47:36 +0100 <monochrom> Why, you press the keys c a b a l <space> i n s t a l l <enter> mechanically! And be sure to use a mechanical keyboard! >:)
2023-12-14 23:48:42 +0100 <int-e> don't forget to release the keys as well
2023-12-14 23:48:52 +0100 <int-e> it takes a lot of practice to get this right
2023-12-14 23:49:40 +0100 <monochrom> For semiconductor-based computers you have to say "how does it work quantum-mechanically?" >:)
2023-12-14 23:52:42 +0100cimento(CO2@gateway/vpn/protonvpn/cimento)