| 2023-10-11 00:01:43 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-10-11 00:20:26 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-10-11 00:31:48 +0000 | Sciencentistguy6 | (~sciencent@hacksoc/ordinary-member) |
| 2023-10-11 00:33:35 +0000 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Ping timeout: 240 seconds) |
| 2023-10-11 00:33:35 +0000 | Sciencentistguy6 | Sciencentistguy |
| 2023-10-11 00:39:08 +0000 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Remote host closed the connection) |
| 2023-10-11 00:51:21 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-11 00:51:21 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-11 00:51:21 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-11 00:51:35 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2023-10-11 00:52:39 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-10-11 00:55:27 +0000 | lg188 | (~lg188@82.18.98.230) (Ping timeout: 240 seconds) |
| 2023-10-11 00:55:58 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 00:56:20 +0000 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 255 seconds) |
| 2023-10-11 00:57:10 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-10-11 01:01:08 +0000 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Quit: oo_miguel) |
| 2023-10-11 01:03:05 +0000 | Guest23 | (~Guest23@149.19.169.127) |
| 2023-10-11 01:03:09 +0000 | <Guest23> | Garfield's Foursome with Nermal, Edna Skilton, and Jean Pierre Manikariza |
| 2023-10-11 01:03:09 +0000 | <Guest23> | Garfield, Nermal, Edna Skilton, and Jean Pierre Manikariza have an orgy over lasagna! https://justpaste.it/Garfield-Foursome-Nermal-Skilton |
| 2023-10-11 01:03:46 +0000 | Guest23 | (~Guest23@149.19.169.127) (K-Lined) |
| 2023-10-11 01:19:42 +0000 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-10-11 01:22:40 +0000 | otto_s | (~user@p5b044f94.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-10-11 01:24:34 +0000 | otto_s | (~user@p4ff272d5.dip0.t-ipconnect.de) |
| 2023-10-11 01:27:25 +0000 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-11 01:29:28 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 01:29:56 +0000 | waleee | (~waleee@2001:9b0:21c:e600:f2f3:f744:435d:137c) (Ping timeout: 246 seconds) |
| 2023-10-11 01:30:05 +0000 | <EvanR> | I've heard that unsafeInterleaveIO is not actually unsafe. In what sense is it not unsafe. Should it say unhaskellyInterleaveIO instead because evaluating the results causes side effects |
| 2023-10-11 01:30:21 +0000 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-10-11 01:31:39 +0000 | <geekosaur> | it's unsafe because I/O actions are triggered in apparently pure code. the Haskell report actually mitigates this to some extent by requiring silent failure in cases where this would be revealed (e.g. exceptions), but GHC's RTS throws them instead |
| 2023-10-11 01:33:50 +0000 | j1grosuc | (~j1grosuc@190.123.12.128) |
| 2023-10-11 01:34:02 +0000 | <EvanR> | not throwing exceptions is safer?? |
| 2023-10-11 01:34:07 +0000 | sabino | (~sabino@user/sabino) (Quit: Lambda _ -> x) |
| 2023-10-11 01:34:21 +0000 | <geekosaur> | from a purity standpoint, yes |
| 2023-10-11 01:34:26 +0000 | j1grosuc | (~j1grosuc@190.123.12.128) (K-Lined) |
| 2023-10-11 01:34:43 +0000 | <geekosaur> | no unexpected bottoms |
| 2023-10-11 01:35:57 +0000 | <geekosaur> | you lose the ability to reason about code when an invisible I/O action can inject unexpected bottoms |
| 2023-10-11 01:35:59 +0000 | <EvanR> | ok the "as long as the program doesn't crash" anti-erlang philosophy |
| 2023-10-11 01:37:56 +0000 | <EvanR> | well yeah this whole narrative seems paint unsafeInterleaveIO as pretty bad either way |
| 2023-10-11 01:38:30 +0000 | <EvanR> | but somehow I recall it being considered not as bad as unsafePerformIO |
| 2023-10-11 01:39:24 +0000 | <geekosaur> | I've seen both takes |
| 2023-10-11 01:40:39 +0000 | <geekosaur> | I think it's still out of sequence with other I/O actions, but at least hypothetically can't interfere with or be interfered with by them (in particular the RTS is supposed to "lock" any resources that are under control of unsafeInterleaveIO) |
| 2023-10-11 01:41:49 +0000 | <EvanR> | how does that work. getContents does the half closing of the handle, but in general? |
| 2023-10-11 01:42:02 +0000 | <geekosaur> | getContents is unsafeInterleaveIO |
| 2023-10-11 01:42:07 +0000 | <EvanR> | yeah |
| 2023-10-11 01:42:51 +0000 | <geekosaur> | and that's what does the half closing. my read of the Report is that it's supposed to be impossible to reopen a file for which a half-closed handle exists |
| 2023-10-11 01:43:04 +0000 | <geekosaur> | not merely impossible to touch that handle |
| 2023-10-11 01:43:13 +0000 | <EvanR> | in general how does it know what resources are involved in your mad science unsafeInterleaveIO |
| 2023-10-11 01:43:19 +0000 | <EvanR> | GC reachable? |
| 2023-10-11 01:45:13 +0000 | <geekosaur> | actually you're expected to tell it yourself, as with hGetContents (https://downloads.haskell.org/ghc/9.2.5/docs/html/libraries/base-4.16.4.0/src/GHC.IO.Handle.Text.h…) |
| 2023-10-11 01:45:19 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-10-11 01:45:27 +0000 | <geekosaur> | it can't be automatic because, as you point out, how can it know? |
| 2023-10-11 01:45:48 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-10-11 01:47:23 +0000 | <geekosaur> | so in the general case you must know how to tell the RTS that some resources can no longer be touched. this is a problem with unsafeInterleaveIO because there are no documented ways to do this in the Report and the only documentation for GHC is in GHC.IO.Handle iirc |
| 2023-10-11 01:47:50 +0000 | <EvanR> | interesting |
| 2023-10-11 01:47:58 +0000 | <geekosaur> | and that might not be enough to deal with, say, a database connection |
| 2023-10-11 01:49:36 +0000 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-11 01:52:24 +0000 | _xor8 | (~xor@ip-50-5-233-250.dynamic.fuse.net) |
| 2023-10-11 01:54:19 +0000 | _xor | (~xor@ip-50-5-233-250.dynamic.fuse.net) (Ping timeout: 255 seconds) |
| 2023-10-11 01:54:19 +0000 | _xor8 | _xor |
| 2023-10-11 02:08:26 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-10-11 02:13:07 +0000 | xff0x | (~xff0x@2405:6580:b080:900:f7aa:8fa9:8388:1900) (Ping timeout: 260 seconds) |
| 2023-10-11 02:13:56 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 02:14:10 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) |
| 2023-10-11 02:17:06 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-10-11 02:18:06 +0000 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2023-10-11 02:21:43 +0000 | thegeekinside | (~thegeekin@189.217.90.224) (Remote host closed the connection) |
| 2023-10-11 02:28:34 +0000 | thegeekinside | (~thegeekin@189.217.90.224) |
| 2023-10-11 02:37:00 +0000 | Sanguine | (~Sanguine@bcdcac82.skybroadband.com) (Ping timeout: 248 seconds) |
| 2023-10-11 02:39:31 +0000 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2023-10-11 02:40:31 +0000 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 255 seconds) |
| 2023-10-11 02:42:45 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-10-11 02:42:45 +0000 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-10-11 02:42:45 +0000 | finn_elija | FinnElija |
| 2023-10-11 02:49:06 +0000 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) |
| 2023-10-11 02:53:16 +0000 | td_ | (~td@i53870936.versanet.de) (Ping timeout: 260 seconds) |
| 2023-10-11 02:54:57 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 02:59:33 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-11 02:59:41 +0000 | td_ | (~td@2001:9e8:19f7:c900:55c4:edef:d459:6ff7) |
| 2023-10-11 02:59:52 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds) |
| 2023-10-11 03:03:51 +0000 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds) |
| 2023-10-11 03:04:08 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-10-11 03:07:49 +0000 | Sanguine | (~Sanguine@176.254.244.83) |
| 2023-10-11 03:11:31 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 03:15:48 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 240 seconds) |
| 2023-10-11 03:16:56 +0000 | aforemny_ | (~aforemny@i59f516dd.versanet.de) |
| 2023-10-11 03:18:09 +0000 | aforemny | (~aforemny@i59F516D8.versanet.de) (Ping timeout: 258 seconds) |
| 2023-10-11 03:20:57 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-11 03:25:01 +0000 | ss4 | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2023-10-11 03:27:02 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2023-10-11 03:38:35 +0000 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds) |
| 2023-10-11 03:40:05 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 240 seconds) |
| 2023-10-11 03:40:07 +0000 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-10-11 03:41:29 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 252 seconds) |
| 2023-10-11 03:41:50 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2023-10-11 03:42:56 +0000 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-10-11 03:45:27 +0000 | thegeekinside | (~thegeekin@189.217.90.224) (Read error: Connection reset by peer) |
| 2023-10-11 03:49:12 +0000 | shapr | (~user@2600:1700:c640:3100:4d15:1e8d:2f46:bef9) (Remote host closed the connection) |
| 2023-10-11 03:49:25 +0000 | shapr | (~user@2600:1700:c640:3100:5112:c2fa:e8e6:5128) |
| 2023-10-11 04:07:53 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 252 seconds) |
| 2023-10-11 04:09:27 +0000 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-10-11 04:13:01 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds) |
| 2023-10-11 04:13:23 +0000 | califax | (~califax@user/califx) (Ping timeout: 252 seconds) |
| 2023-10-11 04:13:24 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-10-11 04:13:36 +0000 | califax_ | (~califax@user/califx) |
| 2023-10-11 04:14:51 +0000 | califax_ | califax |
| 2023-10-11 04:20:05 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 04:20:11 +0000 | tzh_ | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-10-11 04:20:21 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:20:29 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-10-11 04:20:48 +0000 | vglfr | (~vglfr@88.155.190.13) (Remote host closed the connection) |
| 2023-10-11 04:22:27 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:22:40 +0000 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Ping timeout: 255 seconds) |
| 2023-10-11 04:24:53 +0000 | vglfr | (~vglfr@88.155.190.13) (Remote host closed the connection) |
| 2023-10-11 04:25:37 +0000 | tzh_ | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Ping timeout: 258 seconds) |
| 2023-10-11 04:25:42 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:25:51 +0000 | vglfr | (~vglfr@88.155.190.13) (Remote host closed the connection) |
| 2023-10-11 04:28:19 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:30:04 +0000 | vglfr | (~vglfr@88.155.190.13) (Read error: Connection reset by peer) |
| 2023-10-11 04:30:24 +0000 | vglfr | (~vglfr@149.102.244.115) |
| 2023-10-11 04:33:14 +0000 | vglfr | (~vglfr@149.102.244.115) (Remote host closed the connection) |
| 2023-10-11 04:34:09 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:34:17 +0000 | vglfr | (~vglfr@88.155.190.13) (Read error: Connection reset by peer) |
| 2023-10-11 04:34:37 +0000 | vglfr | (vglfr@gateway/vpn/protonvpn/vglfr) |
| 2023-10-11 04:44:18 +0000 | vglfr | (vglfr@gateway/vpn/protonvpn/vglfr) (Ping timeout: 272 seconds) |
| 2023-10-11 04:44:58 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 04:45:33 +0000 | danza | (~francesco@151.35.192.230) |
| 2023-10-11 04:47:34 +0000 | Pixi` | (~Pixi@user/pixi) (Read error: Connection reset by peer) |
| 2023-10-11 04:52:05 +0000 | danza | (~francesco@151.35.192.230) (Ping timeout: 240 seconds) |
| 2023-10-11 04:54:10 +0000 | phma | (~phma@host-67-44-208-50.hnremote.net) (Read error: Connection reset by peer) |
| 2023-10-11 04:58:18 +0000 | phma | (~phma@2001:5b0:211c:9d28:dc53:577d:4a04:1d14) |
| 2023-10-11 04:58:22 +0000 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-10-11 04:58:35 +0000 | jinsun | (~jinsun@user/jinsun) |
| 2023-10-11 05:01:42 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 05:05:33 +0000 | Pixi | (~Pixi@user/pixi) |
| 2023-10-11 05:11:58 +0000 | michalz | (~michalz@185.246.207.200) |
| 2023-10-11 05:14:41 +0000 | phma | (~phma@2001:5b0:211c:9d28:dc53:577d:4a04:1d14) (Read error: Connection reset by peer) |
| 2023-10-11 05:14:55 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-10-11 05:16:46 +0000 | phma | (~phma@host-67-44-208-58.hnremote.net) |
| 2023-10-11 05:34:06 +0000 | Square3 | (~Square4@user/square) |
| 2023-10-11 05:34:46 +0000 | danse-nr3 | (~francesco@151.35.192.230) |
| 2023-10-11 05:35:23 +0000 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-10-11 05:36:52 +0000 | Square2 | (~Square4@user/square) (Ping timeout: 272 seconds) |
| 2023-10-11 05:44:56 +0000 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-10-11 05:47:29 +0000 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-10-11 05:49:31 +0000 | vglfr | (~vglfr@88.155.190.13) (Ping timeout: 264 seconds) |
| 2023-10-11 05:50:48 +0000 | <danse-nr3> | good morning #haskell |
| 2023-10-11 05:58:20 +0000 | acidjnk | (~acidjnk@p200300d6e7072f8019cae40178150491.dip0.t-ipconnect.de) |
| 2023-10-11 05:59:06 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 06:00:12 +0000 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-10-11 06:07:21 +0000 | <dminuoso> | Good morning. |
| 2023-10-11 06:08:06 +0000 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds) |
| 2023-10-11 06:11:36 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-10-11 06:13:03 +0000 | notzmv | (~zmv@user/notzmv) (Ping timeout: 240 seconds) |
| 2023-10-11 06:17:21 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-10-11 06:21:28 +0000 | bilegeek | (~bilegeek@2600:1008:b004:d50e:d8be:4118:2b29:669c) (Quit: Leaving) |
| 2023-10-11 06:22:53 +0000 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 06:29:16 +0000 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-11 06:32:40 +0000 | Jesin | (~Jesin@pool-72-83-12-199.washdc.fios.verizon.net) |
| 2023-10-11 06:38:57 +0000 | danse-nr3_ | (~francesco@151.35.192.230) |
| 2023-10-11 06:41:27 +0000 | danse-nr3 | (~francesco@151.35.192.230) (Ping timeout: 260 seconds) |
| 2023-10-11 06:42:11 +0000 | danse-nr3 | (~francesco@151.35.192.230) |
| 2023-10-11 06:42:12 +0000 | CiaoSen | (~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) |
| 2023-10-11 06:44:48 +0000 | Jesin | (~Jesin@pool-72-83-12-199.washdc.fios.verizon.net) (Quit: Jesin) |
| 2023-10-11 06:45:16 +0000 | danse-nr3_ | (~francesco@151.35.192.230) (Quit: Leaving) |
| 2023-10-11 06:50:26 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8b9c:51e3:d64a:72e4) |
| 2023-10-11 06:56:28 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 07:01:03 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-10-11 07:04:21 +0000 | danse-nr3 | (~francesco@151.35.192.230) (Read error: Connection reset by peer) |
| 2023-10-11 07:04:27 +0000 | danse-nr3_ | (~francesco@151.35.217.158) |
| 2023-10-11 07:09:47 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2023-10-11 07:10:09 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-10-11 07:11:41 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2023-10-11 07:14:55 +0000 | fendor | (~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) |
| 2023-10-11 07:17:54 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 07:20:31 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-10-11 07:34:09 +0000 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5) |
| 2023-10-11 07:36:18 +0000 | zer0bitz | (~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer) |
| 2023-10-11 07:36:20 +0000 | <Hecate> | morning morning |
| 2023-10-11 07:37:21 +0000 | Pickchea | (~private@user/pickchea) |
| 2023-10-11 07:37:52 +0000 | <tomsmeding> | The haskell playground currently has so far carried compilers back to ghc 8.6.5. Just now I added 8.4.4 because I could. Should it go further back? Should we drop old compilers at some point? Or should the list ever keep getting longer? |
| 2023-10-11 07:37:57 +0000 | <tomsmeding> | Opinion time! :D |
| 2023-10-11 07:39:01 +0000 | <Hecate> | well, having these older versions are indeed nice because you get to compare the generated Core/STG/ASM outputs |
| 2023-10-11 07:39:06 +0000 | <Hecate> | that is objectively useful |
| 2023-10-11 07:39:41 +0000 | <Hecate> | now the "problem" (which is quite unavoidable) is that the packages that are exposed will certainly have opinions about which GHC versions they want to run on |
| 2023-10-11 07:40:50 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-10-11 07:41:06 +0000 | <tomsmeding> | In what sense? They can just select their preferred GHC version, right? |
| 2023-10-11 07:41:07 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2023-10-11 07:41:32 +0000 | <tomsmeding> | I have a wishlist of packages and provide, for each GHC version, all that will build |
| 2023-10-11 07:41:35 +0000 | euleritian | (~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) |
| 2023-10-11 07:42:13 +0000 | <tomsmeding> | It's a bit imperfect because sometimes cabal's solver tends to select very old versions to make the plan work and I should probably avoid that with some well-chosen lower boubds |
| 2023-10-11 07:42:42 +0000 | euleritian | (~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-10-11 07:42:59 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 07:45:40 +0000 | aforemny_ | aforemny |
| 2023-10-11 07:49:48 +0000 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 240 seconds) |
| 2023-10-11 07:55:18 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-10-11 07:57:44 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2023-10-11 07:58:37 +0000 | euleritian | (~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) |
| 2023-10-11 08:03:48 +0000 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-10-11 08:10:07 +0000 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2023-10-11 08:16:18 +0000 | <[exa]> | tomsmeding: opinion: I'm trying not to care about ghc version |
| 2023-10-11 08:16:39 +0000 | <[exa]> | but still thanks for the great effort |
| 2023-10-11 08:18:18 +0000 | euleritian | (~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) (Ping timeout: 258 seconds) |
| 2023-10-11 08:19:21 +0000 | dsrt^ | (~cd@76.145.193.217) (Remote host closed the connection) |
| 2023-10-11 08:19:39 +0000 | dsrt^ | (~cd@76.145.193.217) |
| 2023-10-11 08:20:05 +0000 | <tomsmeding> | <3 |
| 2023-10-11 08:22:07 +0000 | notzmv | (~zmv@user/notzmv) |
| 2023-10-11 08:23:24 +0000 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-10-11 08:26:41 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 08:27:29 +0000 | tomih_ | (tomith@85-156-187-17.elisa-laajakaista.fi) |
| 2023-10-11 08:28:12 +0000 | danse-nr3_ | (~francesco@151.35.217.158) (Ping timeout: 240 seconds) |
| 2023-10-11 08:28:57 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2023-10-11 08:30:03 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds) |
| 2023-10-11 08:30:07 +0000 | tomith | (tomith@user/tomith) (Read error: Connection reset by peer) |
| 2023-10-11 08:30:10 +0000 | tomih_ | tomith |
| 2023-10-11 08:33:26 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 08:35:03 +0000 | Jackneill | (~Jackneill@20014C4E1E021C00E4226B7959631CE0.dsl.pool.telekom.hu) |
| 2023-10-11 08:35:24 +0000 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-10-11 08:37:30 +0000 | chele | (~chele@user/chele) |
| 2023-10-11 08:38:42 +0000 | Square3 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2023-10-11 08:38:43 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-10-11 08:41:20 +0000 | <cpressey> | tomsmeding: I don't have enough context to give you an opinion, but as a data point, I regularly use a tool that only works with ghc 7.10. (I run it from a Docker container). |
| 2023-10-11 08:43:47 +0000 | <tomsmeding> | heh |
| 2023-10-11 08:44:19 +0000 | <tomsmeding> | cpressey: for my curiosity, in what way does it break if you run it with ghc 8.0? |
| 2023-10-11 08:44:56 +0000 | <tomsmeding> | (ghc 7.10 doesn't install from ghcup -- something _segfaults_, of all things) |
| 2023-10-11 08:45:20 +0000 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-10-11 08:46:44 +0000 | <cpressey> | tomsmeding: It's https://github.com/valderman/haste-compiler . As I understand it, it relies on ghc internals to do the compiling. ghc internals change (obvs), it was a thesis project of the author's and they have insufficient interest in it to update it. |
| 2023-10-11 08:47:26 +0000 | <tomsmeding> | fair, I wasn't wondering why it wasn't updated -- these things happen. I was just wondering if it relied on GHC internals, and if it had any right to do so :p |
| 2023-10-11 08:47:30 +0000 | <tomsmeding> | but it seems this clearly does |
| 2023-10-11 08:48:42 +0000 | <tomsmeding> | I mean, GHCJS exists |
| 2023-10-11 08:48:51 +0000 | <tomsmeding> | but "if it works, don't touch it" |
| 2023-10-11 08:48:52 +0000 | <cpressey> | I could try switching to a different Haskell-to-JS compiler but all the ones I've seen seem immensely complicated to set up compared to haste. |
| 2023-10-11 08:51:39 +0000 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 08:57:35 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-10-11 08:58:17 +0000 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-11 08:58:55 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) |
| 2023-10-11 09:02:04 +0000 | danse-nr3_ | (~francesco@151.35.217.158) |
| 2023-10-11 09:02:41 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-10-11 09:03:48 +0000 | <sshine> | have you considered ghc wasm backend? |
| 2023-10-11 09:05:39 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-10-11 09:08:59 +0000 | simendsjo | (~user@84.211.91.241) |
| 2023-10-11 09:20:53 +0000 | <cpressey> | sshine: Not yet, and I wouldn't expect it to happen unless/until my perception of "messing with wasm" switches from it being a "dreadful thing" to it being a "fun thing". I don't have an ETA on that at present. |
| 2023-10-11 09:24:14 +0000 | <ncf> | there's a js backend now |
| 2023-10-11 09:24:31 +0000 | vglfr | (~vglfr@88.155.190.13) (Read error: Connection reset by peer) |
| 2023-10-11 09:25:24 +0000 | <arahael> | That js backend terrifies me. |
| 2023-10-11 09:25:48 +0000 | <haskellbridge> | <sm> cpressey I like this metric, could apply to many things |
| 2023-10-11 09:29:02 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 09:36:52 +0000 | <sand-witch> | tomsmeding: Vlad also wants to implement T2T for both patterns and expressions at 9.10, so you would able to write "id t x = x :: t" (where "id :: forall a -> a -> a") and apply it as "id Int 5", without any "type" keywords |
| 2023-10-11 09:40:23 +0000 | shapr | (~user@2600:1700:c640:3100:5112:c2fa:e8e6:5128) (Remote host closed the connection) |
| 2023-10-11 09:40:36 +0000 | shapr | (~user@2600:1700:c640:3100:fb57:2f19:4620:f3bb) |
| 2023-10-11 09:42:15 +0000 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds) |
| 2023-10-11 09:42:55 +0000 | xigua | (~xigua@user/xigua) (Remote host closed the connection) |
| 2023-10-11 09:43:29 +0000 | xigua | (~xigua@user/xigua) |
| 2023-10-11 09:43:54 +0000 | <albet70> | what is functor compose? |
| 2023-10-11 09:44:34 +0000 | <albet70> | foldr (:) [] (Compose [Nothing, Just 3]) |
| 2023-10-11 09:44:40 +0000 | <ncf> | like function composition, but for functors |
| 2023-10-11 09:45:06 +0000 | <ncf> | :k Compose |
| 2023-10-11 09:45:07 +0000 | <lambdabot> | error: |
| 2023-10-11 09:45:07 +0000 | <lambdabot> | Not in scope: type constructor or class ‘Compose’ |
| 2023-10-11 09:45:10 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 09:46:17 +0000 | <albet70> | foldr (:) [] on this functor compose, why [3] is left? |
| 2023-10-11 09:47:08 +0000 | <sshine> | sand-witch, is that types as values? |
| 2023-10-11 09:48:00 +0000 | <ncf> | albet70: this appears to be using the (Foldable f, Foldable g) => Foldable (Compose f g) instance |
| 2023-10-11 09:48:10 +0000 | <ncf> | :t foldr (:) [] |
| 2023-10-11 09:48:11 +0000 | <lambdabot> | Foldable t => t a -> [a] |
| 2023-10-11 09:49:00 +0000 | <ncf> | if you see [_, _] as a container with two holes, Nothing as a container with zero holes and Just _ as a container with one hole, then via the composite instance [Nothing, Just 3] contains just 3 |
| 2023-10-11 09:52:04 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 09:52:44 +0000 | <tomsmeding> | sand-witch: :D |
| 2023-10-11 09:55:13 +0000 | <sand-witch> | sshine: nope, they would be erased on compile time |
| 2023-10-11 09:57:24 +0000 | ft | (~ft@p3e9bc680.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-10-11 09:59:37 +0000 | <dminuoso> | In some sense `(Foldable f, Foldable g) => Foldable (Compose f g)` is just another way of expressing `Monad []` |
| 2023-10-11 10:00:36 +0000 | <albet70> | this Compose reminds me 'maybe' somehow, and 'traverse' |
| 2023-10-11 10:01:18 +0000 | <albet70> | maybe can turn Maybe monad to another monad |
| 2023-10-11 10:01:24 +0000 | <dminuoso> | Or let me ponder about this. |
| 2023-10-11 10:01:53 +0000 | <dminuoso> | Actually on second thought, those things are not equivalent. |
| 2023-10-11 10:01:53 +0000 | <albet70> | but monad does not compose, this functor do compose |
| 2023-10-11 10:02:01 +0000 | <dminuoso> | > join [[1,2], [3,4]] |
| 2023-10-11 10:02:02 +0000 | <ncf> | (f a -> [a]) -> (g a -> [a]) -> (f (g a) -> [a]) does turn into join :: [[a]] -> [a] by yoneda, but you don't get return out of this |
| 2023-10-11 10:02:02 +0000 | <lambdabot> | [1,2,3,4] |
| 2023-10-11 10:02:08 +0000 | <dminuoso> | Or no, actually they are the same. |
| 2023-10-11 10:02:14 +0000 | <dminuoso> | Nevermind, its a good statement. |
| 2023-10-11 10:02:25 +0000 | <dminuoso> | albet70: Well monad is *about* composition. |
| 2023-10-11 10:02:37 +0000 | <ncf> | so it's a way of expressing half of the [] monad :) |
| 2023-10-11 10:02:45 +0000 | <dminuoso> | Its quite literally about being able to do `T :.: T ~> T` in a sensible way |
| 2023-10-11 10:03:21 +0000 | <dminuoso> | Where :.: is just infix Compose |
| 2023-10-11 10:05:44 +0000 | <albet70> | dminuoso , what's its name? natural transparent? |
| 2023-10-11 10:05:58 +0000 | hiyori | (~hiyori@user/hiyori) (Ping timeout: 245 seconds) |
| 2023-10-11 10:06:59 +0000 | <dminuoso> | albet70: Its a natural transformation. But if we ignore this fancy sounding name `T :.: T ~> T` is just another way of expressing `T a :.: T a -> T a` |
| 2023-10-11 10:07:40 +0000 | <dminuoso> | Which using Compose would just be written `(Compose T T) a -> T a`, which is isomorphic to just `T (T a) -> T a` |
| 2023-10-11 10:07:43 +0000 | <dminuoso> | And indeed: |
| 2023-10-11 10:07:46 +0000 | <dminuoso> | :t join |
| 2023-10-11 10:07:47 +0000 | <lambdabot> | Monad m => m (m a) -> m a |
| 2023-10-11 10:07:50 +0000 | <dminuoso> | :t join @[] |
| 2023-10-11 10:07:51 +0000 | <lambdabot> | error: |
| 2023-10-11 10:07:51 +0000 | <lambdabot> | Pattern syntax in expression context: join@[] |
| 2023-10-11 10:07:51 +0000 | <lambdabot> | Did you mean to enable TypeApplications? |
| 2023-10-11 10:08:01 +0000 | <dminuoso> | % set -XTypeApplications |
| 2023-10-11 10:08:01 +0000 | <yahb2> | <interactive>:7:1: error: ; • Variable not in scope: set ; • Perhaps you meant ‘seq’ (imported from Prelude) ; ; <interactive>:7:6: error: ; Data constructor not in scope: XTypeApplica... |
| 2023-10-11 10:08:06 +0000 | <dminuoso> | % :set -XTypeApplications |
| 2023-10-11 10:08:06 +0000 | <yahb2> | <no output> |
| 2023-10-11 10:08:14 +0000 | <dminuoso> | % :t join @[] |
| 2023-10-11 10:08:14 +0000 | <yahb2> | <interactive>:1:1: error: Variable not in scope: join |
| 2023-10-11 10:08:17 +0000 | <dminuoso> | Jeez. |
| 2023-10-11 10:08:41 +0000 | <dminuoso> | % :t join @[] |
| 2023-10-11 10:08:41 +0000 | <yahb2> | join @[] :: Monad [] => [[a]] -> [a] |
| 2023-10-11 10:12:28 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 248 seconds) |
| 2023-10-11 10:14:53 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds) |
| 2023-10-11 10:20:56 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 10:26:56 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 272 seconds) |
| 2023-10-11 10:40:49 +0000 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 255 seconds) |
| 2023-10-11 10:41:45 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-10-11 10:44:33 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-10-11 10:48:11 +0000 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds) |
| 2023-10-11 10:48:14 +0000 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 10:48:51 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 10:48:51 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 10:54:30 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 10:55:32 +0000 | privacy | (~privacy@user/privacy) |
| 2023-10-11 10:57:59 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 11:03:16 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-10-11 11:04:18 +0000 | danse-nr3__ | (~francesco@151.37.199.183) |
| 2023-10-11 11:04:29 +0000 | danse-nr3_ | (~francesco@151.35.217.158) (Read error: Connection reset by peer) |
| 2023-10-11 11:04:52 +0000 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-10-11 11:06:19 +0000 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-10-11 11:06:44 +0000 | xff0x | (~xff0x@ai101218.d.east.v6connect.net) |
| 2023-10-11 11:08:04 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 11:09:41 +0000 | CiaoSen | (~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) (Ping timeout: 260 seconds) |
| 2023-10-11 11:11:12 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 11:11:57 +0000 | danse-nr3__ | (~francesco@151.37.199.183) (Ping timeout: 258 seconds) |
| 2023-10-11 11:14:15 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 11:14:47 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-10-11 11:15:47 +0000 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) |
| 2023-10-11 11:17:08 +0000 | Cajun | (~Cajun@user/cajun) |
| 2023-10-11 11:17:17 +0000 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) |
| 2023-10-11 11:18:35 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 11:20:23 +0000 | vglfr | (~vglfr@88.155.190.13) (Ping timeout: 258 seconds) |
| 2023-10-11 11:21:55 +0000 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-10-11 11:22:42 +0000 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-10-11 11:24:34 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 11:25:54 +0000 | Luj | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Quit: The Lounge - https://thelounge.chat) |
| 2023-10-11 11:27:48 +0000 | Luj | (~Luj@2a01:e0a:5f9:9681:c367:ba44:42cf:91d7) |
| 2023-10-11 11:29:33 +0000 | fendor | (~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection) |
| 2023-10-11 11:30:09 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 11:32:41 +0000 | privacy | (~privacy@user/privacy) (Quit: Leaving) |
| 2023-10-11 11:40:42 +0000 | CiaoSen | (~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) |
| 2023-10-11 11:47:56 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2023-10-11 11:52:11 +0000 | diamond | (~user@89.223.35.3) |
| 2023-10-11 12:05:14 +0000 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-10-11 12:07:04 +0000 | vglfr | (~vglfr@88.155.190.13) (Ping timeout: 255 seconds) |
| 2023-10-11 12:11:34 +0000 | Cajun | (~Cajun@user/cajun) (Quit: Client closed) |
| 2023-10-11 12:13:00 +0000 | cods | (~fred@82-65-232-44.subs.proxad.net) (Ping timeout: 240 seconds) |
| 2023-10-11 12:17:21 +0000 | vglfr | (~vglfr@88.155.190.13) |
| 2023-10-11 12:20:26 +0000 | cods | (~fred@tuxee.net) |
| 2023-10-11 12:34:27 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-11 12:36:26 +0000 | sm | (~sm@plaintextaccounting/sm) (Client Quit) |
| 2023-10-11 12:44:11 +0000 | hugo- | hug |
| 2023-10-11 12:46:47 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-11 12:46:47 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-11 12:46:47 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-11 12:57:48 +0000 | hug | (znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds) |
| 2023-10-11 12:58:15 +0000 | pounce | (~pounce@user/cute/pounce) (Remote host closed the connection) |
| 2023-10-11 12:58:33 +0000 | pounce | (~pounce@user/cute/pounce) |
| 2023-10-11 13:00:05 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8b9c:51e3:d64a:72e4) (Quit: WeeChat 2.8) |
| 2023-10-11 13:01:49 +0000 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-10-11 13:02:21 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 258 seconds) |
| 2023-10-11 13:03:33 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2023-10-11 13:03:35 +0000 | pounce | (~pounce@user/cute/pounce) (Remote host closed the connection) |
| 2023-10-11 13:03:52 +0000 | pounce | (~pounce@user/cute/pounce) |
| 2023-10-11 13:04:53 +0000 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) |
| 2023-10-11 13:05:57 +0000 | pounce | (~pounce@user/cute/pounce) (Remote host closed the connection) |
| 2023-10-11 13:12:15 +0000 | pounce | (~pounce@user/cute/pounce) |
| 2023-10-11 13:12:42 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 13:13:05 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2023-10-11 13:13:51 +0000 | euleritian | (~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) |
| 2023-10-11 13:17:51 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-10-11 13:19:11 +0000 | pounce | (~pounce@user/cute/pounce) (Ping timeout: 260 seconds) |
| 2023-10-11 13:20:11 +0000 | danse-nr3 | (~francesco@151.37.199.183) |
| 2023-10-11 13:21:40 +0000 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-11 13:22:22 +0000 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-10-11 13:23:17 +0000 | euleritian | (~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-10-11 13:23:36 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 13:27:05 +0000 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
| 2023-10-11 13:27:40 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2023-10-11 13:28:00 +0000 | euleritian | (~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) |
| 2023-10-11 13:29:48 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 240 seconds) |
| 2023-10-11 13:31:27 +0000 | lena64t | (~lena64t@gateway/tor-sasl/hck) (Ping timeout: 252 seconds) |
| 2023-10-11 13:32:04 +0000 | shapr | (~user@2600:1700:c640:3100:fb57:2f19:4620:f3bb) (Remote host closed the connection) |
| 2023-10-11 13:32:18 +0000 | shapr | (~user@2600:1700:c640:3100:e8fe:9f19:d6ff:62f3) |
| 2023-10-11 13:32:51 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2023-10-11 13:35:06 +0000 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 13:35:21 +0000 | pounce | (~pounce@user/cute/pounce) |
| 2023-10-11 13:35:38 +0000 | lena64t | (~lena64t@gateway/tor-sasl/hck) |
| 2023-10-11 13:36:05 +0000 | pounce | (~pounce@user/cute/pounce) (Remote host closed the connection) |
| 2023-10-11 13:36:23 +0000 | euleritian | (~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-10-11 13:36:41 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 13:36:54 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 13:37:10 +0000 | pounce | (~pounce@user/cute/pounce) |
| 2023-10-11 13:37:51 +0000 | notzmv | (~zmv@user/notzmv) (Ping timeout: 260 seconds) |
| 2023-10-11 13:46:57 +0000 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-10-11 13:48:28 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 13:49:31 +0000 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Ping timeout: 264 seconds) |
| 2023-10-11 13:49:40 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 255 seconds) |
| 2023-10-11 13:51:05 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 13:51:30 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-11 13:51:37 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 252 seconds) |
| 2023-10-11 13:53:30 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-10-11 13:54:06 +0000 | lg188 | (~lg188@82.18.98.230) (Quit: Ping timeout (120 seconds)) |
| 2023-10-11 13:54:59 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 13:55:28 +0000 | lg188 | (~lg188@82.18.98.230) (Remote host closed the connection) |
| 2023-10-11 13:58:33 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2023-10-11 13:59:12 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 14:01:14 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 14:02:22 +0000 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-10-11 14:02:46 +0000 | ames | (~amelia@offtopia/offtopian/amelia) (Quit: Ping timeout (120 seconds)) |
| 2023-10-11 14:03:19 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) (Ping timeout: 255 seconds) |
| 2023-10-11 14:03:50 +0000 | Franciman | (~Franciman@mx1.fracta.dev) (Read error: Connection reset by peer) |
| 2023-10-11 14:04:04 +0000 | pierrot | (~pi@user/pierrot) (Quit: ZNC 1.8.2 - http://znc.in) |
| 2023-10-11 14:05:17 +0000 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-10-11 14:05:27 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-11 14:11:46 +0000 | simendsjo | (~user@84.211.91.241) (Ping timeout: 272 seconds) |
| 2023-10-11 14:12:21 +0000 | CiaoSen | (~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) (Ping timeout: 260 seconds) |
| 2023-10-11 14:19:35 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) |
| 2023-10-11 14:26:26 +0000 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-11 14:26:37 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 14:27:06 +0000 | thegeekinside | (~thegeekin@189.217.90.224) |
| 2023-10-11 14:34:29 +0000 | xigua | (~xigua@user/xigua) (Remote host closed the connection) |
| 2023-10-11 14:35:02 +0000 | xigua | (~xigua@user/xigua) |
| 2023-10-11 14:38:56 +0000 | Pozyomka | (~pyon@user/pyon) (Quit: Pozyomka, my beloved: https://i.imgur.com/BMmVfTq.png) |
| 2023-10-11 14:39:23 +0000 | xigua | (~xigua@user/xigua) (Remote host closed the connection) |
| 2023-10-11 14:39:53 +0000 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 246 seconds) |
| 2023-10-11 14:39:57 +0000 | xigua | (~xigua@user/xigua) |
| 2023-10-11 14:40:23 +0000 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:17b7) |
| 2023-10-11 14:41:02 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2023-10-11 14:42:36 +0000 | jrm | (~jrm@user/jrm) |
| 2023-10-11 14:45:24 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 240 seconds) |
| 2023-10-11 14:50:41 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2023-10-11 14:52:04 +0000 | jrm | (~jrm@user/jrm) |
| 2023-10-11 14:53:49 +0000 | ames | (~amelia@offtopia/offtopian/amelia) |
| 2023-10-11 14:55:14 +0000 | Franciman | (~Franciman@mx1.fracta.dev) |
| 2023-10-11 14:56:37 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) |
| 2023-10-11 14:58:20 +0000 | <kuribas> | It looks like when throwing an error, the application is not return an proper error code (1)? |
| 2023-10-11 14:58:54 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 14:59:10 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) |
| 2023-10-11 14:59:12 +0000 | pierrot | (~pi@user/pierrot) |
| 2023-10-11 14:59:16 +0000 | <geekosaur> | ? |
| 2023-10-11 14:59:29 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 15:01:10 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2023-10-11 15:03:19 +0000 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-10-11 15:03:47 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 255 seconds) |
| 2023-10-11 15:04:00 +0000 | danse-nr3 | (~francesco@151.37.199.183) (Read error: Connection reset by peer) |
| 2023-10-11 15:04:15 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-10-11 15:04:20 +0000 | <geekosaur> | https://paste.tomsmeding.com/RWqFNwGR `error` seems to produce a nonzero error code from the program. if it's not, I'd check for `catch`es that don't re-throw properly |
| 2023-10-11 15:04:37 +0000 | danse-nr3 | (~francesco@151.37.182.55) |
| 2023-10-11 15:04:49 +0000 | <haskellbridge> | <Inst> Here's something I don't get. How does `join` even work? |
| 2023-10-11 15:05:02 +0000 | <haskellbridge> | <Inst> (>>= id) |
| 2023-10-11 15:05:07 +0000 | <haskellbridge> | <Inst> id doesn't have the right type signature, no? |
| 2023-10-11 15:05:20 +0000 | <kuribas> | geekosaur: hmm right, I suppose something else is going on in my code then... |
| 2023-10-11 15:05:25 +0000 | <c_wraith> | Inst: sure it does. But expand it. |
| 2023-10-11 15:05:43 +0000 | <geekosaur> | `a` unifies with anything, as long as it's the same thing on both sides of the arrow |
| 2023-10-11 15:05:52 +0000 | <kuribas> | geekosaur: indeed, I am catching and collecting the errors elsewhere. |
| 2023-10-11 15:05:55 +0000 | <haskellbridge> | <Inst> (>>=) :: m a -> (a -> m b) -> m b |
| 2023-10-11 15:06:05 +0000 | <haskellbridge> | <Inst> id :: a -> a |
| 2023-10-11 15:06:28 +0000 | <c_wraith> | Inst: join x = x >>= id --- join x = x >>= \y -> y ---- join x = do {y <- x ; y} |
| 2023-10-11 15:06:36 +0000 | <haskellbridge> | <Inst> erm, id :: a2 -> a2 |
| 2023-10-11 15:06:46 +0000 | shapr | (~user@2600:1700:c640:3100:e8fe:9f19:d6ff:62f3) (Remote host closed the connection) |
| 2023-10-11 15:06:59 +0000 | shapr | (~user@2600:1700:c640:3100:ae91:4ce3:990:5e2b) |
| 2023-10-11 15:07:20 +0000 | euleritian | (~euleritia@46.114.206.159) |
| 2023-10-11 15:07:51 +0000 | <haskellbridge> | <Inst> it's still freaky |
| 2023-10-11 15:07:59 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) |
| 2023-10-11 15:08:06 +0000 | <geekosaur> | that's Hindley-Milner for you |
| 2023-10-11 15:08:24 +0000 | <EvanR> | Inst, pretend >>= is an operation on IO actions and followup callbacks that use the result |
| 2023-10-11 15:08:30 +0000 | <c_wraith> | Inst: now work on fix :: (IO a -> IO a) -> IO a |
| 2023-10-11 15:08:50 +0000 | <EvanR> | then join does the obvious |
| 2023-10-11 15:10:25 +0000 | <EvanR> | in the context of IO (IO a) |
| 2023-10-11 15:11:15 +0000 | <c_wraith> | Inst: in any case, going back purely to types. given what you wrote, you immediately derive a2 ~ a, a2 ~ m b. From those, you derived a ~ m b. Then the type of (>>=) is restricted to m (m b) -> (m b -> m b) -> m b |
| 2023-10-11 15:11:24 +0000 | <haskellbridge> | <Inst> I don't have the intellectual background / understanding of HM to understand how this is supposed to work, I just know it works, and is convenient in a few rare usecases |
| 2023-10-11 15:11:40 +0000 | <geekosaur> | see what c_wraith just wrote |
| 2023-10-11 15:11:53 +0000 | <haskellbridge> | <Inst> yeah, just saw it |
| 2023-10-11 15:12:44 +0000 | <[exa]> | Inst: a very little bit of prolog practice usually solves all problem with unification-heavy algorithms like HM |
| 2023-10-11 15:13:29 +0000 | <EvanR> | the identity function works for all types, that part shouldn't be confusing right |
| 2023-10-11 15:13:43 +0000 | <EvanR> | if it couldn't specialize to the appropriate type, how would it ever work |
| 2023-10-11 15:13:51 +0000 | <kuribas> | :t (>>=) id |
| 2023-10-11 15:13:52 +0000 | <lambdabot> | (a -> a -> b) -> a -> b |
| 2023-10-11 15:14:06 +0000 | <geekosaur> | but for most people prolog makes haskell look "normal" 😛 |
| 2023-10-11 15:14:26 +0000 | <kuribas> | :t (>>= id) |
| 2023-10-11 15:14:27 +0000 | <lambdabot> | Monad m => m (m b) -> m b |
| 2023-10-11 15:14:41 +0000 | <[exa]> | geekosaur: true point |
| 2023-10-11 15:14:45 +0000 | <EvanR> | id 7 = 7, but Inst you should be surprised because id doesn't have the right ype? |
| 2023-10-11 15:15:00 +0000 | <haskellbridge> | <Inst> yeah, i know, the :t on (>>= id) makes sense and is understandable, but it's hard for me to grok the loopholes that somehow make (>>= id) work |
| 2023-10-11 15:15:09 +0000 | <kuribas> | id here is (m b -> m b) |
| 2023-10-11 15:15:10 +0000 | <dolio> | You don't need to understand Hindley-Milner. But you need to understand how to unify two types. |
| 2023-10-11 15:15:35 +0000 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:17b7) (Ping timeout: 246 seconds) |
| 2023-10-11 15:15:56 +0000 | <haskellbridge> | <Inst> yeah, tbh, implicitly this is a big problem, when i was very early on my Haskell journey, it was the type system that weirded me out |
| 2023-10-11 15:15:59 +0000 | <c_wraith> | yeah, I actually don't understand H-M. but I can do unification! |
| 2023-10-11 15:16:28 +0000 | <kuribas> | I don't even think you need to understand unification. Type variables are just variables, but at type level. |
| 2023-10-11 15:16:38 +0000 | <kuribas> | unification is only used to infer them automatically. |
| 2023-10-11 15:17:08 +0000 | <haskellbridge> | <Inst> m1 (m2 b) -> (m2 b -> m1 b) -> m1 b ? |
| 2023-10-11 15:17:12 +0000 | <EvanR> | id is the identity function, and it works at all argument/result types |
| 2023-10-11 15:17:27 +0000 | <haskellbridge> | <Inst> actually, i'm checking whether id is kind polymorphic in its type variables |
| 2023-10-11 15:17:43 +0000 | <haskellbridge> | <Inst> :t won't give me whether or not it's forall (a::k). a -> a |
| 2023-10-11 15:17:53 +0000 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:17b7) |
| 2023-10-11 15:18:16 +0000 | <dolio> | Well, you could say, "you need to figure out how to instantiate variables to make the types match." That is just a description of what it means to unify two types. |
| 2023-10-11 15:18:29 +0000 | <haskellbridge> | <Inst> @c_wraith is this correct? |
| 2023-10-11 15:18:30 +0000 | <haskellbridge> | <Inst> m1 (m2 b) -> (m2 b -> m1 b) -> m1 b ? |
| 2023-10-11 15:18:37 +0000 | <[exa]> | hm guys what's the easiest way now to run Haskell as javascript in a web app? say `interact :: Textarea -> Textarea` or so :D |
| 2023-10-11 15:18:48 +0000 | <kuribas> | haskellbridge: no, id takes a value, which always must have kind Type (aka *) |
| 2023-10-11 15:18:49 +0000 | <[exa]> | no need to manipulate DOM, just string to string |
| 2023-10-11 15:18:53 +0000 | <c_wraith> | Inst: where did two different m types come from? |
| 2023-10-11 15:19:31 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 264 seconds) |
| 2023-10-11 15:19:52 +0000 | <haskellbridge> | <Inst> "Then the type of (>>=) is restricted to m (m b) -> (m b -> m b) -> m b" |
| 2023-10-11 15:19:59 +0000 | <haskellbridge> | <Inst> so distinguishing them as m1 and m2 |
| 2023-10-11 15:20:20 +0000 | <c_wraith> | Inst: but they're required to be the same. distinguishing them doesn't work |
| 2023-10-11 15:20:24 +0000 | fendor | (~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) |
| 2023-10-11 15:20:57 +0000 | <EvanR> | code with one >>= introduces only one monad |
| 2023-10-11 15:21:10 +0000 | <c_wraith> | Inst: the only uses of m came from the type of (>>=), and all three uses of m are the same in it |
| 2023-10-11 15:21:40 +0000 | <haskellbridge> | <Inst> no, i mean, the inner m is treated as a separate m, for purposes of matching the m a -> (a -> m b) -> m b type signature |
| 2023-10-11 15:21:59 +0000 | <haskellbridge> | <Inst> i guess it's just that i don't understand unification |
| 2023-10-11 15:22:10 +0000 | <EvanR> | in HM everything can start out as different type variables but they will later get unified |
| 2023-10-11 15:22:16 +0000 | <haskellbridge> | <Inst> also, implicitly, you could also have implicit join via an (m a -> m b) function, no? |
| 2023-10-11 15:22:25 +0000 | <EvanR> | like solving a system of equations |
| 2023-10-11 15:22:30 +0000 | <EvanR> | and m1 = m2 comes out |
| 2023-10-11 15:22:48 +0000 | <kuribas> | haskellbridge: (>>=) :: forall a b. m a -> (a -> m b) -> m b You can assign anything to `a`, for example `m b`, which gives forall b. m (m b) -> (m b -> m b) -> m b |
| 2023-10-11 15:22:52 +0000 | <haskellbridge> | <Inst> Thanks EvanR for the response :) |
| 2023-10-11 15:23:24 +0000 | <ncf> | what's an implicit join? |
| 2023-10-11 15:23:48 +0000 | <haskellbridge> | <Inst> foo :: (Monad m) => m a -> m b |
| 2023-10-11 15:24:12 +0000 | <EvanR> | Inst that is where explicit foralls come in handy, so you don't get confused by quantified variables and singular unknowns |
| 2023-10-11 15:24:26 +0000 | <EvanR> | so that you don't confuse the two |
| 2023-10-11 15:24:34 +0000 | <c_wraith> | that's... not a join. the idea of join is to collapse nested type constructors into a single application |
| 2023-10-11 15:24:37 +0000 | <haskellbridge> | <Inst> then ((u :: m (m a)) >>= foo) :: m b |
| 2023-10-11 15:24:53 +0000 | <haskellbridge> | <Inst> i mean that's implicit, if foo is m a -> m b |
| 2023-10-11 15:24:55 +0000 | <haskellbridge> | <Inst> then you bind into it |
| 2023-10-11 15:25:24 +0000 | <haskellbridge> | <Inst> not sure if Haskell's type system would respect this |
| 2023-10-11 15:25:32 +0000 | <EvanR> | if >>= is defined in terms of join may that's implicit join |
| 2023-10-11 15:25:40 +0000 | <EvanR> | (but it's not) |
| 2023-10-11 15:26:25 +0000 | <haskellbridge> | <Inst> i guess i'll play around with some Maybe a -> Maybe b functions to see what happens |
| 2023-10-11 15:26:30 +0000 | <c_wraith> | ah, I think I see what you're going for. my starting analysis there wasn't a universal observation. it was for specifically the case of (>>= id) |
| 2023-10-11 15:26:50 +0000 | <c_wraith> | when you unify the types of id and the second argument of (>>=) |
| 2023-10-11 15:27:42 +0000 | lena64t | (~lena64t@gateway/tor-sasl/hck) (Quit: WeeChat 4.0.0-dev) |
| 2023-10-11 15:27:50 +0000 | <haskellbridge> | <Inst> http://localhost:20662/_matrix/media/v1/download/matrix.org/GPPAVIEZjhBCAGewKMAzqono |
| 2023-10-11 15:28:00 +0000 | <EvanR> | (forall a b .) Maybe a -> Maybe b functions won't get very far. They have to return Nothing |
| 2023-10-11 15:28:15 +0000 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.0.4) |
| 2023-10-11 15:29:15 +0000 | <c_wraith> | um. wow, that link is useless. geekosaur, did the bridge convert it to localhost, or was that on Inst's matrix client? |
| 2023-10-11 15:29:21 +0000 | <ncf> | someone forgot to configure their matrix instance's base url |
| 2023-10-11 15:29:51 +0000 | <geekosaur> | the bridge isn';t accessible from outside so I can't expose the links created for images/media/etc. properly |
| 2023-10-11 15:30:02 +0000 | <geekosaur> | so it just uses localhost |
| 2023-10-11 15:30:37 +0000 | <geekosaur> | and Inst uses images instead of pastebins etc. so there's little to be done |
| 2023-10-11 15:30:47 +0000 | diamond | (~user@89.223.35.3) (Ping timeout: 255 seconds) |
| 2023-10-11 15:31:03 +0000 | <EvanR> | Inst, maybe post your content to twitter first and link that |
| 2023-10-11 15:31:19 +0000 | <haskellbridge> | <Inst> https://media.discordapp.net/attachments/968989726633779215/1161687327819710514/53db238e-f34c-49ec… |
| 2023-10-11 15:31:52 +0000 | <haskellbridge> | <Inst> I've boycotted twitter for a long time, would like to be able to boycott Discord eventually, but you have to be hooked into mainstream social media somehow |
| 2023-10-11 15:32:04 +0000 | <geekosaur> | (I can't make a tunnel through the building's firewall) |
| 2023-10-11 15:32:32 +0000 | <haskellbridge> | <Inst> Thanks for the answers, though. :) |
| 2023-10-11 15:32:36 +0000 | <EvanR> | Maybe a -> Maybe a has a few more options than Maybe a -> Maybe b |
| 2023-10-11 15:33:14 +0000 | <c_wraith> | it has one more option, if you're restricting yourself to total functions |
| 2023-10-11 15:33:50 +0000 | <c_wraith> | well. one more denotation. I suppose you could insert CPU-wasting code that wouldn't change the return value. |
| 2023-10-11 15:34:49 +0000 | <EvanR> | I'm embarrassed you even suggested such a thing. Extensional equality of course |
| 2023-10-11 15:35:27 +0000 | remexre | (~remexre@user/remexre) (Ping timeout: 240 seconds) |
| 2023-10-11 15:35:53 +0000 | <dolio> | Not into game semantics? |
| 2023-10-11 15:43:35 +0000 | <EvanR> | *reads wikipedia real fast* interesting |
| 2023-10-11 15:44:08 +0000 | <dolio> | Games are a relatively easy to understand intensional model of type theory. |
| 2023-10-11 15:44:38 +0000 | <c_wraith> | Conway's games? |
| 2023-10-11 15:45:07 +0000 | <dolio> | There's a difference between the `Maybe a -> Maybe b` game that just yields Nothing and the one that first challenges the opponent to provide their Maybe before yielding Nothing. |
| 2023-10-11 15:45:28 +0000 | <c_wraith> | nope. Conway's games are entirely different! glad to have that cleared up! |
| 2023-10-11 15:45:41 +0000 | <haskellbridge> | <Inst> Ah, since this isn't guaranteed to be a specialized id. It can just turn everything into Nothing. |
| 2023-10-11 15:46:26 +0000 | <danse-nr3> | [exa], wasm backend, javascript backend, purescript? There are other more exotic options |
| 2023-10-11 15:46:59 +0000 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-10-11 15:47:21 +0000 | <geekosaur> | I think ghcjs is still the preferred ghc-based way, ghcjs is still a tech preview |
| 2023-10-11 15:47:33 +0000 | <geekosaur> | er. js backend is still a tech preview |
| 2023-10-11 15:47:47 +0000 | <geekosaur> | they're working on it but it'll take time |
| 2023-10-11 15:47:56 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 15:48:11 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) |
| 2023-10-11 15:48:18 +0000 | <[exa]> | danse-nr3: is there some kind of howto? "I have this interact-only `main`, what to do now :D" |
| 2023-10-11 15:48:49 +0000 | <danse-nr3> | there is a wiki page about the "javascript problem" ... not sure how up to date |
| 2023-10-11 15:49:40 +0000 | <danse-nr3> | anyways it sounds like you want to write something relatively self-contained to be called from the javascript side. I think purescript was designed with this usecase in mind |
| 2023-10-11 15:50:13 +0000 | <[exa]> | hm does purescript have parsec |
| 2023-10-11 15:50:39 +0000 | <danse-nr3> | nope, it has a different ecosystem |
| 2023-10-11 15:50:46 +0000 | <EvanR> | the javascript problem. Specifically, it exists and there's nothing anyone can do about that |
| 2023-10-11 15:50:53 +0000 | <[exa]> | ah good it looks like there are parsecs for purescript |
| 2023-10-11 15:51:00 +0000 | <[exa]> | well I'll try purescript and see, thanks! |
| 2023-10-11 15:51:28 +0000 | <danse-nr3> | https://wiki.haskell.org/The_JavaScript_Problem |
| 2023-10-11 15:51:46 +0000 | notzmv | (~zmv@user/notzmv) |
| 2023-10-11 15:51:56 +0000 | <danse-nr3> | yeah i think purescript is one of the most practical approaches |
| 2023-10-11 15:53:11 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-10-11 15:56:21 +0000 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-10-11 15:57:06 +0000 | <EvanR> | quoting that page, we might not have time to teach people a new language, but people seem to have no problem inventing new languages at a rate that is borderline outlandish |
| 2023-10-11 15:57:30 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-10-11 15:57:47 +0000 | <[exa]> | but wait purescript is eager?? |
| 2023-10-11 15:58:15 +0000 | <yushyin> | yup |
| 2023-10-11 16:00:03 +0000 | <EvanR> | https://blog.drewolson.org/laziness-in-purescript |
| 2023-10-11 16:01:27 +0000 | <haskellbridge> | <Inst> wondering if it's possible to algorithmically generate all possible programming languages |
| 2023-10-11 16:01:45 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 258 seconds) |
| 2023-10-11 16:02:02 +0000 | <EvanR> | is that like generating a list of all real numbers |
| 2023-10-11 16:02:09 +0000 | sabino | (~sabino@user/sabino) |
| 2023-10-11 16:02:10 +0000 | <haskellbridge> | <Inst> feels like it |
| 2023-10-11 16:02:13 +0000 | <EvanR> | then no |
| 2023-10-11 16:02:29 +0000 | <haskellbridge> | <Inst> keywords are finite and countable |
| 2023-10-11 16:02:36 +0000 | <EvanR> | then yes |
| 2023-10-11 16:02:37 +0000 | <haskellbridge> | <Inst> number of keywords are also finite and countable |
| 2023-10-11 16:03:19 +0000 | <haskellbridge> | <Inst> number of possible design concepts probably aren't, though :( |
| 2023-10-11 16:03:46 +0000 | <EvanR> | [exa], on try.purescript.org I placed a division by zero in a tuple, then extracted the other component for one of the HTML elements output, and it didn't crash... |
| 2023-10-11 16:04:00 +0000 | shryke | (~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd) (Quit: WeeChat 4.0.5) |
| 2023-10-11 16:04:14 +0000 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Remote host closed the connection) |
| 2023-10-11 16:04:33 +0000 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) |
| 2023-10-11 16:04:34 +0000 | <EvanR> | maybe division by zero just isn't an error |
| 2023-10-11 16:04:58 +0000 | <[exa]> | division by zero in js is afaik Infinity |
| 2023-10-11 16:05:18 +0000 | <EvanR> | it's zero in purescript xD |
| 2023-10-11 16:05:28 +0000 | <EvanR> | so I learned nothing about the laziness |
| 2023-10-11 16:05:29 +0000 | <danse-nr3> | purescript is definitely strict |
| 2023-10-11 16:05:41 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 16:06:10 +0000 | <haskellbridge> | <Inst> Elm, giggle |
| 2023-10-11 16:06:33 +0000 | <haskellbridge> | <Inst> _ / 0 = 0 in Elm |
| 2023-10-11 16:06:54 +0000 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2023-10-11 16:06:56 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) |
| 2023-10-11 16:07:27 +0000 | <EvanR> | it's not an unreasonable definition if you want your page to load when the author is bad at math |
| 2023-10-11 16:08:04 +0000 | exarkun | (~exarkun@user/exarkun) (Excess Flood) |
| 2023-10-11 16:08:36 +0000 | <EvanR> | so to observe strictness we need an infinite loop probably... |
| 2023-10-11 16:08:58 +0000 | exarkun | (~exarkun@user/exarkun) |
| 2023-10-11 16:09:30 +0000 | <haskellbridge> | <Inst> Not sure if they copied that from Elm, Elm had a no exceptions promise, and they had to define _ / 0 as 0 to avoid exceptions |
| 2023-10-11 16:09:32 +0000 | <haskellbridge> | <Inst> it's an interesting problem |
| 2023-10-11 16:09:59 +0000 | <EvanR> | sure, did they also stop infinite loops |
| 2023-10-11 16:11:43 +0000 | danse-nr3 | (~francesco@151.37.182.55) (Ping timeout: 264 seconds) |
| 2023-10-11 16:11:59 +0000 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-11 16:12:00 +0000 | <haskellbridge> | <Inst> i mean, that, if you _ / 0, you can easily do Knight Capital Mark 2: https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html |
| 2023-10-11 16:12:01 +0000 | <geekosaur> | those don't throw exceptions |
| 2023-10-11 16:13:03 +0000 | <haskellbridge> | <Inst> i mean, that, if you div _ 0, you can easily do Knight Capital Mark 2: https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html |
| 2023-10-11 16:13:10 +0000 | <EvanR> | I managed to put in an infinite loop and observe the strictness |
| 2023-10-11 16:13:16 +0000 | <EvanR> | no exceptions but nothing good either |
| 2023-10-11 16:13:28 +0000 | <[exa]> | I'll do with Elm |
| 2023-10-11 16:13:40 +0000 | <haskellbridge> | <Inst> how can you observe the strictness if the strictness is infinite? |
| 2023-10-11 16:13:51 +0000 | <geekosaur> | Injst, please don't do edits in here (see the Matrix-side topic) |
| 2023-10-11 16:14:01 +0000 | <geekosaur> | *Inst |
| 2023-10-11 16:14:02 +0000 | <[exa]> | infinite things are noticeably easy to observe due to size |
| 2023-10-11 16:14:10 +0000 | <haskellbridge> | <Inst> yeah, undersstood |
| 2023-10-11 16:14:24 +0000 | <haskellbridge> | <Inst> it was _ / 0, edited to div _ 0 defined as 0 |
| 2023-10-11 16:15:02 +0000 | remexre | (~remexre@user/remexre) |
| 2023-10-11 16:17:05 +0000 | <geekosaur> | yes, and the bridge repeated the whole message because IRC doesn't support edits |
| 2023-10-11 16:17:42 +0000 | <geekosaur> | this is an IRC channel to which I have provided Matrix access, with some constraints. if those constraints are violated I can and will shut down the bridge |
| 2023-10-11 16:18:29 +0000 | danse-nr3 | (~francesco@151.37.182.55) |
| 2023-10-11 16:18:45 +0000 | Guest22 | (~Guest22@136.25.94.94) |
| 2023-10-11 16:18:48 +0000 | <haskellbridge> | <Inst> I see, understood, sorry, it's become habitual. And yeah, I usually use the IRC side, but trying to cut down on wasteful social media use. |
| 2023-10-11 16:18:54 +0000 | Guest22 | (~Guest22@136.25.94.94) (Client Quit) |
| 2023-10-11 16:18:56 +0000 | ghoulguy | (g@libera/staff/glguy) (Quit: Quit) |
| 2023-10-11 16:18:56 +0000 | g | (g@libera/staff/glguy) (Remote host closed the connection) |
| 2023-10-11 16:19:16 +0000 | EitanCh | (~EitanCh@136.25.94.94) |
| 2023-10-11 16:19:48 +0000 | g | (g@libera/staff/glguy) |
| 2023-10-11 16:20:18 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-10-11 16:20:48 +0000 | glguy | (g@libera/staff/glguy) |
| 2023-10-11 16:23:40 +0000 | <EitanCh> | Hello, I'm trying to define an analog for the `many` Alternative combinator for Profunctors but when I try to use it it infinite loops on me. The definition involves mutual recursion. Am I missing something obvious that causes it to loop forever? Here's the code: |
| 2023-10-11 16:23:41 +0000 | <EitanCh> | several |
| 2023-10-11 16:23:41 +0000 | <EitanCh> | :: (Cons s s a a, Cons t t b b, Monoid t) |
| 2023-10-11 16:23:42 +0000 | <EitanCh> | => p a b -> p s t |
| 2023-10-11 16:23:42 +0000 | <EitanCh> | several p = several_p where |
| 2023-10-11 16:23:43 +0000 | <EitanCh> | several_p = withIso _Stream $ \f g -> |
| 2023-10-11 16:23:43 +0000 | <EitanCh> | dimap f g (pure () >+< several1_p) |
| 2023-10-11 16:23:43 +0000 | EitanCh | (~EitanCh@136.25.94.94) (Killed (ozone (No Spam))) |
| 2023-10-11 16:24:44 +0000 | DemonDerg | (A_D@libera/staff/dragon) |
| 2023-10-11 16:26:22 +0000 | <geekosaur> | they are, but oh well |
| 2023-10-11 16:27:13 +0000 | <EvanR> | so the network is on spam alert high |
| 2023-10-11 16:27:22 +0000 | <EvanR> | spam alert elevateed |
| 2023-10-11 16:27:42 +0000 | <geekosaur> | well, yes. have you not noticed all the "just paste it" spam of late? |
| 2023-10-11 16:27:47 +0000 | <EvanR> | yes |
| 2023-10-11 16:27:53 +0000 | <geekosaur> | and we got spammed by supernets the other day too |
| 2023-10-11 16:28:05 +0000 | <DemonDerg> | was that a misban? |
| 2023-10-11 16:28:19 +0000 | <geekosaur> | yeh, just someone pasting a question into the channel |
| 2023-10-11 16:28:24 +0000 | <geekosaur> | which ozone didn't like |
| 2023-10-11 16:28:41 +0000 | <DemonDerg> | what was the nick? |
| 2023-10-11 16:28:44 +0000 | <geekosaur> | (we don't either, but first timers don't know that) |
| 2023-10-11 16:28:47 +0000 | <geekosaur> | EitanCh |
| 2023-10-11 16:29:50 +0000 | <DemonDerg> | removed |
| 2023-10-11 16:29:56 +0000 | <geekosaur> | thank you |
| 2023-10-11 16:30:27 +0000 | <ncf> | dolio: do you have a recommended resource for game semantics and type theory? |
| 2023-10-11 16:31:14 +0000 | danse-nr3 | failing to "quickly reach out to them" |
| 2023-10-11 16:31:34 +0000 | <ncf> | i guess the nlab has two |
| 2023-10-11 16:31:51 +0000 | <geekosaur> | not sure they'd be trying again quickly after being klined |
| 2023-10-11 16:32:01 +0000 | <dolio> | Not really. This explains a little, though: https://www.youtube.com/watch?v=uY5LubwJ1Xo |
| 2023-10-11 16:32:12 +0000 | <DemonDerg> | unfortunately yeah |
| 2023-10-11 16:33:05 +0000 | <danse-nr3> | maybe we can leave a message through the bot? |
| 2023-10-11 16:33:20 +0000 | <ncf> | ah, that's the author of one of the papers i found (now "withdrawn" from arxiv, but you can still read it, wtf?) |
| 2023-10-11 16:34:08 +0000 | danse-nr3 | (~francesco@151.37.182.55) (Remote host closed the connection) |
| 2023-10-11 16:34:33 +0000 | danse-nr3 | (~francesco@151.37.182.55) |
| 2023-10-11 16:34:43 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 258 seconds) |
| 2023-10-11 16:35:12 +0000 | <DemonDerg> | also while Im looking about, you all seen any extra supernets spam or so today? |
| 2023-10-11 16:36:54 +0000 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-10-11 16:38:06 +0000 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds) |
| 2023-10-11 16:38:12 +0000 | <EvanR> | types are games and terms are strategies |
| 2023-10-11 16:38:33 +0000 | Square3 | (~Square4@user/square) |
| 2023-10-11 16:38:50 +0000 | <dolio> | Yeah, I guess I should have said "strategy" above. |
| 2023-10-11 16:39:46 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) |
| 2023-10-11 16:39:51 +0000 | <dolio> | For the two distinct values of Maybe a -> Maybe b. |
| 2023-10-11 16:42:16 +0000 | <danse-nr3> | hum so i guess a term is what i used to call a type's "value" |
| 2023-10-11 16:42:45 +0000 | <dolio> | Well, terms are syntactic things. |
| 2023-10-11 16:42:51 +0000 | <dolio> | Terms denote strategies. |
| 2023-10-11 16:44:04 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 16:46:22 +0000 | <danse-nr3> | i see, thanks |
| 2023-10-11 16:47:25 +0000 | <geekosaur> | DemonDerg, not today. had some jp.it last night but I didn't wake up to any this morning for a change |
| 2023-10-11 16:48:01 +0000 | <geekosaur> | btw there used to be some protocol for chanops to follow if ozone incorrectly klined someone, does that still exist? |
| 2023-10-11 16:48:07 +0000 | <DemonDerg> | it does |
| 2023-10-11 16:48:17 +0000 | <DemonDerg> | be opped and message it unkline $nick, IIRC |
| 2023-10-11 16:48:40 +0000 | <geekosaur> | thank you |
| 2023-10-11 16:48:46 +0000 | <DemonDerg> | https://libera.chat/guides/bots#ozone |
| 2023-10-11 16:49:09 +0000 | <DemonDerg> | should also op any bots you have in here |
| 2023-10-11 16:49:12 +0000 | <DemonDerg> | sorry, voice |
| 2023-10-11 16:49:13 +0000 | <DemonDerg> | not op |
| 2023-10-11 16:49:18 +0000 | <DemonDerg> | apologies, long day |
| 2023-10-11 16:50:39 +0000 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 16:51:04 +0000 | <geekosaur> | that one's not up to me, I'll mention it in the ops channel |
| 2023-10-11 16:51:15 +0000 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-11 16:52:01 +0000 | stites | (~stites@130.44.147.204) (Ping timeout: 252 seconds) |
| 2023-10-11 16:52:33 +0000 | stites | (~stites@2607:fb91:dc8:e0e2:5656:70eb:8498:35ff) |
| 2023-10-11 16:54:31 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 17:03:40 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 17:04:42 +0000 | AlexNoo_ | (~AlexNoo@94.233.241.173) |
| 2023-10-11 17:05:06 +0000 | euleritian | (~euleritia@46.114.206.159) (Read error: Connection reset by peer) |
| 2023-10-11 17:05:23 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 17:06:47 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2023-10-11 17:07:32 +0000 | AlexZenon | (~alzenon@178.34.163.10) (Ping timeout: 255 seconds) |
| 2023-10-11 17:07:49 +0000 | Alex_test | (~al_test@178.34.163.10) (Ping timeout: 255 seconds) |
| 2023-10-11 17:07:59 +0000 | AlexNoo | (~AlexNoo@178.34.163.10) (Ping timeout: 245 seconds) |
| 2023-10-11 17:08:15 +0000 | AlexNoo_ | AlexNoo |
| 2023-10-11 17:08:20 +0000 | emergence | (emergence@2607:5300:60:5910:dcad:beff:feef:5bc) |
| 2023-10-11 17:09:50 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 17:09:57 +0000 | asivitz | (uid178348@id-178348.tinside.irccloud.com) |
| 2023-10-11 17:10:41 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 17:11:12 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) |
| 2023-10-11 17:12:28 +0000 | ChanServ | +o monochrom |
| 2023-10-11 17:12:31 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2023-10-11 17:12:53 +0000 | ChanServ | +v lambdabot |
| 2023-10-11 17:13:06 +0000 | ChanServ | +v yahb2 |
| 2023-10-11 17:13:07 +0000 | Alex_test | (~al_test@94.233.241.173) |
| 2023-10-11 17:13:22 +0000 | ChanServ | +v haskellbridge |
| 2023-10-11 17:13:30 +0000 | monochrom | -o monochrom |
| 2023-10-11 17:13:47 +0000 | AlexZenon | (~alzenon@94.233.241.173) |
| 2023-10-11 17:15:21 +0000 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-10-11 17:15:31 +0000 | lg188 | (~lg188@82.18.98.230) (Quit: Bye.) |
| 2023-10-11 17:16:16 +0000 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-10-11 17:16:42 +0000 | danse-nr3 | (~francesco@151.37.182.55) (Ping timeout: 260 seconds) |
| 2023-10-11 17:21:10 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 17:25:38 +0000 | lg188 | (~lg188@82.18.98.230) (Read error: Connection reset by peer) |
| 2023-10-11 17:25:46 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-10-11 17:27:49 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 17:30:08 +0000 | lg188 | (~lg188@82.18.98.230) (Read error: Connection reset by peer) |
| 2023-10-11 17:32:59 +0000 | <EvanR> | Data.ByteString docs state that it is suitable for high performance, then it says it's implemented as a ForeignPtr. Does this mean ByteStrings have FFI overhead or is FFI not involved |
| 2023-10-11 17:33:13 +0000 | stites | (~stites@2607:fb91:dc8:e0e2:5656:70eb:8498:35ff) (Read error: Connection reset by peer) |
| 2023-10-11 17:33:39 +0000 | stites | (~stites@130.44.147.204) |
| 2023-10-11 17:34:40 +0000 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-11 17:34:49 +0000 | simendsjo | (~user@84.211.91.241) |
| 2023-10-11 17:36:52 +0000 | <EvanR> | also when looking at how BS.takeWhile is implemented I noticed accursedUnutterablePerformIO, which I thought was considered unprofessional and renamed xD |
| 2023-10-11 17:37:42 +0000 | <EvanR> | which also answers the question because there's the FFI |
| 2023-10-11 17:38:46 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection) |
| 2023-10-11 17:39:41 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) |
| 2023-10-11 17:41:12 +0000 | <geekosaur> | ByteString is what invented it… and discovered why it's a bad idea |
| 2023-10-11 17:41:20 +0000 | <geekosaur> | but they still use it for performance |
| 2023-10-11 17:41:37 +0000 | <geekosaur> | and yes, it FFIs again for performance |
| 2023-10-11 17:41:57 +0000 | ski | (~ski@88.131.7.247) |
| 2023-10-11 17:42:23 +0000 | <geekosaur> | I think they cheat there and use unsafe calls? which avoids the overhead but they have to be very careful with it |
| 2023-10-11 17:42:55 +0000 | <geekosaur> | then again they're looking for performance so they're avoiding anything that would block and thereby be unsafe from a FFI standpoint |
| 2023-10-11 17:48:18 +0000 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 17:48:34 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-10-11 17:51:14 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:24c5:ca27:9366:8391) |
| 2023-10-11 17:53:50 +0000 | Simikando | (~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Remote host closed the connection) |
| 2023-10-11 17:55:58 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:24c5:ca27:9366:8391) (Ping timeout: 272 seconds) |
| 2023-10-11 17:56:55 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 18:02:44 +0000 | <EvanR> | FFI has more performance than what, using a primitive array? |
| 2023-10-11 18:04:46 +0000 | <[exa]> | ok so today I learned that Elm ain't very good for functional programming. :D |
| 2023-10-11 18:05:10 +0000 | <EvanR> | yeeeeeaahh.... |
| 2023-10-11 18:05:33 +0000 | <[exa]> | "error: too much recursion" when trying elm/parser to do JSON, like, where are we |
| 2023-10-11 18:05:49 +0000 | <[exa]> | there's never enough recursion! |
| 2023-10-11 18:06:22 +0000 | <EvanR> | what a disgrace |
| 2023-10-11 18:07:48 +0000 | <[exa]> | somehow I tend to understand "compile to javascript" a bit more elaborately as "direct source-to-source homomorphism to javascript" |
| 2023-10-11 18:07:58 +0000 | <[exa]> | *than |
| 2023-10-11 18:08:13 +0000 | <[exa]> | ok nvm probably time to write my own language for this. :D |
| 2023-10-11 18:13:14 +0000 | <EvanR> | what made you go for Elm over purescript |
| 2023-10-11 18:13:31 +0000 | Square3 | (~Square4@user/square) (Ping timeout: 264 seconds) |
| 2023-10-11 18:15:22 +0000 | rgw | (~R@2605:a601:a0df:5600:786b:f462:3e9c:5be6) |
| 2023-10-11 18:15:26 +0000 | <[exa]> | I somehow thought it's not eager. |
| 2023-10-11 18:15:40 +0000 | <[exa]> | ;_; |
| 2023-10-11 18:16:12 +0000 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
| 2023-10-11 18:17:33 +0000 | <mauke> | no warnings qw(recursion); # if this were perl ... |
| 2023-10-11 18:17:43 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 18:18:15 +0000 | <monochrom> | haha |
| 2023-10-11 18:18:55 +0000 | <monochrom> | But yeah I'm disappointed. It is no longer rocket science to write a translator that does CPS and trampolining for you. |
| 2023-10-11 18:19:03 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-10-11 18:19:17 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2023-10-11 18:20:24 +0000 | <monochrom> | Then again there is a conflict between "translate to js but preserve semantics" and "translate to js but make it idiomatic js". |
| 2023-10-11 18:20:40 +0000 | <monochrom> | s/semantics/source-language semantics/ to be precise |
| 2023-10-11 18:20:56 +0000 | <mauke> | do you know a language that has explicit tail calls? i.e. where the programmer can say "jump to this function over there, no return" |
| 2023-10-11 18:21:12 +0000 | <monochrom> | Does iptables count? :) |
| 2023-10-11 18:21:22 +0000 | <mauke> | I was about to say, outside of asm |
| 2023-10-11 18:21:45 +0000 | <mauke> | iptables looks to me like a similar idea, just chains of instructions |
| 2023-10-11 18:22:03 +0000 | <monochrom> | I think Scheme counts, but perhaps indirectly. |
| 2023-10-11 18:22:06 +0000 | <geekosaur> | I feel like I've seen a language that has `goto <some function>` but I'm not recalling it |
| 2023-10-11 18:22:12 +0000 | <mauke> | that's perl |
| 2023-10-11 18:22:18 +0000 | <geekosaur> | oh, right |
| 2023-10-11 18:22:45 +0000 | <mauke> | I'm wondering if perl invented it or whether there's precedent elsewhere |
| 2023-10-11 18:22:46 +0000 | <geekosaur> | been too long |
| 2023-10-11 18:22:49 +0000 | <monochrom> | Scheme's definition makes it completely predictable which calls become tail calls and the others don't. |
| 2023-10-11 18:22:55 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) |
| 2023-10-11 18:23:21 +0000 | <mauke> | scheme is more on the side of guaranteed optimizations, I'd say |
| 2023-10-11 18:23:27 +0000 | <mauke> | along the lines of ApplicativeDo |
| 2023-10-11 18:23:35 +0000 | <monochrom> | Yeah that's true. |
| 2023-10-11 18:24:41 +0000 | <EvanR> | llvm has explicit tail calls, C--? |
| 2023-10-11 18:25:00 +0000 | <[exa]> | monochrom: "idiomatic js" and then people claim react+jsx outputs as good :D |
| 2023-10-11 18:26:11 +0000 | <mauke> | EvanR: ok, but those aren't meant to be written by humans |
| 2023-10-11 18:26:26 +0000 | <mauke> | I was looking for more high-level things :-) |
| 2023-10-11 18:26:34 +0000 | <monochrom> | llvm is too close to asm |
| 2023-10-11 18:26:58 +0000 | <[exa]> | mauke: does 'yield' count? |
| 2023-10-11 18:27:12 +0000 | <monochrom> | In fact, too close to ideal asm, too. You actually write single-assignments and phi nodes! |
| 2023-10-11 18:27:46 +0000 | <mauke> | [exa]: in a way, yield is the exact opposite |
| 2023-10-11 18:27:48 +0000 | <[exa]> | mauke: also maybe you were searching for........high level assembler, the gem of IBM! |
| 2023-10-11 18:28:19 +0000 | <mauke> | yield returns up instead of calling deeper, and it can return instead of making everything after it unreachable |
| 2023-10-11 18:28:46 +0000 | <ski> | "proper tail recursion" in Scheme is not an optimization (and doesn't need to be implemented via TCO), it's a language guarantee (about asymptotic space usage of a (conforming) implementation (that it can support an unbounded number of active tail calls in bounded space)) |
| 2023-10-11 18:29:12 +0000 | danza | (~francesco@151.37.182.55) |
| 2023-10-11 18:33:32 +0000 | <EvanR> | llvm, portable assembly. Unlike C |
| 2023-10-11 18:34:38 +0000 | <EvanR> | is proper tail recursion the technical name in scheme? |
| 2023-10-11 18:34:56 +0000 | <ski> | yes |
| 2023-10-11 18:35:01 +0000 | <EvanR> | nice |
| 2023-10-11 18:35:31 +0000 | <ski> | in Prolog, the term is "Last Call" as opposed to "Tail Call" (the concept was discovered independently in LP) |
| 2023-10-11 18:37:36 +0000 | <ski> | (there's also TCMC, Tail-Call Modulo Cons(tructor), where you (e.g.) first construct the cons cell of the list, then pass the address of the tail field in the cell to the (usually) recursive call, to fill in (initialize/instantiate) the rest .. the Logic/Functional programming language Mercury can do this, and OCaml also has some support) |
| 2023-10-11 18:38:32 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2023-10-11 18:39:22 +0000 | <ski> | (i recall reading somewhere that because Erlang doesn't have TCMC, a serialization framework for it decided to serialize the elements of lists in reverse order, so that when deserializing it can reconstruct the list with a tail recursion) |
| 2023-10-11 18:41:05 +0000 | <mauke> | should've had first-class lvalues :-D |
| 2023-10-11 18:41:09 +0000 | <EvanR> | to be clear, are we talking about construction an entire actual list in memory |
| 2023-10-11 18:41:18 +0000 | <ski> | yes |
| 2023-10-11 18:41:23 +0000 | <EvanR> | crazy |
| 2023-10-11 18:41:35 +0000 | <mauke> | the depravity |
| 2023-10-11 18:42:55 +0000 | <EvanR> | many languages, purescript included, seem to have a facility for doing lazy list processing in an otherwise non-lazy language. But I don't often see people in those languages enthusiastic about it |
| 2023-10-11 18:43:09 +0000 | <monochrom> | Well this being OCaml etc., "map f (x:xs) = f x : map f xs" is a bit sad until TCMC. |
| 2023-10-11 18:43:09 +0000 | <EvanR> | I wonder if it's just cargo culting xD |
| 2023-10-11 18:44:10 +0000 | <monochrom> | Well yeah most people aren't thrilled about lazy evaluation. |
| 2023-10-11 18:45:08 +0000 | <dolio> | Why use lazy evaluation when you can manually convolute your program so that things happen in the right order? |
| 2023-10-11 18:45:29 +0000 | <monochrom> | I like lazy evaluation because I see the half-full glass that offers "map f (x:xs) = f x : map f xs is already constant-space without doing anything special" |
| 2023-10-11 18:46:00 +0000 | <monochrom> | But other people see the half-empty glass that offers "foldl (+) 0 xs is linear space" |
| 2023-10-11 18:46:29 +0000 | <mauke> | map f xs = x <- await xs; yield (f x); map f xs |
| 2023-10-11 18:48:20 +0000 | ski | (~ski@88.131.7.247) (Ping timeout: 255 seconds) |
| 2023-10-11 18:49:06 +0000 | <EvanR> | foldl not prime on list is a fully empty glass, unless you're implementing last |
| 2023-10-11 18:49:45 +0000 | <EvanR> | why isn't your map example fully full ? xD |
| 2023-10-11 18:50:04 +0000 | <EvanR> | (also, fully empty? wtf) |
| 2023-10-11 18:50:20 +0000 | <monochrom> | Because lazy evaluation is a superposition of both :) |
| 2023-10-11 18:53:21 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5) |
| 2023-10-11 18:53:59 +0000 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds) |
| 2023-10-11 18:54:10 +0000 | <EvanR> | is that why we don't want to redefine foldl to be strict, we want to be reminded of the flaws in our ways |
| 2023-10-11 18:54:46 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) |
| 2023-10-11 18:55:06 +0000 | <EvanR> | better to admit it than paper over it and hide the truth |
| 2023-10-11 18:55:43 +0000 | <mauke> | @src foldl' |
| 2023-10-11 18:55:43 +0000 | <lambdabot> | foldl' f a [] = a |
| 2023-10-11 18:55:43 +0000 | <lambdabot> | foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs |
| 2023-10-11 18:55:48 +0000 | <nullie> | isn't lazy evaluation a leaky abstraction? |
| 2023-10-11 18:56:00 +0000 | <monochrom> | No, I think we are just too polite to change historical definitions, even those that were flawed. |
| 2023-10-11 18:56:01 +0000 | <mauke> | is foldl' guaranteed to work any better? |
| 2023-10-11 18:56:24 +0000 | <monochrom> | Just look at how people are too polite to actually delete things on the haskell wiki. |
| 2023-10-11 18:56:52 +0000 | <monochrom> | Yes. |
| 2023-10-11 18:57:28 +0000 | <EvanR> | foldl' arguably works worse when defining last |
| 2023-10-11 18:57:35 +0000 | <mauke> | why? |
| 2023-10-11 18:57:35 +0000 | <EvanR> | which no one ever does |
| 2023-10-11 18:58:02 +0000 | <dolio> | mauke: Because it blows up if any non-last elements are undefined. |
| 2023-10-11 18:58:21 +0000 | <dolio> | If I recall. |
| 2023-10-11 18:58:52 +0000 | <mauke> | no, why is foldl' guaranteed to work better for summing? |
| 2023-10-11 18:59:07 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 18:59:41 +0000 | <monochrom> | You have: let a'=a+x in seq a' (foldl' (+) a' xs) |
| 2023-10-11 19:00:20 +0000 | <mauke> | seq a b = seq b (seq a b) |
| 2023-10-11 19:00:57 +0000 | <monochrom> | Well OK, next we have to choose one of two paths. |
| 2023-10-11 19:01:00 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 19:01:38 +0000 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-10-11 19:02:01 +0000 | <monochrom> | One path is: You say that the Haskell Report promises strictness only, but then a compiler adds optimizations based on strictness, so a+x is evaluated earlier. |
| 2023-10-11 19:02:11 +0000 | danza | (~francesco@151.37.182.55) (Ping timeout: 255 seconds) |
| 2023-10-11 19:02:19 +0000 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-10-11 19:02:23 +0000 | <monochrom> | The other path is: I say that seq promises evaluation order in the context of lazy evaluation. |
| 2023-10-11 19:03:05 +0000 | <monochrom> | I know, neither path is actually completely guaranteed by any signed rubber-stamped documents. |
| 2023-10-11 19:05:11 +0000 | <monochrom> | But what else is guaranteed by the Haskell Report anyway apart from syntax? :) |
| 2023-10-11 19:05:43 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds) |
| 2023-10-11 19:05:45 +0000 | <dolio> | It would take extra work to provide the right semantics without making the sum cases better, I think. |
| 2023-10-11 19:06:26 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) (Remote host closed the connection) |
| 2023-10-11 19:06:41 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) |
| 2023-10-11 19:07:46 +0000 | <monochrom> | I raise two points outside the signed rubber-stamped documents. |
| 2023-10-11 19:08:51 +0000 | <monochrom> | 1. Consider why it ends up being named "seq" rather than, say, "strict". (In fact, an old textbook of Bird called it "strict". (And went on to show the confusion between strict/non-strict and eager/lazy.)) |
| 2023-10-11 19:09:23 +0000 | privacy | (~privacy@user/privacy) |
| 2023-10-11 19:10:46 +0000 | <monochrom> | 2. John Hughes in an interview said: His contribution was adding a way to disable laziness to solve the space problem. |
| 2023-10-11 19:10:50 +0000 | lg188 | (~lg188@82.18.98.230) (Ping timeout: 255 seconds) |
| 2023-10-11 19:11:33 +0000 | <EvanR> | also language gains meaning through use, and that's how/why it's used |
| 2023-10-11 19:11:43 +0000 | <monochrom> | The intention of seq is very much eagerness, despite how the committee was too afraid to put in black on white. |
| 2023-10-11 19:13:45 +0000 | <mauke> | seq (error "a") (error "b") |
| 2023-10-11 19:14:07 +0000 | <EvanR> | > seq (error "a") (error "b") |
| 2023-10-11 19:14:09 +0000 | <lambdabot> | *Exception: a |
| 2023-10-11 19:14:18 +0000 | <mauke> | I don't think ghc guarantees "a" |
| 2023-10-11 19:14:18 +0000 | <EvanR> | cromulent |
| 2023-10-11 19:14:43 +0000 | <EvanR> | at least that test doesn't contradict the arguments made by monochrom |
| 2023-10-11 19:14:52 +0000 | <monochrom> | You are right about that. When there are two errors to choose from, GHC optimizations can end up choosing the unexpected one. |
| 2023-10-11 19:14:54 +0000 | <mauke> | true, but why does pseq exist? |
| 2023-10-11 19:14:56 +0000 | <dolio> | It's not about "afraid." Imposing an exact evaluation order is less useful. |
| 2023-10-11 19:15:08 +0000 | <EvanR> | but not I kind of see the value in rubber stamped documents "guaranteeing" something, it makes this entire discussion miraculously unnecessary |
| 2023-10-11 19:15:20 +0000 | <EvanR> | now* |
| 2023-10-11 19:16:07 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) (Remote host closed the connection) |
| 2023-10-11 19:16:15 +0000 | <monochrom> | But foldl' (+) 0 [1..10000] contains no errors. The same strictness analysis and optimizations will keep it constant space. |
| 2023-10-11 19:17:08 +0000 | <dolio> | You want to enable the compiler to make good decisions about the exact evaluation order given the local context it has. For sum, the compiler knows what to do as long as it isn't required to give the non-strict semantics. |
| 2023-10-11 19:17:32 +0000 | <dolio> | That you can be a pedantic dipshit and say, "technically it could do something really bad instead," is irrelevant. |
| 2023-10-11 19:18:05 +0000 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-10-11 19:21:39 +0000 | <monochrom> | pseq exists because, hell, even today, GHC optimizer isn't quite aware of parallelization. |
| 2023-10-11 19:25:29 +0000 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-10-11 19:27:42 +0000 | phma_ | (~phma@host-67-44-208-58.hnremote.net) |
| 2023-10-11 19:31:11 +0000 | <monochrom> | You know what, I don't think even standard C states that "x = 0;" takes constant space or constant time. :) |
| 2023-10-11 19:31:13 +0000 | phma | (~phma@host-67-44-208-58.hnremote.net) (Ping timeout: 255 seconds) |
| 2023-10-11 19:31:59 +0000 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:17b7) (Read error: Connection reset by peer) |
| 2023-10-11 19:32:07 +0000 | <mauke> | I wonder if C even has time |
| 2023-10-11 19:32:14 +0000 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:17b7) |
| 2023-10-11 19:44:10 +0000 | <EvanR> | as you approach C time comes to a stop so no |
| 2023-10-11 19:46:55 +0000 | <monochrom> | haha |
| 2023-10-11 19:47:05 +0000 | <monochrom> | @quote monochrom einstein |
| 2023-10-11 19:47:06 +0000 | <lambdabot> | monochrom says: einstein's theory implies that haskell cannot be faster than c |
| 2023-10-11 19:47:30 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5) |
| 2023-10-11 19:48:33 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5d3c:fd45:6dba:f35a) |
| 2023-10-11 19:49:05 +0000 | iteratee | (~kyle@162.218.222.207) (Ping timeout: 255 seconds) |
| 2023-10-11 19:49:30 +0000 | iteratee | (~kyle@162.218.222.207) |
| 2023-10-11 19:49:54 +0000 | alphacentauri | (alphacenta@gateway/vpn/protonvpn/alphacentauri) |
| 2023-10-11 19:50:47 +0000 | <EvanR> | right now I'm trying to write a haskell version of a tool script in the zig codebase. Right now with optimizations I'm at .043ms while the zig version is .005ms |
| 2023-10-11 19:52:05 +0000 | <EvanR> | 11% zig |
| 2023-10-11 19:53:00 +0000 | <mauke> | move `zig` |
| 2023-10-11 19:54:15 +0000 | <EvanR> | hopefully I can pick up some time by going through ByteString instead of String I/O |
| 2023-10-11 19:55:51 +0000 | <mauke> | what does the tool do? |
| 2023-10-11 19:56:17 +0000 | iteratee | (~kyle@162.218.222.207) (Ping timeout: 255 seconds) |
| 2023-10-11 19:56:29 +0000 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-11 19:56:33 +0000 | iteratee | (~kyle@162.218.222.207) |
| 2023-10-11 19:57:49 +0000 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-10-11 19:58:25 +0000 | <EvanR> | it extracts syscall numbers from linux source code from various files and creates a zig file |
| 2023-10-11 19:58:39 +0000 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-10-11 19:59:36 +0000 | <EvanR> | well the product just goes to stdout |
| 2023-10-11 19:59:54 +0000 | <mauke> | ah, like h2ph / syscall.ph |
| 2023-10-11 20:03:26 +0000 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2023-10-11 20:05:16 +0000 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-11 20:06:01 +0000 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2023-10-11 20:09:35 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-10-11 20:11:48 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-10-11 20:12:58 +0000 | ft | (~ft@p3e9bc680.dip0.t-ipconnect.de) |
| 2023-10-11 20:15:58 +0000 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-10-11 20:28:01 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 20:37:12 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) |
| 2023-10-11 20:39:23 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 255 seconds) |
| 2023-10-11 20:39:45 +0000 | __monty__ | (~toonn@user/toonn) |
| 2023-10-11 20:41:57 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-11 20:41:57 +0000 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-11 20:41:57 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-11 20:47:27 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-10-11 20:53:41 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-10-11 20:58:32 +0000 | michalz | (~michalz@185.246.207.200) (Remote host closed the connection) |
| 2023-10-11 21:01:13 +0000 | pavonia | (~user@user/siracusa) |
| 2023-10-11 21:05:28 +0000 | phma_ | phma |
| 2023-10-11 21:06:03 +0000 | myxos | (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 2023-10-11 21:10:22 +0000 | simendsjo | (~user@84.211.91.241) (Ping timeout: 255 seconds) |
| 2023-10-11 21:13:05 +0000 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-10-11 21:14:49 +0000 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Quit: Leaving) |
| 2023-10-11 21:18:23 +0000 | fendor | (~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection) |
| 2023-10-11 21:22:20 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-10-11 21:24:02 +0000 | cpressey | (~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed) |
| 2023-10-11 21:27:27 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-11 21:30:04 +0000 | acidjnk | (~acidjnk@p200300d6e7072f8019cae40178150491.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2023-10-11 21:32:05 +0000 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-10-11 21:42:05 +0000 | Jackneill | (~Jackneill@20014C4E1E021C00E4226B7959631CE0.dsl.pool.telekom.hu) (Ping timeout: 240 seconds) |
| 2023-10-11 21:42:12 +0000 | Inst | (~Inst@120.244.192.250) |
| 2023-10-11 21:42:35 +0000 | <Inst> | what are the efficiency advantages of a list comprehension vs filter? |
| 2023-10-11 21:44:01 +0000 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-10-11 21:45:18 +0000 | <davean> | Inst: I mean list comprehensions are far more powerful than filter. |
| 2023-10-11 21:45:57 +0000 | <davean> | You're comparing a helicopter to a ski lift. Thy can both get you up the mountain. Whats the efficiency difference? For doing what filter can do? |
| 2023-10-11 21:46:07 +0000 | <Inst> | i guess it's more easy to extend, I'm discussing code in cabal, and I'm surprised this is being done via a list comprehension instead of a filter, but I'm called a point-free addict sometimes |
| 2023-10-11 21:46:10 +0000 | <haskellbridge> | <sm> did you mean list comprehensions vs standard function composition ? no difference I think |
| 2023-10-11 21:46:39 +0000 | <haskellbridge> | <sm> it's a readability choice |
| 2023-10-11 21:46:55 +0000 | <Inst> | [ cmd | cmd@(Command cname' _ _ _) <- commands', cname' == cname] vs |
| 2023-10-11 21:47:13 +0000 | <Inst> | filter (\(Command cname' _ _ _) -> cname' == cname) |
| 2023-10-11 21:47:16 +0000 | <geekosaur> | @undo [ cmd | cmd@(Command cname' _ _ _) <- commands', cname' == cname] |
| 2023-10-11 21:47:16 +0000 | <lambdabot> | concatMap (\ a -> case a of { cmd@(Command cname' _ _ _) -> if cname' == cname then [cmd] else []; _ -> []}) commands' |
| 2023-10-11 21:47:47 +0000 | <davean> | geekosaur: that is the worst undo of that ... |
| 2023-10-11 21:47:52 +0000 | <geekosaur> | yeh |
| 2023-10-11 21:47:59 +0000 | <davean> | I'd be hard pressed to write a worse version of undoing it. |
| 2023-10-11 21:47:59 +0000 | <geekosaur> | thought it used map and filter these days |
| 2023-10-11 21:48:19 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds) |
| 2023-10-11 21:49:00 +0000 | <Inst> | iirc list comprehensions desugar to concatmap |
| 2023-10-11 21:49:18 +0000 | <geekosaur> | they only do if MonadComprehensions is in effect, I think |
| 2023-10-11 21:51:12 +0000 | ChanServ | +o litharge |
| 2023-10-11 21:51:13 +0000 | litharge | -bo *!*@190.123.41.211 litharge |
| 2023-10-11 21:52:17 +0000 | <monochrom> | I think there are two points. 1. List comprehension and filter go through different pathways in GHC. 2. But end up being the same asm code. |
| 2023-10-11 21:52:19 +0000 | <geekosaur> | yeh, 0-ddump-ds shows no use of concatMap |
| 2023-10-11 21:56:46 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-10-11 21:57:19 +0000 | privacy | (~privacy@user/privacy) (Quit: Leaving) |
| 2023-10-11 22:01:50 +0000 | leah2 | (~leah@vuxu.org) (Ping timeout: 255 seconds) |
| 2023-10-11 22:10:16 +0000 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-10-11 22:14:03 +0000 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-10-11 22:14:47 +0000 | leah2 | (~leah@vuxu.org) |
| 2023-10-11 22:20:35 +0000 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) (Ping timeout: 240 seconds) |
| 2023-10-11 22:22:39 +0000 | AlexZenon | (~alzenon@94.233.241.173) (Ping timeout: 240 seconds) |
| 2023-10-11 22:23:33 +0000 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) |
| 2023-10-11 22:23:33 +0000 | ChanServ | +v haskellbridge |
| 2023-10-11 22:23:34 +0000 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) (Remote host closed the connection) |
| 2023-10-11 22:23:55 +0000 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) |
| 2023-10-11 22:23:55 +0000 | ChanServ | +v haskellbridge |
| 2023-10-11 22:29:06 +0000 | patrl | (~patrl@user/patrl) (Remote host closed the connection) |
| 2023-10-11 22:29:14 +0000 | AlexZenon | (~alzenon@94.233.241.173) |
| 2023-10-11 22:29:24 +0000 | patrl | (~patrl@user/patrl) |
| 2023-10-11 22:31:48 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-10-11 22:32:11 +0000 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-11 22:35:11 +0000 | harveypwca | (~harveypwc@2601:246:c280:6a90:837d:db39:3eea:f7db) |
| 2023-10-11 22:37:31 +0000 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 264 seconds) |
| 2023-10-11 22:37:57 +0000 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-10-11 22:41:14 +0000 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer) |
| 2023-10-11 22:41:27 +0000 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-10-11 22:44:26 +0000 | Square | (~Square@user/square) |
| 2023-10-11 22:44:28 +0000 | <Inst> | ls |
| 2023-10-11 22:44:38 +0000 | <geekosaur> | . |
| 2023-10-11 22:44:48 +0000 | <davean> | .. |
| 2023-10-11 22:44:51 +0000 | patrl | (~patrl@user/patrl) (Remote host closed the connection) |
| 2023-10-11 22:45:01 +0000 | <Inst> | typo, but this is now a dumb instinct i have whenever i find a text prompt |
| 2023-10-11 22:45:05 +0000 | patrl | (~patrl@user/patrl) |
| 2023-10-11 22:45:07 +0000 | <EvanR> | after converting everything to lazy bytestring I went from 0.044ms to 0.083ms. Strict bytestring (in which case hGetContents just loads everything immediately), 0.034ms |
| 2023-10-11 22:45:24 +0000 | <EvanR> | strictness for the win |
| 2023-10-11 22:46:04 +0000 | <davean> | uh, you're likely missattributing that. lazy bytestrings are a different datastructure with different computational efficiencies |
| 2023-10-11 22:46:28 +0000 | <EvanR> | yes not strictness, but strict bytestringness |
| 2023-10-11 22:46:56 +0000 | <davean> | yah, lazy bytestring is a rather inefficient structure for what you get! |
| 2023-10-11 22:47:19 +0000 | <EvanR> | I just realized the incongruous names of the two bytestrings |
| 2023-10-11 22:47:30 +0000 | <EvanR> | strict vs eager, non-strict vs lazy |
| 2023-10-11 22:48:23 +0000 | <c_wraith> | both terms *are* accurate |
| 2023-10-11 22:48:28 +0000 | <monochrom> | We need to talk about Data.Map.Eager and Data.Map.Nonstrict. >:) |
| 2023-10-11 22:48:37 +0000 | <c_wraith> | they're just not exactly a matched pair |
| 2023-10-11 22:49:07 +0000 | <monochrom> | Data.Map.Do.It.Now |
| 2023-10-11 22:49:10 +0000 | Guest48 | (~Guest2@85-147-192-197.cable.dynamic.v4.ziggo.nl) |
| 2023-10-11 22:49:12 +0000 | <c_wraith> | though I suppose Haskell as a language never guarantees laziness. that's up to GHC. |
| 2023-10-11 22:49:25 +0000 | <c_wraith> | Haskell only guarantees non-strict properties. |
| 2023-10-11 22:49:29 +0000 | Guest48 | (~Guest2@85-147-192-197.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2023-10-11 22:49:52 +0000 | <EvanR> | must keep GHC well fed or it will become angry and turn all our lists strict and our bytestrings lazy |
| 2023-10-11 22:49:55 +0000 | <monochrom> | Haha we just went through how little any standard doc guarantees anything at all a couple of hours ago. |
| 2023-10-11 22:50:17 +0000 | <dolio> | It can't turn them strict, at least. |
| 2023-10-11 22:50:25 +0000 | <monochrom> | I bet you no standard doc even guarantees that evaluating 1+1 even takes constant time or space. |
| 2023-10-11 22:50:29 +0000 | <c_wraith> | the whole "unevaluated expressions are represented by thunks that memoize results after calculation" is a specific implementation choice. |
| 2023-10-11 22:50:57 +0000 | <monochrom> | Yeah this is why I don't use the word "thunk" even when teaching lazy evaluation. |
| 2023-10-11 22:51:12 +0000 | <monochrom> | "partly unevaluated expression" is just fine. |
| 2023-10-11 22:51:21 +0000 | <c_wraith> | not even if you hit someone over the head for not paying attention? |
| 2023-10-11 22:51:54 +0000 | <EvanR> | I still am kind of boggling that lazy bytestring is performing twice as slow as list of Char |
| 2023-10-11 22:51:59 +0000 | <c_wraith> | I may be misremembering how college courses go. |
| 2023-10-11 22:52:30 +0000 | <c_wraith> | EvanR: When you're seeing that result, there's a good chance list fusion played a part |
| 2023-10-11 22:52:33 +0000 | <monochrom> | Oh my students don't pay attention during class. That's fine. They will after class, reviewing lecture slides and doing homework. |
| 2023-10-11 22:52:55 +0000 | <EvanR> | list (+ fusion) for the win |
| 2023-10-11 22:53:10 +0000 | <geekosaur> | EvanR, you're talking times that are short enough that I could imagine the extra indirection on all lazy ByteStrings being relevant |
| 2023-10-11 22:53:13 +0000 | <monochrom> | Lazy bytestring is supposed to enjoy fusion too. |
| 2023-10-11 22:53:24 +0000 | <monochrom> | Ah. That. |
| 2023-10-11 22:53:30 +0000 | <c_wraith> | geekosaur: there's no way lazy bytestring has *more* indirection than String |
| 2023-10-11 22:53:57 +0000 | <geekosaur> | no, but I expect String fuses in more cases |
| 2023-10-11 22:53:58 +0000 | <monochrom> | Time to look at Core, even Cmm? |
| 2023-10-11 22:54:00 +0000 | <c_wraith> | ... if the String is ever materialized |
| 2023-10-11 22:54:10 +0000 | <c_wraith> | yeah, fusion again |
| 2023-10-11 22:55:48 +0000 | <dolio> | bytestring doesn't actually hasn't had fusion for a long time, if it ever did. |
| 2023-10-11 22:56:05 +0000 | geekosaur | fails to parse |
| 2023-10-11 22:56:06 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2023-10-11 22:56:11 +0000 | <EvanR> | my brain just exploded |
| 2023-10-11 22:56:12 +0000 | <dolio> | Yeah, I edited that poorly. |
| 2023-10-11 22:56:20 +0000 | <dolio> | It doesn't have fusion. |
| 2023-10-11 22:56:48 +0000 | <EvanR> | so (strict, at least) bytestring is more what you see is what you get |
| 2023-10-11 22:56:57 +0000 | <dolio> | I don't know if it was all ripped out, or if it never got added. |
| 2023-10-11 22:57:22 +0000 | <monochrom> | :( |
| 2023-10-11 22:58:07 +0000 | <EvanR> | I guess I should try Text for completeness |
| 2023-10-11 23:00:51 +0000 | <dolio> | I definitely remember talk about it when it first debuted. |
| 2023-10-11 23:02:29 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-11 23:03:29 +0000 | <EvanR> | (strict) Text gets the same exact time as strict bytestring |
| 2023-10-11 23:03:52 +0000 | <EvanR> | text-2.0 which is utf8 right |
| 2023-10-11 23:03:57 +0000 | <geekosaur> | yes |
| 2023-10-11 23:05:16 +0000 | td_ | (~td@2001:9e8:19f7:c900:55c4:edef:d459:6ff7) (Ping timeout: 248 seconds) |
| 2023-10-11 23:05:17 +0000 | <EvanR> | so it's probably more or less identical algorithms to my Bytestring.Char8 code |
| 2023-10-11 23:05:24 +0000 | <EvanR> | on ascii |
| 2023-10-11 23:07:25 +0000 | <EvanR> | except Text is apparently implemented with a ByteArray# and ByteString is a foreign pointer |
| 2023-10-11 23:07:31 +0000 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 264 seconds) |
| 2023-10-11 23:08:58 +0000 | <EvanR> | it must be that my minimum time just doesn't have anything to do with the data structure anymore |
| 2023-10-11 23:13:11 +0000 | <solrize> | https://gitlab.haskell.org/ghc/ghc/-/wikis/linear-types i just found out that this got merged into ghc a while back i hadn't been paying tattention. i'm wondering if there could be some way to have linear values with i/o actions inside, so you can consume the value inside a pure function and have the action happen, sort of how i/o in Clean worked |
| 2023-10-11 23:14:19 +0000 | harveypwca_ | (~harveypwc@2601:246:c280:6a90:837d:db39:3eea:f7db) |
| 2023-10-11 23:15:49 +0000 | Square3 | (~Square4@user/square) |
| 2023-10-11 23:15:55 +0000 | ph88 | (~ph88@ip5b406c07.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2023-10-11 23:17:03 +0000 | harveypwca | (~harveypwc@2601:246:c280:6a90:837d:db39:3eea:f7db) (Ping timeout: 240 seconds) |
| 2023-10-11 23:17:31 +0000 | <solrize> | the IO monad is kind of a hack to get around the former absence of linear types in haskell, right? It's State RealWorld a |
| 2023-10-11 23:18:06 +0000 | kantokuen | (~kantokuen@user/kantokuen) (Read error: Connection reset by peer) |
| 2023-10-11 23:18:15 +0000 | Square | (~Square@user/square) (Ping timeout: 240 seconds) |
| 2023-10-11 23:19:24 +0000 | EvanR | (~EvanR@user/evanr) (Ping timeout: 240 seconds) |
| 2023-10-11 23:20:16 +0000 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2023-10-11 23:20:17 +0000 | apache2 | (apache2@anubis.0x90.dk) (Remote host closed the connection) |
| 2023-10-11 23:20:26 +0000 | apache2 | (apache2@anubis.0x90.dk) |
| 2023-10-11 23:21:16 +0000 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-10-11 23:21:22 +0000 | Square3 | (~Square4@user/square) (Remote host closed the connection) |
| 2023-10-11 23:21:33 +0000 | <solrize> | https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/linear_types.html sorry meant this, it is a little different from the wiki page but i'll read the wiki page now |
| 2023-10-11 23:22:14 +0000 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-10-11 23:24:21 +0000 | EvanR | (~EvanR@user/evanr) |
| 2023-10-11 23:25:31 +0000 | <geekosaur> | you can want sequencing without linearity, so I'd say no unless the linearity is specific to the "RealWorld" token. and even then I think that prevents e.g. forkIO |
| 2023-10-11 23:25:49 +0000 | kantokuen | (~kantokuen@user/kantokuen) |
| 2023-10-11 23:26:02 +0000 | <EvanR> | how did/does Clean work? |
| 2023-10-11 23:26:56 +0000 | td_ | (~td@83.135.9.0) |
| 2023-10-11 23:27:41 +0000 | <solrize> | geekosaur, yeah RealWorld is sort of a fiction in the face of concurrency. Clean had something called uniqueness types which were sort of like linear types |
| 2023-10-11 23:27:49 +0000 | <solrize> | and used them for effects |
| 2023-10-11 23:28:00 +0000 | <dolio> | It doesn't make any actual semantic sense. |
| 2023-10-11 23:28:00 +0000 | <solrize> | https://en.wikipedia.org/wiki/Clean_(programming_language) |
| 2023-10-11 23:28:24 +0000 | <solrize> | yeah there is a paper "tackling the awkward squad" which dishes the dirt |
| 2023-10-11 23:28:47 +0000 | <solrize> | https://www.microsoft.com/en-us/research/publication/tackling-awkward-squad-monadic-inputoutput-co… |
| 2023-10-11 23:29:07 +0000 | ph88 | (~ph88@2a01:598:b034:e155:39dc:f437:99ae:bc1f) |
| 2023-10-11 23:33:08 +0000 | <EvanR> | IO could easily be an abstract data type of primitive actions string together with a >>= operation |
| 2023-10-11 23:33:16 +0000 | <EvanR> | strung together* |
| 2023-10-11 23:33:40 +0000 | <EvanR> | uniqueness or linear types must be for something else |
| 2023-10-11 23:41:23 +0000 | <Inst> | why does Snoyman use so much template Haskell? |
| 2023-10-11 23:41:34 +0000 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 255 seconds) |
| 2023-10-11 23:41:40 +0000 | <monochrom> | Wouldn't you ask Snoyman? :) |
| 2023-10-11 23:41:46 +0000 | <geekosaur> | like I said, sequencing. linear types would prevent "forking" a series of I/O actions that could run concurrently with other actions; monads provide a mechanism for direct sequencing |
| 2023-10-11 23:42:00 +0000 | <Inst> | Well, he's busy |
| 2023-10-11 23:42:34 +0000 | <Inst> | to a large extent a lot of stuff in Haskell seems to be code archaeology |
| 2023-10-11 23:42:36 +0000 | <geekosaur> | that doesn't mean other people know |
| 2023-10-11 23:42:52 +0000 | myxokephale | (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 2023-10-11 23:43:00 +0000 | <Inst> | as in, there's code that represents ancient notions of what was good practice at the time |
| 2023-10-11 23:43:16 +0000 | myxokephale | (~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit) |
| 2023-10-11 23:43:20 +0000 | kantokuen | (~kantokuen@user/kantokuen) (Quit: brb) |
| 2023-10-11 23:43:34 +0000 | <monochrom> | I don't understand why a lot of stuff in Haskell is code archaeology. What I see is you are doing code archaeology. |
| 2023-10-11 23:44:48 +0000 | Square | (~Square4@user/square) |
| 2023-10-11 23:45:28 +0000 | <Inst> | yeah, i guess |
| 2023-10-11 23:45:57 +0000 | <Inst> | for the exact same niche as yesod, i should be looking at IHP for something recent |
| 2023-10-11 23:46:17 +0000 | <Inst> | then i don't get a right to complain about 20 year old libraries |
| 2023-10-11 23:46:40 +0000 | <geekosaur> | sometimes things are used just because they work. Servant is a good example |
| 2023-10-11 23:46:43 +0000 | <monochrom> | At the beginning, someone suggested you to look at existing code so as to accelerate you writing your own production code. But as it turns out, you turn that into its own rabbit hole for its own sake so as to prevent you from writing any code at all. |
| 2023-10-11 23:46:46 +0000 | <geekosaur> | or scotty or spock |
| 2023-10-11 23:47:13 +0000 | kantokuen | (~kantokuen@user/kantokuen) |
| 2023-10-11 23:47:32 +0000 | hgolden_ | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Quit: Leaving) |
| 2023-10-11 23:47:44 +0000 | <geekosaur> | but I'm not saying look at their code, I'm saying make use of them |
| 2023-10-11 23:49:53 +0000 | <Inst> | you must be mistaken, I'm looking at Cabal to figure out how to write an exact parser |
| 2023-10-11 23:49:58 +0000 | <monochrom> | Anyway, back to IO and linearity. |
| 2023-10-11 23:50:07 +0000 | <Inst> | Yesod is more me getting bored and trying to take a break to do an easy project |
| 2023-10-11 23:50:21 +0000 | EvanR | (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 2023-10-11 23:51:24 +0000 | <monochrom> | If you use the World->(a,World) model for IO and/or ST, you can notice that the World is used linearly (or stronger) (if you ignore concurrency and unsafePerformIO). This is where linear types and uniqueness types can come in. |
| 2023-10-11 23:51:54 +0000 | EvanR | (~EvanR@user/evanr) |
| 2023-10-11 23:52:09 +0000 | <monochrom> | In fact, Wadler wrote a "linear types can change the world!" paper that suggests linear types instead of monads for ST. (The rest is history.) |
| 2023-10-11 23:52:58 +0000 | <monochrom> | Thing is, Wadler wrote both "monads for mutable states" and "linearity for mutable states" so he was successful, one of his proposals was adopted. :) |
| 2023-10-11 23:54:56 +0000 | <solrize> | lol |
| 2023-10-11 23:54:57 +0000 | myxokephale | (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 2023-10-11 23:55:02 +0000 | <monochrom> | Concurrency should be the best reason why linearity will run into a roadblock for the pupose of IO. But I am depraved, my first instinct was "but it conflicts with unsafePerformIO". Am I evil? |
| 2023-10-11 23:55:06 +0000 | Square | (~Square4@user/square) (Quit: Leaving) |
| 2023-10-11 23:55:40 +0000 | <dolio> | It doesn't work for infinite processes, either. |
| 2023-10-11 23:56:06 +0000 | <EvanR> | obviously linear types only works for single threaded code, it's linear. To express concurrency you need non-linear types |
| 2023-10-11 23:56:14 +0000 | <EvanR> | multilinear |
| 2023-10-11 23:56:28 +0000 | <dolio> | How is `forever (putStrLn "Hello")` different from `forever (return ())`? |
| 2023-10-11 23:56:42 +0000 | <solrize> | World->(a,World) is also single threaded |
| 2023-10-11 23:56:56 +0000 | <EvanR> | I was joking |
| 2023-10-11 23:57:11 +0000 | <EvanR> | but World -> (a, World) explains what I was wondering |
| 2023-10-11 23:57:20 +0000 | <EvanR> | answers my question |
| 2023-10-11 23:57:25 +0000 | <monochrom> | :) |
| 2023-10-11 23:58:13 +0000 | <dolio> | If you try to use State, then those both look like `const undefined`. |
| 2023-10-11 23:59:06 +0000 | <dolio> | Which of course doesn't even look linear, but the terms you wrote do. |
| 2023-10-11 23:59:57 +0000 | <EvanR> | ghci really doesn't like forever (return ()) |
