| 2025-03-21 00:00:11 +0100 | abiss27 | (~abiss27@190.213.236.106) |
| 2025-03-21 00:01:17 +0100 | abiss27 | (~abiss27@190.213.236.106) (Changing host) |
| 2025-03-21 00:01:17 +0100 | abiss27 | (~abiss27@user/abiss) abiss |
| 2025-03-21 00:02:02 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-03-21 00:03:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-21 00:03:29 +0100 | <monochrom> | hehe |
| 2025-03-21 00:03:56 +0100 | <monochrom> | "infer the type of id id id id id id id id id id id id" |
| 2025-03-21 00:04:02 +0100 | <monochrom> | @quote monochrom 17-ary |
| 2025-03-21 00:04:02 +0100 | <lambdabot> | monochrom says: I am 17-ary, going on 18-ary, I can take curry of you |
| 2025-03-21 00:04:43 +0100 | Buliarou1 | (~gypsydang@46.232.210.139) (Remote host closed the connection) |
| 2025-03-21 00:05:44 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-03-21 00:06:33 +0100 | yin | (~z@user/zero) zero |
| 2025-03-21 00:09:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 00:10:58 +0100 | abiss27 | (~abiss27@user/abiss) () |
| 2025-03-21 00:11:32 +0100 | abiss27 | (~abiss27@190.213.236.106) |
| 2025-03-21 00:12:11 +0100 | xff0x | (~xff0x@2405:6580:b080:900:810c:5794:3404:58c8) (Ping timeout: 265 seconds) |
| 2025-03-21 00:12:28 +0100 | abiss27 | (~abiss27@190.213.236.106) (Client Quit) |
| 2025-03-21 00:14:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-03-21 00:20:49 +0100 | abiss27 | (~abiss27@user/abiss) abiss |
| 2025-03-21 00:25:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 00:26:02 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 268 seconds) |
| 2025-03-21 00:26:05 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 00:28:45 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-03-21 00:30:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 00:30:23 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-21 00:41:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 00:45:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-21 00:52:53 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2025-03-21 00:56:56 +0100 | kh0d | (~kh0d@212.200.247.167) (Remote host closed the connection) |
| 2025-03-21 00:56:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 00:57:51 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 00:59:35 +0100 | xff0x | (~xff0x@2405:6580:b080:900:d229:f63b:2d49:ccd3) |
| 2025-03-21 01:01:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 01:02:36 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 252 seconds) |
| 2025-03-21 01:04:08 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 01:11:21 +0100 | abiss27 | (~abiss27@user/abiss) (Quit: I'm off, Goodbye!) |
| 2025-03-21 01:11:49 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 01:12:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 01:14:52 +0100 | abiss27 | (~abiss27@190.213.236.106) |
| 2025-03-21 01:15:59 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 265 seconds) |
| 2025-03-21 01:16:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 01:17:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 01:19:04 +0100 | xff0x | (~xff0x@2405:6580:b080:900:d229:f63b:2d49:ccd3) (Ping timeout: 260 seconds) |
| 2025-03-21 01:20:58 +0100 | xff0x | (~xff0x@2405:6580:b080:900:b993:7de8:b31e:5325) |
| 2025-03-21 01:22:05 +0100 | abiss27 | (~abiss27@190.213.236.106) (Changing host) |
| 2025-03-21 01:22:05 +0100 | abiss27 | (~abiss27@user/abiss) abiss |
| 2025-03-21 01:23:12 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-21 01:24:03 +0100 | abiss27 | (~abiss27@user/abiss) (Quit: I'm off, Goodbye!) |
| 2025-03-21 01:24:42 +0100 | abiss27 | (~abiss27@190.213.236.106) |
| 2025-03-21 01:26:06 +0100 | abiss27 | (~abiss27@190.213.236.106) (Client Quit) |
| 2025-03-21 01:28:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 01:28:41 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-21 01:28:59 +0100 | kh0d | (~kh0d@212.200.247.167) |
| 2025-03-21 01:30:27 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) (Client Quit) |
| 2025-03-21 01:30:45 +0100 | tabaqui | (~tabaqui@167.71.80.236) (Ping timeout: 252 seconds) |
| 2025-03-21 01:31:18 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-21 01:35:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 01:35:34 +0100 | sprotte24 | (~sprotte24@p200300d16f3eed00f17f1149f1ad7273.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-03-21 01:36:34 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 260 seconds) |
| 2025-03-21 01:38:07 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:99ef:5e1b:cda4:8b3) (Read error: Connection reset by peer) |
| 2025-03-21 01:39:50 +0100 | Square | (~Square@user/square) Square |
| 2025-03-21 01:40:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 01:41:53 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f9399301ab9560bdae8.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-03-21 01:43:24 +0100 | xff0x | (~xff0x@2405:6580:b080:900:b993:7de8:b31e:5325) (Ping timeout: 260 seconds) |
| 2025-03-21 01:43:56 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3522:3957:cbed:8aef) |
| 2025-03-21 01:45:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-21 01:48:18 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f9399301ab9560bdae8.dip0.t-ipconnect.de) acidjnk |
| 2025-03-21 01:50:18 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 01:51:46 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) justsomeguy |
| 2025-03-21 01:53:35 +0100 | euleritian | (~euleritia@95.90.214.149) (Remote host closed the connection) |
| 2025-03-21 01:54:03 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 01:54:19 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2025-03-21 01:55:00 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 01:56:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 01:57:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 01:57:44 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-0ae4-b88c-ff83-9891-e272.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-03-21 01:58:02 +0100 | Googulator88 | (~Googulato@80-95-93-233.pool.digikabel.hu) |
| 2025-03-21 01:59:33 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 245 seconds) |
| 2025-03-21 02:01:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 02:02:14 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 02:12:10 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-21 02:12:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 02:13:18 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3522:3957:cbed:8aef) (Ping timeout: 245 seconds) |
| 2025-03-21 02:13:37 +0100 | Digit | (~user@user/digit) Digit |
| 2025-03-21 02:13:58 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 02:16:51 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 02:17:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-21 02:22:44 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-03-21 02:24:05 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f9399301ab9560bdae8.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-03-21 02:28:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 02:32:41 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2025-03-21 02:32:56 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 02:33:29 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2025-03-21 02:34:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-03-21 02:34:20 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 02:38:22 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 244 seconds) |
| 2025-03-21 02:39:03 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2025-03-21 02:39:23 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 02:42:37 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 02:44:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 02:45:10 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-03-21 02:46:51 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-21 02:47:53 +0100 | Square | (~Square@user/square) (Ping timeout: 245 seconds) |
| 2025-03-21 02:48:29 +0100 | tusko | (uid478376@user/tusko) () |
| 2025-03-21 02:49:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 02:55:25 +0100 | mvk | (~mvk@2607:fea8:5c96:5800::7ea9) mvk |
| 2025-03-21 02:55:25 +0100 | mvk | (~mvk@2607:fea8:5c96:5800::7ea9) (Client Quit) |
| 2025-03-21 02:58:56 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 02:59:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 03:03:36 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 252 seconds) |
| 2025-03-21 03:04:32 +0100 | user363627 | (~user@user/user363627) user363627 |
| 2025-03-21 03:04:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 03:07:20 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-03-21 03:08:20 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-21 03:08:36 +0100 | weary-traveler | (~user@user/user363627) (Ping timeout: 265 seconds) |
| 2025-03-21 03:12:41 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Ping timeout: 244 seconds) |
| 2025-03-21 03:15:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 03:19:30 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-03-21 03:22:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 03:28:01 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 03:32:09 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-21 03:33:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 03:34:57 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 03:38:07 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-21 03:38:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-21 03:40:12 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 246 seconds) |
| 2025-03-21 03:41:49 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 03:44:55 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-21 03:48:00 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 03:49:03 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-21 03:49:26 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-21 03:49:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 03:50:24 +0100 | tromp | (~textual@2a02:a210:cba:8500:f085:be23:3f4e:4a7a) (Ping timeout: 244 seconds) |
| 2025-03-21 03:54:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 03:59:23 +0100 | Guest9 | (~Guest9@2600:4040:52fa:9700:fd29:3b63:e979:8aca) |
| 2025-03-21 03:59:52 +0100 | Guest9 | (~Guest9@2600:4040:52fa:9700:fd29:3b63:e979:8aca) (Client Quit) |
| 2025-03-21 04:01:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 04:06:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 04:09:29 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 04:10:16 +0100 | kh0d | (~kh0d@212.200.247.167) kh0d |
| 2025-03-21 04:13:25 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 04:15:23 +0100 | kh0d | (~kh0d@212.200.247.167) (Ping timeout: 245 seconds) |
| 2025-03-21 04:16:37 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-03-21 04:17:13 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-03-21 04:17:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 04:17:40 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 04:18:45 +0100 | sudden | (~cat@user/sudden) (Ping timeout: 248 seconds) |
| 2025-03-21 04:19:49 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) (Ping timeout: 248 seconds) |
| 2025-03-21 04:20:26 +0100 | sudden | (~cat@user/sudden) sudden |
| 2025-03-21 04:20:31 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) |
| 2025-03-21 04:22:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 04:27:44 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 04:33:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 04:33:19 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 260 seconds) |
| 2025-03-21 04:36:57 +0100 | user363627 | weary-traveler |
| 2025-03-21 04:37:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 04:47:41 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 04:48:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 04:53:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 04:55:23 +0100 | Xe | (~Xe@perl/impostor/xe) (Ping timeout: 245 seconds) |
| 2025-03-21 04:57:04 +0100 | Xe | (~Xe@perl/impostor/xe) Xe |
| 2025-03-21 04:58:49 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 05:03:02 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-21 05:04:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 05:08:09 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2025-03-21 05:08:15 +0100 | Fijxu | (~Fijxu@user/fijxu) (Quit: XD!!) |
| 2025-03-21 05:11:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 05:12:17 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2025-03-21 05:15:17 +0100 | azh_ming | (~aaron@pool-108-48-188-212.washdc.fios.verizon.net) |
| 2025-03-21 05:17:28 +0100 | aazh_anon_ming | (~aazh_anon@pool-108-48-188-212.washdc.fios.verizon.net) |
| 2025-03-21 05:18:46 +0100 | azh_ming | (~aaron@pool-108-48-188-212.washdc.fios.verizon.net) (Quit: leaving) |
| 2025-03-21 05:19:12 +0100 | aazh_anon_ming | (~aazh_anon@pool-108-48-188-212.washdc.fios.verizon.net) (Remote host closed the connection) |
| 2025-03-21 05:19:22 +0100 | azh_ming | (~azh_ming@pool-108-48-188-212.washdc.fios.verizon.net) |
| 2025-03-21 05:20:25 +0100 | <azh_ming> | @pl \f g x y -> f (x ++ g x) (g y) |
| 2025-03-21 05:20:25 +0100 | <lambdabot> | join . ((flip . ((.) .)) .) . (. ap (++)) . (.) |
| 2025-03-21 05:21:44 +0100 | Square | (~Square@user/square) Square |
| 2025-03-21 05:22:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 05:24:06 +0100 | azh_ming | (~azh_ming@pool-108-48-188-212.washdc.fios.verizon.net) (Changing host) |
| 2025-03-21 05:24:06 +0100 | azh_ming | (~azh_ming@user/azh-ming:58353) azh_ming |
| 2025-03-21 05:25:04 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-03-21 05:27:21 +0100 | <haskellbridge> | <Bowuigi> Peak Haskell |
| 2025-03-21 05:27:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-21 05:28:22 +0100 | azh_ming | (~azh_ming@user/azh-ming:58353) (Remote host closed the connection) |
| 2025-03-21 05:28:46 +0100 | azh_ming | (~azh_ming@user/azh-ming:58353) azh_ming |
| 2025-03-21 05:28:48 +0100 | azh_ming | (~azh_ming@user/azh-ming:58353) (Remote host closed the connection) |
| 2025-03-21 05:29:58 +0100 | azh_ming | (~aaron@user/azh-ming:58353) azh_ming |
| 2025-03-21 05:30:45 +0100 | <azh_ming> | /join #politics |
| 2025-03-21 05:30:51 +0100 | azh_ming | (~aaron@user/azh-ming:58353) (Client Quit) |
| 2025-03-21 05:34:57 +0100 | azh_ming | (~aaron@user/azh-ming:58353) azh_ming |
| 2025-03-21 05:38:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 05:43:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 05:44:13 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 05:48:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-21 05:54:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 05:56:46 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 244 seconds) |
| 2025-03-21 05:57:24 +0100 | azh_ming | (~aaron@user/azh-ming:58353) (Quit: leaving) |
| 2025-03-21 05:58:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 06:01:12 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-03-21 06:02:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 06:07:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 06:10:25 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-03-21 06:11:06 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2025-03-21 06:11:43 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-03-21 06:11:46 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 06:13:18 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 244 seconds) |
| 2025-03-21 06:14:53 +0100 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-03-21 06:15:06 +0100 | Square | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2025-03-21 06:15:39 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-03-21 06:15:57 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.5.2) |
| 2025-03-21 06:16:24 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 244 seconds) |
| 2025-03-21 06:18:04 +0100 | shr\ke_ | (~shrike@user/paxhumana) paxhumana |
| 2025-03-21 06:18:18 +0100 | shr\ke | (~shrike@user/shrke:31298) (Ping timeout: 252 seconds) |
| 2025-03-21 06:18:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 06:18:21 +0100 | shr\ke_ | shr\ke |
| 2025-03-21 06:23:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-21 06:26:17 +0100 | michalz | (~michalz@185.246.207.193) |
| 2025-03-21 06:27:25 +0100 | arahael | (~arahael@user/arahael) arahael |
| 2025-03-21 06:29:17 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 06:29:47 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-21 06:31:12 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-03-21 06:33:42 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 06:34:04 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-21 06:34:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 06:35:13 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-03-21 06:39:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 06:45:29 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 06:49:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 06:50:13 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 248 seconds) |
| 2025-03-21 06:50:52 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-03-21 06:54:25 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-03-21 06:56:00 +0100 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2025-03-21 06:56:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 06:58:22 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-03-21 07:00:20 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-03-21 07:03:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 07:08:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-21 07:09:33 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-03-21 07:15:21 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 07:18:04 +0100 | kh0d | (~kh0d@212.200.65.86) |
| 2025-03-21 07:19:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 07:19:26 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-21 07:24:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 07:24:46 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 265 seconds) |
| 2025-03-21 07:35:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 07:40:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 07:43:10 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-21 07:43:25 +0100 | <Inst> | curious, do you need to use IORef (or relatives) to cache top-level data? |
| 2025-03-21 07:43:47 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f937555fc5a67c80b19.dip0.t-ipconnect.de) acidjnk |
| 2025-03-21 07:44:00 +0100 | <Inst> | Let's say, I'm using a web framework. I define a webpage under Lucid, Lucid2, or Blaze on the top-level. |
| 2025-03-21 07:45:14 +0100 | <Inst> | Every time the page is served, is the top-level definition re-evaluated? Or would it be more efficient to freeze it with IORef, then pass the IORef to the route handler as an argument, with the route handler being in MonadIO? |
| 2025-03-21 07:47:24 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-21 07:48:29 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:19d8:9179:8622:bdf3) (Read error: Connection reset by peer) |
| 2025-03-21 07:49:29 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:19d8:9179:8622:bdf3) synchromesh |
| 2025-03-21 07:49:50 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-21 07:50:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 07:52:00 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-21 07:54:35 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-21 07:55:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-21 07:56:55 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 07:58:41 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 08:00:01 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-21 08:00:46 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 08:00:56 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-21 08:02:02 +0100 | <Axman6> | top level values are generally only evaluated once, just like all named things in Haskell. There are caveats to that though, if it's a function I can't remember what happens |
| 2025-03-21 08:02:19 +0100 | <Axman6> | if it has a generic type, it might also not be cached |
| 2025-03-21 08:02:53 +0100 | kh0d | (~kh0d@212.200.65.86) (Ping timeout: 245 seconds) |
| 2025-03-21 08:03:09 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Client Quit) |
| 2025-03-21 08:04:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 08:04:47 +0100 | <haskellbridge> | <Liamzee> thanks, couldn't find an answer on Google |
| 2025-03-21 08:04:58 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-21 08:05:17 +0100 | <Axman6> | I think CAF, constant applicative form, is a useful thing to search for, but my memory's rusty |
| 2025-03-21 08:06:13 +0100 | <haskellbridge> | <Liamzee> thanks, but the term has confusion with the typeclass |
| 2025-03-21 08:07:27 +0100 | <haskellbridge> | <Liamzee> With Lucid I suspect it might be better to burn the HTML down to a bytestring first |
| 2025-03-21 08:07:38 +0100 | <haskellbridge> | <Liamzee> since it's a builder function |
| 2025-03-21 08:07:51 +0100 | <haskellbridge> | <Liamzee> that's also a monad transformer |
| 2025-03-21 08:08:27 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 08:08:43 +0100 | ft | (~ft@p508db463.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-03-21 08:09:04 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 08:09:48 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Quit: wildsalander) |
| 2025-03-21 08:11:07 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-03-21 08:11:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-21 08:13:27 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 08:13:56 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-03-21 08:14:00 +0100 | euleritian | (~euleritia@95.90.214.149) |
| 2025-03-21 08:14:33 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds) |
| 2025-03-21 08:14:47 +0100 | <[exa]> | Liamzee: what's the type of your toplevel definition btw? that usually determines whether it's gonna get cached or not. |
| 2025-03-21 08:15:20 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-03-21 08:18:21 +0100 | kh0d | (~kh0d@109.111.226.14) |
| 2025-03-21 08:22:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 08:23:15 +0100 | kh0d | (~kh0d@109.111.226.14) (Ping timeout: 252 seconds) |
| 2025-03-21 08:26:00 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 08:28:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-21 08:29:59 +0100 | euleritian | (~euleritia@95.90.214.149) (Ping timeout: 260 seconds) |
| 2025-03-21 08:30:20 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) (Read error: Connection reset by peer) |
| 2025-03-21 08:30:25 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 08:31:59 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 08:32:17 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-03-21 08:33:15 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) |
| 2025-03-21 08:37:36 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Ping timeout: 272 seconds) |
| 2025-03-21 08:37:51 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-21 08:38:08 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) (Ping timeout: 268 seconds) |
| 2025-03-21 08:38:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 08:38:59 +0100 | dsrt^ | (~dsrt@c-71-199-187-173.hsd1.ga.comcast.net) |
| 2025-03-21 08:43:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 08:43:44 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-03-21 08:44:26 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-03-21 08:45:47 +0100 | kh0d | (~kh0d@109.111.226.14) kh0d |
| 2025-03-21 08:46:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 08:50:18 +0100 | kh0d | (~kh0d@109.111.226.14) (Ping timeout: 246 seconds) |
| 2025-03-21 08:50:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-21 08:52:40 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-21 08:53:42 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-21 08:53:42 +0100 | ljdarj1 | ljdarj |
| 2025-03-21 08:54:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 08:59:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-03-21 09:05:29 +0100 | kh0d | (~kh0d@109.111.226.14) kh0d |
| 2025-03-21 09:05:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 09:05:42 +0100 | Googulator88 | (~Googulato@80-95-93-233.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-03-21 09:06:44 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-03-21 09:10:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 09:11:26 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2025-03-21 09:12:22 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 09:15:59 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2025-03-21 09:19:01 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-03-21 09:21:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 09:25:34 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Remote host closed the connection) |
| 2025-03-21 09:25:34 +0100 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-03-21 09:30:23 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard |
| 2025-03-21 09:31:35 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 09:32:52 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-21 09:35:55 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 09:44:52 +0100 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-03-21 09:47:35 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 09:48:42 +0100 | <haskellbridge> | <Liamzee> Html () :( |
| 2025-03-21 09:49:04 +0100 | <haskellbridge> | <Liamzee> so burn to bytestring, it'll get cached, but as a builder, which is afaik just a function pointer |
| 2025-03-21 09:49:40 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-03-21 09:53:19 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 09:58:27 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-21 09:58:58 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-21 10:01:50 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-03-21 10:06:01 +0100 | krei-se- | (~krei-se@p5dea1e73.dip0.t-ipconnect.de) krei-se |
| 2025-03-21 10:06:25 +0100 | krei-se | (~krei-se@p3ee0faf4.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-03-21 10:08:34 +0100 | <[exa]> | Liamzee: yap that's a builder, not cacheable |
| 2025-03-21 10:09:55 +0100 | <[exa]> | but you can cache the prebuild piece (let it evaluate to something with runHtml or so?) and then just shove it into the other html builders? |
| 2025-03-21 10:11:54 +0100 | <[exa]> | basically having the global value as this should do it: memoized = toLazyByteString ...someglue... runHtmlT $ mypage |
| 2025-03-21 10:12:30 +0100 | forell | (~forell@user/forell) forell |
| 2025-03-21 10:12:39 +0100 | <[exa]> | `someglue` should be solvable by following a typehole |
| 2025-03-21 10:15:22 +0100 | dhil | (~dhil@2a0c:b381:52e:3600:dd6a:fa62:e132:ec11) dhil |
| 2025-03-21 10:16:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 10:21:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 10:26:00 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-03-21 10:26:41 +0100 | califax | (~califax@user/califx) califx |
| 2025-03-21 10:30:07 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-03-21 10:36:09 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2025-03-21 10:39:48 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-03-21 10:41:14 +0100 | califax | (~califax@user/califx) califx |
| 2025-03-21 10:57:47 +0100 | <tomsmeding> | Athas: I have few insights regarding higher-order derivatives in general, let alone with `ad`. :P |
| 2025-03-21 10:58:12 +0100 | <tomsmeding> | (Assuming you mean 2nd, etc. derivatives, not "AD of code containing (higher-order) functions") |
| 2025-03-21 10:58:19 +0100 | <Athas> | tomsmeding: well, I got it working (albeit with undesirable boilerplate), but now it's just remarkably slow. |
| 2025-03-21 10:58:29 +0100 | <tomsmeding> | Athas: which mode did you use? |
| 2025-03-21 10:58:43 +0100 | <Athas> | Forward-over-forward. And it's slower than just hacking up your own dual numbers. |
| 2025-03-21 10:59:03 +0100 | <tomsmeding> | forward in `ad` is just a dual number, so that's rather surprising |
| 2025-03-21 10:59:28 +0100 | <tomsmeding> | did you try Numeric.AD.Mode.Tower(.Double)? It purports to be higher-order forward derivatives |
| 2025-03-21 10:59:46 +0100 | <Athas> | Well, it's not so easy - I need actual nested AD. |
| 2025-03-21 11:00:04 +0100 | <Athas> | I've realised I'm not good at fast Haskell. |
| 2025-03-21 11:00:14 +0100 | <tomsmeding> | few people are |
| 2025-03-21 11:00:34 +0100 | <tomsmeding> | can you share your code with the manual dual numbers? I'm curious to see what beats `ad` |
| 2025-03-21 11:01:21 +0100 | <__monty__> | (I'd appreciate another recap of what AD is. It's not just a way to numerically compute derivatives of numerical functions, is it? Feel free to leave the recap for when the discussion is more or less over.) |
| 2025-03-21 11:01:31 +0100 | <tomsmeding> | __monty__: it is |
| 2025-03-21 11:01:49 +0100 | <tomsmeding> | the problem is that you can do so efficiently for a function of type R^n -> R, or for a function of type R -> R^n |
| 2025-03-21 11:02:09 +0100 | <tomsmeding> | the typical dual-numbers formulation gives you the _latter_, whereas you usually (but not always) want the former |
| 2025-03-21 11:02:25 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 11:02:28 +0100 | <tomsmeding> | the former you get with reverse AD, which is more complicated |
| 2025-03-21 11:02:35 +0100 | <tomsmeding> | does that help? |
| 2025-03-21 11:04:14 +0100 | <Athas> | This is my code: https://github.com/gradbench/gradbench/blob/4fdb8cc00daaae42b99431fde3da7be1b1bbbc13/tools/haskell… |
| 2025-03-21 11:04:14 +0100 | <Athas> | This is the ad hoc version: https://engineering.purdue.edu/~qobi/stalingrad-examples2009/particle-FF-ghc.html |
| 2025-03-21 11:04:26 +0100 | <Athas> | And the dual numbers: https://engineering.purdue.edu/~qobi/stalingrad-examples2009/common-ghc.html |
| 2025-03-21 11:04:42 +0100 | <tomsmeding> | ooh, DatatypeContexts |
| 2025-03-21 11:05:13 +0100 | <Athas> | Yes, it is aaaalmost working Haskell. |
| 2025-03-21 11:05:18 +0100 | <Athas> | There are also n+k patterns. |
| 2025-03-21 11:05:24 +0100 | <Athas> | But it is easy to fix. |
| 2025-03-21 11:05:31 +0100 | <tomsmeding> | that will likely be faster if you `data Bundle = Bundle {-# UNPACK #-} !Double {-# UNPACK #-} !Double` |
| 2025-03-21 11:05:41 +0100 | <tomsmeding> | but let me read |
| 2025-03-21 11:05:42 +0100 | <Athas> | Sure, but it is already faster than 'ad'. |
| 2025-03-21 11:05:45 +0100 | <tomsmeding> | lol |
| 2025-03-21 11:06:10 +0100 | <tomsmeding> | 'ad' with Forward over Forward, or Forward over ForwardDouble? |
| 2025-03-21 11:06:15 +0100 | <Athas> | Forward over Forward. |
| 2025-03-21 11:06:38 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-21 11:07:05 +0100 | <tomsmeding> | I like this blast-to-the-past Haskell style |
| 2025-03-21 11:08:36 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-03-21 11:10:48 +0100 | <tomsmeding> | Athas: I see a 'gradient' function that uses forward AD |
| 2025-03-21 11:10:51 +0100 | <tomsmeding> | is that intentional? |
| 2025-03-21 11:11:41 +0100 | <Athas> | tomsmeding: in which program? |
| 2025-03-21 11:12:24 +0100 | <tomsmeding> | I was looking at the stalingrad example, but it seems you've implemented that with a proper reverse-mode gradient |
| 2025-03-21 11:12:46 +0100 | <Athas> | I have done all variants in my 'ad' code. |
| 2025-03-21 11:12:58 +0100 | <Athas> | The hand-written code only has forward-over-forward. |
| 2025-03-21 11:13:01 +0100 | <tomsmeding> | oh, right |
| 2025-03-21 11:13:08 +0100 | <tomsmeding> | the closest match is 'ff'? |
| 2025-03-21 11:14:02 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 272 seconds) |
| 2025-03-21 11:14:08 +0100 | <Athas> | Yes. |
| 2025-03-21 11:14:12 +0100 | <tomsmeding> | the input to f is also only length 2, so doing forward mode twice has a chance of being competitive with reverse AD |
| 2025-03-21 11:15:04 +0100 | <tomsmeding> | I have no clue juts from looking at the code; I would perhaps profile to see if there's anything surprising, but it's bound to produce noise here |
| 2025-03-21 11:15:13 +0100 | <Athas> | Yes, forward mode is better here, but it is still slow. |
| 2025-03-21 11:16:33 +0100 | <tomsmeding> | the Forward in 'ad' is a sum type with special cases for zero (not sure why?) and constants |
| 2025-03-21 11:16:53 +0100 | <tomsmeding> | oh, the zero is relevant if you're doing nested AD I guess |
| 2025-03-21 11:17:16 +0100 | <tomsmeding> | perhaps that just introduces busywork here? I don't know |
| 2025-03-21 11:17:50 +0100 | mniip | (mniip@libera/staff/mniip) (Ping timeout: 604 seconds) |
| 2025-03-21 11:18:11 +0100 | <tomsmeding> | Athas: if you haven't yet, I recommend implementing 'ff' by Forward over ForwardDouble, I suspect it'll help quite a bit |
| 2025-03-21 11:20:41 +0100 | <Athas> | tomsmeding: I gave it a shot yesterday, but received some type errors I couldn't figure out. Maybe I will try again. |
| 2025-03-21 11:22:48 +0100 | <ski> | that `stalingrad' code looks a bit weird |
| 2025-03-21 11:22:56 +0100 | <haskellbridge> | <Liamzee> [exa]: so it's the fault of the person who made the servant lib |
| 2025-03-21 11:22:57 +0100 | <haskellbridge> | <Liamzee> oh well |
| 2025-03-21 11:23:44 +0100 | <Athas> | ski: it's written by Scheme programmers and specifically to resemble the style of a corresponding Scheme program. |
| 2025-03-21 11:24:15 +0100 | <haskellbridge> | <Liamzee> erm, not the lib, but the adapter for the lib |
| 2025-03-21 11:24:38 +0100 | <haskellbridge> | <Liamzee> will probably try to figure out how to get it to cache lucid later |
| 2025-03-21 11:24:47 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:19d8:9179:8622:bdf3) (Quit: WeeChat 4.1.1) |
| 2025-03-21 11:25:23 +0100 | <ski> | (lot of use of `let'-`in', rather than `where'. some redundant brackets (e.g. when defining some infix operators, or sometimes around function calls, or even conses). incorrect `Show' instance (ought to use `showsPrec', not `show') |
| 2025-03-21 11:25:39 +0100 | <ski> | mhm |
| 2025-03-21 11:25:56 +0100 | <ski> | any relation to the Stalin Scheme implementation, Athas ? |
| 2025-03-21 11:26:09 +0100 | <Athas> | ski: yeah, same people. |
| 2025-03-21 11:26:14 +0100 | <ski> | ah |
| 2025-03-21 11:26:51 +0100 | <Athas> | This is code from a benchmark suite to demonstrate how wonderful Stalingrad (an extension of Stalin) is. |
| 2025-03-21 11:27:20 +0100 | <ski> | it calls out to Scheme code, from Haskell ? |
| 2025-03-21 11:28:04 +0100 | <Athas> | No, it is a bunch of implementations of the same program in various languages, followed by a performance comparison. Stalingrad is by far the fastest. |
| 2025-03-21 11:28:29 +0100 | mniip | (mniip@libera/staff/mniip) mniip |
| 2025-03-21 11:28:32 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-03-21 11:28:54 +0100 | <ski> | ah |
| 2025-03-21 11:30:31 +0100 | <Athas> | See https://www.bcl.hamilton.ie/~qobi/ad2016-benchmarks/ |
| 2025-03-21 11:30:36 +0100 | <Athas> | Nice work, really! |
| 2025-03-21 11:32:40 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
| 2025-03-21 11:32:47 +0100 | <ski> | "Scheme->C" is a particular Scheme implementation ? |
| 2025-03-21 11:32:53 +0100 | <ski> | can't recall hearing about that one, before |
| 2025-03-21 11:34:06 +0100 | <ski> | yea, looks like a quite nice variety of different backend languages |
| 2025-03-21 11:34:20 +0100 | <ski> | /implementations |
| 2025-03-21 11:35:57 +0100 | <ski> | does any of those use source transformations ? |
| 2025-03-21 11:36:14 +0100 | <sprout> | needs egel |
| 2025-03-21 11:36:57 +0100 | <ski> | "three files that contain the code that is transformed zero, one, and two times" -- sounds like it, yea |
| 2025-03-21 11:37:46 +0100 | <ski> | "We could not benchmark against ADIC because we were unsuccessful in getting ADIC to transform its own generated code." -- for higher derivatives ? |
| 2025-03-21 11:39:01 +0100 | <ski> | "polyvariant submission" does sound like it suggests something like partial evaluation / program specialization, or related |
| 2025-03-21 11:42:08 +0100 | alp | (~alp@2001:861:8ca0:4940:1861:ecb2:15d3:3a1d) |
| 2025-03-21 11:42:48 +0100 | AlexZenon | (~alzenon@94.233.240.210) (Read error: Connection reset by peer) |
| 2025-03-21 11:43:04 +0100 | AlexZenon | (~alzenon@94.233.240.210) |
| 2025-03-21 11:45:21 +0100 | Ekho | (~Ekho@user/ekho) (Remote host closed the connection) |
| 2025-03-21 11:47:46 +0100 | Fijxu | (~Fijxu@user/fijxu) (Ping timeout: 248 seconds) |
| 2025-03-21 11:48:43 +0100 | natto17 | (~natto@129.154.243.159) natto |
| 2025-03-21 11:49:32 +0100 | natto | (~natto@129.154.243.159) (Ping timeout: 260 seconds) |
| 2025-03-21 11:49:32 +0100 | noteness | (~noteness@user/noteness) (Ping timeout: 260 seconds) |
| 2025-03-21 11:49:32 +0100 | Hafydd | (~Hafydd@user/hafydd) (Ping timeout: 260 seconds) |
| 2025-03-21 11:49:33 +0100 | noteness_ | (~noteness@user/noteness) nessessary129 |
| 2025-03-21 11:50:29 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 11:50:49 +0100 | Hafydd | (~Hafydd@user/hafydd) Hafydd |
| 2025-03-21 11:51:04 +0100 | Fijxu_ | (~Fijxu@user/fijxu) fijxu |
| 2025-03-21 11:51:58 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Ping timeout: 252 seconds) |
| 2025-03-21 11:54:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-21 12:00:19 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-21 12:00:46 +0100 | Ekho | (~Ekho@user/ekho) Ekho |
| 2025-03-21 12:06:20 +0100 | <Athas> | ski: yes, Scheme->C is a Scheme compiler (actually there seems to be several of that name, very confusing). I don't think any of them implement AD with source transformation. |
| 2025-03-21 12:07:28 +0100 | <Athas> | ski: oh right, those Fortran things are source transformers. But they work terribly. |
| 2025-03-21 12:07:40 +0100 | <Athas> | The authors actually wrote an entire paper about how none of those tools work. |
| 2025-03-21 12:09:41 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 248 seconds) |
| 2025-03-21 12:13:34 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2025-03-21 12:15:06 +0100 | euleritian | (~euleritia@dynamic-176-006-132-178.176.6.pool.telefonica.de) |
| 2025-03-21 12:24:58 +0100 | sprotte24 | (~sprotte24@p200300d16f266c002dc4a2d25f2ad6fe.dip0.t-ipconnect.de) |
| 2025-03-21 12:27:04 +0100 | euleritian | (~euleritia@dynamic-176-006-132-178.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 12:27:22 +0100 | euleritian | (~euleritia@95.90.214.149) |
| 2025-03-21 12:27:48 +0100 | <merijn> | Athas: That sounds about right :p |
| 2025-03-21 12:30:36 +0100 | xff0x | (~xff0x@2405:6580:b080:900:74ac:a2fa:2f95:eb9f) |
| 2025-03-21 12:35:00 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 12:35:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 12:40:14 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 12:43:44 +0100 | euleritian | (~euleritia@95.90.214.149) (Ping timeout: 260 seconds) |
| 2025-03-21 12:44:10 +0100 | ^Dan | (~xxx@89.136.142.218) |
| 2025-03-21 12:45:16 +0100 | alecs | (~alecs@nat16.software.imdea.org) (Quit: alecs) |
| 2025-03-21 12:46:51 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-03-21 12:47:24 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 12:52:17 +0100 | ^Dan | (~xxx@89.136.142.218) (Remote host closed the connection) |
| 2025-03-21 13:01:42 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 13:03:42 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 13:03:45 +0100 | chele | (~chele@user/chele) chele |
| 2025-03-21 13:08:44 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Quit: ash3en) |
| 2025-03-21 13:08:53 +0100 | alp | (~alp@2001:861:8ca0:4940:1861:ecb2:15d3:3a1d) (Ping timeout: 248 seconds) |
| 2025-03-21 13:08:53 +0100 | ash3en1 | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 13:09:46 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-03-21 13:10:17 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-03-21 13:11:17 +0100 | ash3en1 | ash3en |
| 2025-03-21 13:17:29 +0100 | amir | (sid22336@user/amir) (Quit: Connection closed for inactivity) |
| 2025-03-21 13:20:37 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 13:23:18 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2025-03-21 13:24:16 +0100 | euleritian | (~euleritia@95.90.214.149) |
| 2025-03-21 13:25:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-03-21 13:34:44 +0100 | kh0d | (~kh0d@109.111.226.14) (Remote host closed the connection) |
| 2025-03-21 13:35:15 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Quit: ash3en) |
| 2025-03-21 13:35:27 +0100 | ash3en1 | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 13:37:45 +0100 | ash3en1 | ash3en |
| 2025-03-21 13:42:40 +0100 | kh0d | (~kh0d@109.111.226.14) kh0d |
| 2025-03-21 13:45:09 +0100 | loonycyborg_ | (loonycybor@chat.chantal.wesnoth.org) (Ping timeout: 265 seconds) |
| 2025-03-21 13:45:46 +0100 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-03-21 13:47:27 +0100 | loonycyborg | (loonycybor@wesnoth/developer/loonycyborg) loonycyborg |
| 2025-03-21 13:47:35 +0100 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Quit: WeeChat 4.4.3) |
| 2025-03-21 13:47:55 +0100 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-03-21 13:48:43 +0100 | kh0d | (~kh0d@109.111.226.14) (Ping timeout: 245 seconds) |
| 2025-03-21 13:49:30 +0100 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) (Client Quit) |
| 2025-03-21 13:50:45 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-03-21 13:50:48 +0100 | hughjfchen | (~hughjfche@vmi2417424.contaboserver.net) hughjfchen |
| 2025-03-21 13:54:03 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) jespada |
| 2025-03-21 13:54:44 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) (Client Quit) |
| 2025-03-21 13:55:41 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Quit: ash3en) |
| 2025-03-21 13:55:50 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) jespada |
| 2025-03-21 13:55:57 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 13:56:41 +0100 | kh0d | (~kh0d@109.111.226.14) |
| 2025-03-21 14:01:20 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 14:03:04 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Ping timeout: 260 seconds) |
| 2025-03-21 14:04:08 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 14:05:42 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 14:06:26 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 248 seconds) |
| 2025-03-21 14:10:09 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-21 14:18:22 +0100 | alp | (~alp@2001:861:8ca0:4940:ce87:6c75:c7a9:f360) |
| 2025-03-21 14:23:37 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 14:29:01 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-21 14:30:51 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 244 seconds) |
| 2025-03-21 14:32:49 +0100 | Guest84 | (~Guest84@14.139.38.105) |
| 2025-03-21 14:36:19 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2025-03-21 14:42:58 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-03-21 14:43:02 +0100 | alp | (~alp@2001:861:8ca0:4940:ce87:6c75:c7a9:f360) (Ping timeout: 272 seconds) |
| 2025-03-21 14:43:14 +0100 | califax | (~califax@user/califx) califx |
| 2025-03-21 14:44:46 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-03-21 14:45:41 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-03-21 14:45:44 +0100 | Guest84 | (~Guest84@14.139.38.105) (Quit: Client closed) |
| 2025-03-21 14:50:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 14:52:00 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-03-21 14:55:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 14:56:06 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-03-21 15:03:51 +0100 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2025-03-21 15:11:22 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-03-21 15:11:40 +0100 | Digit | (~user@user/digit) (Ping timeout: 244 seconds) |
| 2025-03-21 15:11:50 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-21 15:12:36 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-03-21 15:15:26 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 15:17:20 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-21 15:20:16 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-03-21 15:21:02 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 272 seconds) |
| 2025-03-21 15:24:03 +0100 | kh0d | (~kh0d@109.111.226.14) (Remote host closed the connection) |
| 2025-03-21 15:26:37 +0100 | kh0d | (~kh0d@109.111.226.14) |
| 2025-03-21 15:31:13 +0100 | kh0d | (~kh0d@109.111.226.14) (Ping timeout: 245 seconds) |
| 2025-03-21 15:31:14 +0100 | adamCS | (~adamCS@pool-100-33-104-162.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-03-21 15:31:14 +0100 | doyougnu- | (~doyougnu@syn-045-046-170-068.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-21 15:31:23 +0100 | adamCS | (~adamCS@pool-100-33-104-162.nycmny.fios.verizon.net) adamCS |
| 2025-03-21 15:32:48 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 246 seconds) |
| 2025-03-21 15:33:16 +0100 | doyougnu | (~doyougnu@syn-045-046-170-068.res.spectrum.com) |
| 2025-03-21 15:33:40 +0100 | Digitteknohippie | Digit |
| 2025-03-21 15:35:33 +0100 | noteness_ | (~noteness@user/noteness) (Ping timeout: 248 seconds) |
| 2025-03-21 15:35:50 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 15:36:39 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 252 seconds) |
| 2025-03-21 15:37:51 +0100 | noteness | (~noteness@user/noteness) nessessary129 |
| 2025-03-21 15:38:17 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-21 15:40:29 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 15:46:35 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) jespada |
| 2025-03-21 15:49:02 +0100 | myme | (~myme@2a01:799:d5e:5f00:69c6:1b0c:ff6d:bdea) myme |
| 2025-03-21 15:49:15 +0100 | Buliarou1 | (~gypsydang@46.232.210.139) Buliarous |
| 2025-03-21 15:49:51 +0100 | kh0d | (~kh0d@109.111.226.14) kh0d |
| 2025-03-21 15:50:06 +0100 | as__ | (~as@2800:a4:396:c900:c2ca:9624:369a:7d24) |
| 2025-03-21 15:51:04 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2025-03-21 15:52:53 +0100 | euleritian | (~euleritia@95.90.214.149) (Read error: Connection reset by peer) |
| 2025-03-21 15:54:42 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) |
| 2025-03-21 15:57:03 +0100 | ft | (~ft@p508db463.dip0.t-ipconnect.de) ft |
| 2025-03-21 15:58:04 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-21 15:59:01 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 15:59:19 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 16:02:14 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 16:02:16 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:314f:c6fc:a776:72e4) |
| 2025-03-21 16:02:24 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 16:06:48 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-03-21 16:07:07 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) |
| 2025-03-21 16:07:58 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 16:08:17 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) |
| 2025-03-21 16:11:49 +0100 | as__ | (~as@2800:a4:396:c900:c2ca:9624:369a:7d24) (Ping timeout: 244 seconds) |
| 2025-03-21 16:12:25 +0100 | as___ | (~as@2800:a4:396:c900:c2ca:9624:369a:7d24) |
| 2025-03-21 16:14:20 +0100 | berzerk | (~berzerk@2800:a4:396:c900:c2ca:9624:369a:7d24) |
| 2025-03-21 16:15:06 +0100 | bsima | (~bsima@143.198.118.179) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-03-21 16:15:31 +0100 | bsima | (~bsima@143.198.118.179) bsima |
| 2025-03-21 16:16:48 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-21 16:16:55 +0100 | <absence> | When using a constraint called Subset, which takes two type-level lists, I find myself having to use "Subset (x : list1) (x : list2) => ..." instead of just "Subset list1 list2". Is there a way to convince the type checker that the x is superfluous? |
| 2025-03-21 16:17:53 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 16:18:44 +0100 | <tomsmeding> | absence: I have a feeling that this is an X-Y problem, and that the answer is a common-ish trick that I don't know a name for: define an associated type family to your class where the right-hand sides are precisely the instance contexts, then add that type family as a _superclass_ constraint to the class |
| 2025-03-21 16:19:26 +0100 | <tomsmeding> | that allows ghc to, given an `instance C A => C T` not only infer `C T` from `C A`, but furthermore conclude from evidence of `C T` that `C A` must also hold |
| 2025-03-21 16:19:35 +0100 | <tomsmeding> | the latter is normally _not_ what GHC does |
| 2025-03-21 16:19:58 +0100 | <tomsmeding> | if you don't know what I'm talking about, or don't know how it applies to your case, you'll have to share the definition of that Subset thing |
| 2025-03-21 16:20:11 +0100 | <absence> | Can I do that if the constraint and the function that needs it are defined in a third-party library? |
| 2025-03-21 16:20:29 +0100 | <tomsmeding> | no |
| 2025-03-21 16:20:33 +0100 | <tomsmeding> | you have to modify the class |
| 2025-03-21 16:20:50 +0100 | <tomsmeding> | I'm not 100% sure this is what you are running into, but it has a similar "vibe" :p |
| 2025-03-21 16:20:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 16:21:17 +0100 | <absence> | Here's the constraint by the way: https://hackage.haskell.org/package/effectful-core-2.5.1.0/docs/src/Effectful.Internal.Effect.html… |
| 2025-03-21 16:21:38 +0100 | taktoa[c] | (sid282096@id-282096.tinside.irccloud.com) (Ping timeout: 244 seconds) |
| 2025-03-21 16:22:45 +0100 | <tomsmeding> | ah, so `Subset list1 list2 => Subset (x : list1) (x : list2)` itself isn't even directly derivable |
| 2025-03-21 16:22:57 +0100 | taktoa[c] | (sid282096@id-282096.tinside.irccloud.com) taktoa[c] |
| 2025-03-21 16:23:29 +0100 | <absence> | Speaking of vibes, it feels vaguely similar to "(Monad (t m), Monad m, MonadTrans t) =>", so maybe something something QuantifiedConstraints...? |
| 2025-03-21 16:23:42 +0100 | jackdk | (sid373013@cssa/jackdk) (Ping timeout: 244 seconds) |
| 2025-03-21 16:23:43 +0100 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (Ping timeout: 268 seconds) |
| 2025-03-21 16:24:29 +0100 | <int-e> | Looks like Subset (x : list1) (x : list2) should simplify to Subset list1 (x : list2), but there's nothing that ensures that list1 doesn't contain another x... |
| 2025-03-21 16:24:37 +0100 | <tomsmeding> | absence: Note that `Subset (x : list1) (x : list2)` is NOT equivalent to `Subset list1 list2`: the former allows elements of list1 to be equal to x, whereas the latter only allows that if x is in list2 |
| 2025-03-21 16:24:44 +0100 | <tomsmeding> | that |
| 2025-03-21 16:25:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 16:25:56 +0100 | jackdk | (sid373013@cssa/jackdk) jackdk |
| 2025-03-21 16:26:47 +0100 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2025-03-21 16:28:31 +0100 | berzerk | (~berzerk@2800:a4:396:c900:c2ca:9624:369a:7d24) (Ping timeout: 265 seconds) |
| 2025-03-21 16:30:27 +0100 | as___ | (~as@2800:a4:396:c900:c2ca:9624:369a:7d24) (Ping timeout: 265 seconds) |
| 2025-03-21 16:31:12 +0100 | <absence> | I'm not sure I see how adding an x to both of them breaks the subset relationship... |
| 2025-03-21 16:31:36 +0100 | <tomsmeding> | absence: sure, Subset a b implies Subset (x:a) (x:b). But the other way round does not hold |
| 2025-03-21 16:32:01 +0100 | <tomsmeding> | [1,1] is a subset of [1,2], but [1] is not a subset of [2] |
| 2025-03-21 16:32:49 +0100 | <absence> | Oh right, that makes sense. |
| 2025-03-21 16:33:18 +0100 | <tomsmeding> | Now, even the implication `Subset a b => Subset (x:a) (x:b)` is not directly inferrable from the given instances, but you could prove it perhaps, given singletons for those lists |
| 2025-03-21 16:33:35 +0100 | <EvanR> | x = x ? |
| 2025-03-21 16:33:54 +0100 | <tomsmeding> | > x == x |
| 2025-03-21 16:33:55 +0100 | <lambdabot> | True |
| 2025-03-21 16:33:57 +0100 | <tomsmeding> | seems so |
| 2025-03-21 16:33:58 +0100 | <EvanR> | oh was reading : as "type off" |
| 2025-03-21 16:34:00 +0100 | <EvanR> | er |
| 2025-03-21 16:34:04 +0100 | <EvanR> | type O |
| 2025-03-21 16:34:24 +0100 | <tomsmeding> | we're in #haskell, not in #agda ;) |
| 2025-03-21 16:36:10 +0100 | <absence> | Proving things with singletons sounds like it will quickly escalate into "not worth it". :p |
| 2025-03-21 16:37:14 +0100 | <tomsmeding> | also not particularly efficient. |
| 2025-03-21 16:37:28 +0100 | <EvanR> | was just reading about "presets" which are setoids (a set that comes equipped with an equivalence relation) without the equivalence relation provided. And then it explained "a preset becomes a set if you give it a relation which.... is reflexive (x = x)" |
| 2025-03-21 16:38:11 +0100 | <EvanR> | xD |
| 2025-03-21 16:38:41 +0100 | <EvanR> | (and other properties but, they also involve "=") |
| 2025-03-21 16:40:22 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 268 seconds) |
| 2025-03-21 16:41:13 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-03-21 16:41:51 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-21 16:42:54 +0100 | <EvanR> | ok I got confused, = is the relation being defined |
| 2025-03-21 16:43:13 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 16:43:39 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 16:45:40 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 16:50:04 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-03-21 16:50:26 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 252 seconds) |
| 2025-03-21 16:50:52 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) |
| 2025-03-21 16:51:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-21 16:55:39 +0100 | vpan | (~vpan@212.117.1.172) |
| 2025-03-21 17:00:29 +0100 | <roconnor> | EvanR: PERs: Partial Equivalence Relations |
| 2025-03-21 17:01:17 +0100 | <EvanR> | yes? |
| 2025-03-21 17:03:14 +0100 | <roconnor> | Oh I misunderstood what your presets were. |
| 2025-03-21 17:03:29 +0100 | <roconnor> | I though they were setoids without reflexivity. |
| 2025-03-21 17:04:31 +0100 | <EvanR> | I actually veered off, the presets are "sets" without equality among the elements |
| 2025-03-21 17:04:57 +0100 | <EvanR> | (yet) |
| 2025-03-21 17:05:51 +0100 | <EvanR> | so x doesn't equal x because equal doesn't exist |
| 2025-03-21 17:06:58 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 17:07:55 +0100 | euleritian | (~euleritia@dynamic-176-006-136-021.176.6.pool.telefonica.de) (Ping timeout: 244 seconds) |
| 2025-03-21 17:07:55 +0100 | Square | (~Square@user/square) Square |
| 2025-03-21 17:11:20 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 17:23:03 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:314f:c6fc:a776:72e4) (Remote host closed the connection) |
| 2025-03-21 17:23:06 +0100 | <haskellbridge> | <Bowuigi> How are those useful? I mean, order dependency is nice but do they make something more elegant? |
| 2025-03-21 17:23:25 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:314f:c6fc:a776:72e4) |
| 2025-03-21 17:24:58 +0100 | <haskellbridge> | <Bowuigi> Quotients become central in proofs, that's nice |
| 2025-03-21 17:26:29 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f937555fc5a67c80b19.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-03-21 17:27:09 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) |
| 2025-03-21 17:27:37 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-03-21 17:28:33 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Client Quit) |
| 2025-03-21 17:29:23 +0100 | <EvanR> | something about foundations https://ncatlab.org/nlab/show/preset |
| 2025-03-21 17:30:05 +0100 | <EvanR> | it was the 60s, so maybe they were tripping AF |
| 2025-03-21 17:31:49 +0100 | <EvanR> | also you could attempt to construe haskell's datatypes as presets because not all of them have a way to, at least decidably, know two values are equal |
| 2025-03-21 17:32:20 +0100 | <EvanR> | either because there's no Eq instance or because more serious issues |
| 2025-03-21 17:33:10 +0100 | <haskellbridge> | <Bowuigi> The concept of prefunction seems useful |
| 2025-03-21 17:33:58 +0100 | <EvanR> | yes we have functions between types that might not agree with one or more notions of equality we have in mind on the domains |
| 2025-03-21 17:34:03 +0100 | <haskellbridge> | <Bowuigi> Being able to ignore equality means that you can inspect the internal structure of something without that being in "normal form" |
| 2025-03-21 17:35:25 +0100 | <EvanR> | or you could talk about, however you did it, any function you manage to define automatically preserves (a) notion of equality |
| 2025-03-21 17:35:41 +0100 | <EvanR> | which we might take for granted and otherwise never had language for |
| 2025-03-21 17:36:30 +0100 | <EvanR> | (automatically preserves equality, perhaps without using normal forms) |
| 2025-03-21 17:36:42 +0100 | <haskellbridge> | <Bowuigi> That's usually called congruence I think |
| 2025-03-21 17:37:58 +0100 | <EvanR> | sounds like a luxury to be able to pick a "real" equality relation so you can call other mappings congruence |
| 2025-03-21 17:38:10 +0100 | <EvanR> | or homomorphism |
| 2025-03-21 17:43:58 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-03-21 17:45:23 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-03-21 17:48:56 +0100 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2025-03-21 17:49:50 +0100 | Square | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2025-03-21 17:50:19 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-03-21 17:52:42 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 17:56:34 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-21 17:56:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-21 17:57:27 +0100 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 268 seconds) |
| 2025-03-21 18:10:09 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-03-21 18:11:14 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 18:11:33 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 18:11:36 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2025-03-21 18:12:31 +0100 | chiselfu1e | chiselfuse |
| 2025-03-21 18:16:30 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Ping timeout: 276 seconds) |
| 2025-03-21 18:16:52 +0100 | euleritian | (~euleritia@95.90.214.149) |
| 2025-03-21 18:17:25 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-03-21 18:20:59 +0100 | euleritian | (~euleritia@95.90.214.149) (Ping timeout: 252 seconds) |
| 2025-03-21 18:21:55 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) |
| 2025-03-21 18:24:29 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-03-21 18:25:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-21 18:26:44 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-03-21 18:27:28 +0100 | <EvanR> | so we can go from, imperative language with "functions" doesn't have real functions because they do side effects, or depend on invisible state, etc. to functional language with "functions" futhermore doesn't have functions because it doesn't preserve the equality xD |
| 2025-03-21 18:27:34 +0100 | <EvanR> | no true function |
| 2025-03-21 18:32:56 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-21 18:37:44 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) jespada |
| 2025-03-21 18:38:46 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 18:41:16 +0100 | <__monty__> | I'm not sure that's entirely rigorous. Nowhere do the definitions require that the notion of equality is part of the language of the functions, right? |
| 2025-03-21 18:43:12 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-21 18:43:26 +0100 | <c_wraith> | No, though if you're strictly in math... If the objects in the pairs that make up a formal function can be compared for equality, then functions are equal if they contain the same set of pairs. |
| 2025-03-21 18:43:41 +0100 | <c_wraith> | It gets much harder when you want equality to be computable |
| 2025-03-21 18:43:59 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 18:44:03 +0100 | <EvanR> | if x = y then f(x) = f(y) can be |
| 2025-03-21 18:44:22 +0100 | <EvanR> | derived from the usual definition of functions in set theory |
| 2025-03-21 18:45:53 +0100 | <EvanR> | and is otherwise a pretty common rule to rely on |
| 2025-03-21 18:45:54 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) |
| 2025-03-21 18:46:09 +0100 | <EvanR> | even though it's wrong! |
| 2025-03-21 18:46:45 +0100 | dhil | (~dhil@2a0c:b381:52e:3600:dd6a:fa62:e132:ec11) (Ping timeout: 265 seconds) |
| 2025-03-21 18:47:22 +0100 | euleritian | (~euleritia@dynamic-176-000-195-182.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-03-21 18:47:40 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 18:47:57 +0100 | <EvanR> | e.g. in a possible implementation of computable reals, you could have rational real which terminates and is easy to compute with, and another real which converges to the same rational, and causes the f to explode when applied to it |
| 2025-03-21 18:48:38 +0100 | <EvanR> | (though now you might argue the f is not really a function after all, since it's observing a difference, which is the same point as above) |
| 2025-03-21 18:52:23 +0100 | <haskellbridge> | <Bowuigi> It's only wrong from an undecidability/non-termination standpoint |
| 2025-03-21 18:52:34 +0100 | <haskellbridge> | <Bowuigi> Even then, it holds for PERs IIRC |
| 2025-03-21 18:53:04 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 18:53:37 +0100 | <haskellbridge> | <Bowuigi> Congruence is derivable in various type theories as well, even without identity types |
| 2025-03-21 18:53:53 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) |
| 2025-03-21 18:55:24 +0100 | <EvanR> | another example is treating zero and minus zero differently in floats. Another example is implementing rationals with two numbers, and mapping 1/2 and 2/4 to false and true respectively (assuming false and true are not equal) |
| 2025-03-21 18:56:10 +0100 | <EvanR> | though in these cases indeed x = x, which is what got me started on this |
| 2025-03-21 18:56:23 +0100 | <sim590> | foo |
| 2025-03-21 18:56:29 +0100 | <EvanR> | except for NaN |
| 2025-03-21 18:56:54 +0100 | xeno11 | (~xeno11@c-69-140-170-168.hsd1.de.comcast.net) |
| 2025-03-21 18:57:07 +0100 | <sim590> | test |
| 2025-03-21 18:58:31 +0100 | <EvanR> | failed |
| 2025-03-21 18:58:33 +0100 | <haskellbridge> | <Bowuigi> IEEE-754 floats are so weird |
| 2025-03-21 18:58:43 +0100 | <sim590> | :) |
| 2025-03-21 18:59:18 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-03-21 19:00:28 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-21 19:00:33 +0100 | <xeno11> | To anyone that can help/edit wiki... haskell wikibook main page was edited. It seems "Haskell is pure" was changed to "JEWS ARE THE BEST |
| 2025-03-21 19:00:34 +0100 | <xeno11> | LIRON WAS THE CREATOR OF COMPUTERS" and other changes might have been made. |
| 2025-03-21 19:01:20 +0100 | <xeno11> | https://en.wikibooks.org/wiki/Haskell |
| 2025-03-21 19:01:20 +0100 | euleritian | (~euleritia@ip5f5ad695.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-03-21 19:01:21 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 248 seconds) |
| 2025-03-21 19:02:06 +0100 | euleritian | (~euleritia@95.90.214.149) |
| 2025-03-21 19:03:14 +0100 | <EvanR> | seems like the kind of thing the wiki infrastructure would flag automatically |
| 2025-03-21 19:08:46 +0100 | tromp | (~textual@2a02:a210:cba:8500:40b3:acb4:4579:83af) |
| 2025-03-21 19:12:29 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-21 19:14:00 +0100 | kh0d | (~kh0d@109.111.226.14) (Remote host closed the connection) |
| 2025-03-21 19:20:59 +0100 | <haskellbridge> | <Bowuigi> Who's Liron and why did they create computers? |
| 2025-03-21 19:22:01 +0100 | <dminuoso> | More importantly, why did they even name them computers and did they have the authority to do so? |
| 2025-03-21 19:22:54 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f6518434db087d421fc.dip0.t-ipconnect.de) acidjnk |
| 2025-03-21 19:24:50 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 19:25:31 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) justsomeguy |
| 2025-03-21 19:28:56 +0100 | kh0d | (~kh0d@212.200.65.86) kh0d |
| 2025-03-21 19:29:12 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-21 19:30:13 +0100 | <EvanR> | In the beginning the Universe was created. |
| 2025-03-21 19:30:13 +0100 | <EvanR> | This had made many people very angry and has been widely regarded as a bad move. |
| 2025-03-21 19:31:36 +0100 | alp | (~alp@2001:861:8ca0:4940:4f32:5e1f:632d:94e1) |
| 2025-03-21 19:31:56 +0100 | Clint | golfclaps. |
| 2025-03-21 19:43:13 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-03-21 19:44:08 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2025-03-21 19:44:57 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2025-03-21 19:45:22 +0100 | ash3en | (~Thunderbi@89.56.182.235) (Ping timeout: 268 seconds) |
| 2025-03-21 19:47:12 +0100 | <ski> | EvanR : "you could attempt to construe haskell's datatypes as presets because not all of them have a way to, at least decidably, know two values are equal" -- it's useful to consider an intended semantic equality, not necessarily decidable, on various Haskell data types |
| 2025-03-21 19:47:16 +0100 | Pixi` | (~Pixi@user/pixi) Pixi |
| 2025-03-21 19:47:24 +0100 | <ski> | e.g. for `Set's and `Map's considering ones which have the same elements/associations, but represented differently internally, asb being "equal". also not including imbalanced representations as valid representations of the semantic values. leading to having an abstract data type that is intended to be a quotient type of a subset type of the representation type |
| 2025-03-21 19:47:57 +0100 | <ski> | laws for `Eq' could be `x == y = True => x = y' and `x == y = False => x =/= y', where `=' is semantic equality (an equivalence relation on the representations), and `=/=' is semantic inrquality (an apartness relation on the representations) |
| 2025-03-21 19:48:17 +0100 | <ski> | Mercury has (a bit) more explicit support for this, by allowing you to attach a user-defined equality (which is not just "another computable function", but is tied semantically to reasoning laws, and possibly used by some optimizations), causing the data constructor to become non-injective, matching on it is (committed-choice, .. |
| 2025-03-21 19:48:38 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 252 seconds) |
| 2025-03-21 19:48:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-21 19:48:50 +0100 | <ski> | .., the implementation arbitrarily choosed one representation) multi-deterministic (could semantically result in any one of one or more possible results), "tainting" the matching operation to be committed-choice multi-deterministic, .. |
| 2025-03-21 19:48:56 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 272 seconds) |
| 2025-03-21 19:49:00 +0100 | <ski> | .., until you at some point decide to use a `promise_equivalent_solutions' pragma (proof obligation) to claim that at this point you'll get the same result regardless of which representation was observed (or else you can let `main' be comitted-choice multi-deterministic, which you could also do for concurrency, with race conditions possibly affecting result) |
| 2025-03-21 19:50:07 +0100 | Pixi` | (~Pixi@user/pixi) (Read error: Connection reset by peer) |
| 2025-03-21 19:56:56 +0100 | zzz | (~z@user/zero) zero |
| 2025-03-21 19:57:58 +0100 | yin | (~z@user/zero) (Read error: Connection reset by peer) |
| 2025-03-21 19:58:02 +0100 | zzz | yin |
| 2025-03-21 20:00:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 20:00:03 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-21 20:00:47 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-21 20:01:06 +0100 | forell | (~forell@user/forell) (Ping timeout: 252 seconds) |
| 2025-03-21 20:04:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 20:06:30 +0100 | xeno11 | (~xeno11@c-69-140-170-168.hsd1.de.comcast.net) (Ping timeout: 240 seconds) |
| 2025-03-21 20:10:14 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 20:13:30 +0100 | laurapigeon | (~laura@205.124.7.51.dyn.plus.net) |
| 2025-03-21 20:14:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-21 20:15:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 20:18:30 +0100 | <laurapigeon> | Hello! I hope this is the right place to troubleshoot build issues- I'm on a fork of arch linux with the following packages from the arch repos: ghc, cabal-install, stack, haskell-language-server. I can access ghci, import modules and load my own .hs files. But when I try to run `ghc --make helloworld` in a folder with hello world I get the following error. When I try to run ghc-pkg check I get a series of errors like the following, |
| 2025-03-21 20:18:31 +0100 | <laurapigeon> | terminated by the following: https://paste.tomsmeding.com/akUj6oxa |
| 2025-03-21 20:19:06 +0100 | <laurapigeon> | Sorry if this is the wrong place or way to ask, I'm new to IRC |
| 2025-03-21 20:19:32 +0100 | <geekosaur> | arch and derivatives don't ship static libs, which ghc uses by default. add `-dynamic` |
| 2025-03-21 20:20:31 +0100 | <geekosaur> | I think there's a package to get static libs for ghc bootlibs, but not for additional packages |
| 2025-03-21 20:20:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 20:20:49 +0100 | <yushyin> | yeah, ghc-static |
| 2025-03-21 20:20:56 +0100 | <laurapigeon> | Perfect- that worked, thanks a bunch |
| 2025-03-21 20:22:03 +0100 | <laurapigeon> | getting ghc-static from extra made the original command work too, nice! |
| 2025-03-21 20:22:30 +0100 | <yushyin> | laurapigeon: https://wiki.archlinux.org/title/Haskell#Static_linking for more information on the static approach |
| 2025-03-21 20:23:37 +0100 | xeno11 | (~xeno11@c-69-140-170-168.hsd1.de.comcast.net) |
| 2025-03-21 20:24:34 +0100 | <laurapigeon> | oh a reading issue on my part, good to know this is here |
| 2025-03-21 20:29:03 +0100 | Square | (~Square@user/square) Square |
| 2025-03-21 20:31:27 +0100 | <sim590> | I read on multiple posts on the Web that we categorize a function as "unpure" if it has side-effects and furturemore that when calling that function twice, if it doesn't produce the "same" ouptput for the both calls, then it is not pure. To me, this can only apply to IO and only IO is unpure. I read some places that people assume Monads are unpure, but to me it is not the case, because "side |
| 2025-03-21 20:31:29 +0100 | <sim590> | effects" of monads are actually just behind the scene just like with the do operator, it is syntaxic sugar, but in the end, there were no side effects, just some computation abstracted away, but this doesn't mean that in two separate calls of a function that is wrapped in a monad that we supply the same argument because the monad actually hides the abstracted some of the arguments and both |
| 2025-03-21 20:31:31 +0100 | <sim590> | function calls had indeed different arguments. Therefore, am I right to say that only IO is impure and that for example, the State monad or even the Maybe monad are not unpure. They are indeed pure? |
| 2025-03-21 20:31:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 20:31:56 +0100 | <mauke> | <laurapigeon> [...] I'm new to IRC <- no worries, you're doing great so far |
| 2025-03-21 20:34:00 +0100 | <mauke> | sim590: if you're taking that approach, then IO is pure, too |
| 2025-03-21 20:34:15 +0100 | <EvanR> | sim590, an impure function is a function that's not pure. A pure function is a (something) which only depends on the input and has side effects (that you care about) |
| 2025-03-21 20:34:50 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2025-03-21 20:34:54 +0100 | <EvanR> | IO actions don't have a function type in the first place |
| 2025-03-21 20:35:03 +0100 | <EvanR> | so this doesn't directly apply |
| 2025-03-21 20:35:13 +0100 | <mauke> | consider, for example: main1 = putStrLn "." >> putStrLn "." >> putStrLn "."; main2 = let x = putStrLn "." in x >> x >> x |
| 2025-03-21 20:35:14 +0100 | <EvanR> | you don't give them input |
| 2025-03-21 20:35:31 +0100 | <tomsmeding> | laurapigeon: I know it's convenient to be able to get haskell tooling from the system package manager, but do consider using ghcup ( https://www.haskell.org/ghcup/ ) instead, if you haven't already -- besides being the main supported way to get haskell tooling these days, it also gives you much more flexibility with versions etc. |
| 2025-03-21 20:35:56 +0100 | <sim590> | EvanR, mauke: I'm not sure if I should understand that you are agreeing together or not. |
| 2025-03-21 20:35:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-21 20:36:11 +0100 | <mauke> | putStrLn is "pure" in the sense that whenever you call it with a particular string, it returns an IO value that is equivalent to any other IO value returned from putStrLn with the same argument |
| 2025-03-21 20:36:57 +0100 | <mauke> | we're not at odds, I think |
| 2025-03-21 20:37:26 +0100 | <mauke> | I'm talking about the purity of functions like putStrLn, which is indeed a function, and not the purity of IO (), which is not a function |
| 2025-03-21 20:38:05 +0100 | <sim590> | Of course, when i said I was talking about IO, I was talking about the function which are warapped inside IO. |
| 2025-03-21 20:38:16 +0100 | <EvanR> | sim590, I'm trying to clarify your premise using traditional jargon |
| 2025-03-21 20:38:30 +0100 | <EvanR> | "IO is/is not pure" doesn't fit this for categorical reasons |
| 2025-03-21 20:38:31 +0100 | <mauke> | A -> IO B, I hope, not IO (A -> B) |
| 2025-03-21 20:38:51 +0100 | <sim590> | mauke: indeed. |
| 2025-03-21 20:38:57 +0100 | <EvanR> | sim590, there's not necessarily any IO wrapped inside IO |
| 2025-03-21 20:39:02 +0100 | <EvanR> | alskdjf |
| 2025-03-21 20:39:05 +0100 | <EvanR> | any function wrapped inside IO |
| 2025-03-21 20:39:36 +0100 | <EvanR> | it's a big difference from imperative I/O code |
| 2025-03-21 20:39:48 +0100 | <EvanR> | IO actions are first class values you can pass around and store in structures |
| 2025-03-21 20:39:58 +0100 | <EvanR> | but they don't take any arguments or input |
| 2025-03-21 20:40:07 +0100 | <EvanR> | it's just a thing that can be executed |
| 2025-03-21 20:40:13 +0100 | <ski> | sim590 : "this can only apply to IO and only IO is unpure" -- no, things like e.g. internal state, indeterminacy, continuations, could also cause being side-effects, not just Input/Output communication with the OS |
| 2025-03-21 20:40:18 +0100 | <EvanR> | and purity of functions is about... functions |
| 2025-03-21 20:40:24 +0100 | <ski> | sim590 : "\"side effects\" of monads are actually just behind the scene just like with the do operator, it is syntaxic sugar" -- `do' is indeed syntactic sugar, but you can't invoke that to claim something about side-effects or not of monads |
| 2025-03-21 20:40:32 +0100 | <sim590> | w`e mauke said is what I mean. Any function `f :: [[...] A -> ] IO a` if I can write it like that where `[]` means it's optional.. |
| 2025-03-21 20:40:34 +0100 | <ski> | sim590 : "in the end, there were no side effects, just some computation abstracted away" -- you could perhaps phrase it like this, depending on what you mean by this. "calls of a function that is wrapped in a monad" is vague/confusing phrasing (specifically "wrapped in a monad", although also potentially "call") |
| 2025-03-21 20:40:41 +0100 | <ski> | sim590 : "am I right to say that only IO is impure" -- `IO' is not impure |
| 2025-03-21 20:41:06 +0100 | <EvanR> | sim590, well if you have putChar :: Char -> IO (), the important part here is the IO, not the -> |
| 2025-03-21 20:41:10 +0100 | <EvanR> | that function is pure |
| 2025-03-21 20:41:17 +0100 | <EvanR> | but you're calling the IO impure |
| 2025-03-21 20:41:30 +0100 | <EvanR> | calling that function doesn't execute anything |
| 2025-03-21 20:43:03 +0100 | <sim590> | ski: I'm not writing a scientific paper here. I'm discussing and I hope people can grasp what I mean, assuming that I have read and wrote Haskell for at least 5 years now. |
| 2025-03-21 20:44:24 +0100 | laurapigeon | (~laura@205.124.7.51.dyn.plus.net) (Quit: Konversation terminated!) |
| 2025-03-21 20:44:25 +0100 | <sim590> | EvanR: I'm just saying that the set of functions that CAN be impure reside in the set that contains functions of the return type that is `IO a` where a could also be `()`. |
| 2025-03-21 20:44:35 +0100 | <ski> | sim590 : yes. but it's important to try to better understand the relevant concepts and distinctions (and non-distinctions), and to that end it helps being more strict about terminology, for beginners, to understand what is being claimed and not claimed, to understand the essentials of the situaation, and to ensure that we have a common ground for further conversation |
| 2025-03-21 20:44:45 +0100 | <sim590> | by "reside", I mean contained in. |
| 2025-03-21 20:45:34 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 20:45:47 +0100 | <ski> | there is no "`IO' is side-effectful, but other monads are not". this is not a relevant distinction, in Haskell |
| 2025-03-21 20:46:29 +0100 | <sim590> | I'm talking about the functions inside the set of functions why have a return type `IO a` where `a` can be `()` also. |
| 2025-03-21 20:46:43 +0100 | <sim590> | s/why/which/ |
| 2025-03-21 20:46:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 20:47:03 +0100 | <EvanR> | sim590, IO doesn't contain functions... I just get the feeling you're down the wrong path a few miles with the concepts |
| 2025-03-21 20:47:10 +0100 | <sim590> | I'm not saying IO is a set |
| 2025-03-21 20:47:12 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2025-03-21 20:47:19 +0100 | tv | (~tv@user/tv) (Quit: derp) |
| 2025-03-21 20:47:25 +0100 | <sim590> | I'm talkinga bout THE SET of functions which have a return type `IO a`. |
| 2025-03-21 20:47:35 +0100 | <EvanR> | all those functions are pure |
| 2025-03-21 20:47:36 +0100 | tv | (~tv@user/tv) tv |
| 2025-03-21 20:47:41 +0100 | <EvanR> | since all functions in haskell are pure |
| 2025-03-21 20:47:55 +0100 | <EvanR> | it's purely functional |
| 2025-03-21 20:48:13 +0100 | <ski> | "the set of functions that CAN be impure" -- there are zero such functions, in Haskell (unless you unsafe escape hatches like `unsafePerformIO', which comes with proof obligations for the programmer in order to use safely) (there is also an argument that non-termination (and partiality) can be viewed as a side-effect, albeit more "benign" than most other ones. if you want to, we could discuss this, but |
| 2025-03-21 20:48:19 +0100 | <ski> | otherwise i'll assume we agree to disregard these) |
| 2025-03-21 20:50:13 +0100 | <sim590> | EvanR: to me, IO functions have side effects. I can call some IO action which will act on a MVar value and at some point my program, it might terminate and at some other point it might not because another thread has not acted on that MVar value also. |
| 2025-03-21 20:50:30 +0100 | <sim590> | This is the kind of side-effects which I see IO allowing. |
| 2025-03-21 20:51:11 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-21 20:52:14 +0100 | <sim590> | And depending on that circumstance, the function might return 0 or else 1. |
| 2025-03-21 20:52:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-21 20:52:17 +0100 | <EvanR> | sim590, you're focusing on functions returning IO, but that's not how you get side effects |
| 2025-03-21 20:52:18 +0100 | <sim590> | For e.g. |
| 2025-03-21 20:52:22 +0100 | <ski> | sim590 : the main point here is that, unless in languages with side-effects, we have reasoning (including for refactoring) laws which doesn't have to take potential side-effects into account, can be more general ("aggressive"), you can "replace equals by equals". `let x = putStrLn "foo" in do x; x' is equal (equivalent) to `do putStrLn "foo"; putStrLn "foo";'. in C, `{ int n = puts("foo"); n; n }' is not |
| 2025-03-21 20:52:28 +0100 | <ski> | equivalent to `{ puts("foo"); puts("foo") }' |
| 2025-03-21 20:52:34 +0100 | <EvanR> | e.g. getChar :: IO Char will get a char, it's not a function |
| 2025-03-21 20:53:03 +0100 | <EvanR> | meanwhile [putChar 'a', getChar, putChar 'b'] is a list constructed using such functions, but they don't cause side effects |
| 2025-03-21 20:53:33 +0100 | <ski> | sim590 : it does not matter here, what happens "under the hood", whether you'd consider the implementation (not necessarily in Haskell) to "be side-effectful". what matters is how you can reason and observe about program fragments, "at the level of the language" |
| 2025-03-21 20:53:47 +0100 | <EvanR> | but you can execute all three actions contained there in as its own IO action (with no -> involved at that point) |
| 2025-03-21 20:55:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-21 20:56:00 +0100 | <ski> | sim590 : "I can call some IO action which will act on a MVar value and at some point my program, it might terminate and at some other point it might not because another thread has not acted on that MVar value also." -- you're not calling it. calling is for functions. `IO'-actions are not functions. calling `putStrLn' as in the call `putStrLn "foo"' always gives the same result value (that value being an |
| 2025-03-21 20:56:03 +0100 | <sim590> | EvanR: "getChar is not a function" .... "[putChar 'a', getChar, putChar 'b'] is a list constructed using such FUNCTIONS" .... I'm not sure I understand. |
| 2025-03-21 20:56:06 +0100 | <ski> | `IO'-action, a "recipe" for what I/O operations to (possibly) later perform). later, you can invoke/run/perform this action, and that is what causes observable input/output interactions to happen |
| 2025-03-21 20:56:17 +0100 | <EvanR> | sim590, well, putChar is one your functions |
| 2025-03-21 20:56:22 +0100 | <EvanR> | that you think has side effects |
| 2025-03-21 20:56:29 +0100 | <EvanR> | (it doesn't, this demonstrates why) |
| 2025-03-21 20:56:49 +0100 | <EvanR> | getChar is in the same boat as the result of putChar, but is not a function |
| 2025-03-21 20:57:03 +0100 | <EvanR> | these are counterexamples to your theory |
| 2025-03-21 20:57:20 +0100 | <ski> | `IO'-actions (explicitly) express (Input/Output-) effects. the "explicitly" part is why this is not *side*-effects (which would be implicit) |
| 2025-03-21 20:58:08 +0100 | <sim590> | EvanR: are you saying that `f :: a` is not a function ?& |
| 2025-03-21 20:58:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 260 seconds) |
| 2025-03-21 20:59:11 +0100 | <EvanR> | f :: a is not a function |
| 2025-03-21 21:00:00 +0100 | <ski> | the type of a `getChar' expression is `IO Char', not `Char'. in C, the type of `getchar()' is `char'. so, in C, expressions of type char, when evaluated, may implicitly cause effects, on the *side* (not explicitly accounted for, in the interface of `getchar', being `int getchar(void);'). while in Haskell, evaluating `getChar' will not cause any effects, it will just compute a value of type `IO Char' (an |
| 2025-03-21 21:00:06 +0100 | <ski> | `IO'-action) for you. only by running/executing/invoking this value (this action), will you get an actual `Char' to work on |
| 2025-03-21 21:00:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-03-21 21:00:54 +0100 | <ski> | sim590 : all functions in Haskell take exactly one argument/parameter, have a type of the general shape `(...) -> (...)'. and all expressions of such type are functions, taking one input parameter/argument |
| 2025-03-21 21:00:55 +0100 | <sim590> | To me, this is a "constant function". It just doesn't have a parameter. Just like you we call `f(x) = 5` a function in Math. |
| 2025-03-21 21:01:11 +0100 | <ski> | if the type is not of the shape `(...) -> (...)', then it's not a function |
| 2025-03-21 21:01:44 +0100 | <sim590> | I guess f(x)=5 has a parameter, but it's just not used. Fine. |
| 2025-03-21 21:02:02 +0100 | <EvanR> | (\_ -> 5) :: () -> Int would be a function |
| 2025-03-21 21:02:16 +0100 | <EvanR> | x :: Int is not a function |
| 2025-03-21 21:02:19 +0100 | <EvanR> | big diff |
| 2025-03-21 21:02:47 +0100 | <EvanR> | 5 :: Int to be concrete |
| 2025-03-21 21:02:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 21:03:02 +0100 | <EvanR> | it's just a 5 |
| 2025-03-21 21:03:19 +0100 | <EvanR> | there's no argument or input to be had |
| 2025-03-21 21:03:46 +0100 | <EvanR> | you can "lambda wrap" any value you want to put another level of "function" around it though |
| 2025-03-21 21:03:50 +0100 | <EvanR> | might be what you were thinking |
| 2025-03-21 21:04:16 +0100 | <EvanR> | but while [5] or [[5]] are lists, 5 isn't a list |
| 2025-03-21 21:04:24 +0100 | <ski> | in Haskell, the effects of `getChar' and `putChar' are accounted for, explicitly, in the interfaces (type signatures), by the `IO' in `getChar :: IO Char' and `putChar :: Char -> IO ()' (and by `IO T' being a distinct type from `T', you can't implicitly treat a value of one as being a value of the other). this separation (which is similar in spirit to the old idea of "separate user interface from internal |
| 2025-03-21 21:04:31 +0100 | <ski> | machinery", but is enforced in Haskell) is what makes I/O effects explicit, not implicit, not on the side, not side-effects |
| 2025-03-21 21:04:31 +0100 | <sim590> | Who says that `getChar :: IO Char` is not actually `getChar :: () -> IO Char` behind the scene and therefore, `getChar` is a function! |
| 2025-03-21 21:04:43 +0100 | <EvanR> | :t getChar :: () -> IO Char |
| 2025-03-21 21:04:44 +0100 | <lambdabot> | error: |
| 2025-03-21 21:04:44 +0100 | <lambdabot> | • Couldn't match expected type ‘() -> IO Char’ |
| 2025-03-21 21:04:44 +0100 | <lambdabot> | with actual type ‘IO Char’ |
| 2025-03-21 21:04:48 +0100 | <EvanR> | the type checker said so |
| 2025-03-21 21:04:56 +0100 | <sim590> | That's what HE says. |
| 2025-03-21 21:05:11 +0100 | <sim590> | :D |
| 2025-03-21 21:05:34 +0100 | <EvanR> | just like 0 doesn't equal 1, () -> IO Char doesn't match IO Char |
| 2025-03-21 21:05:44 +0100 | <EvanR> | and if they did it would be bad |
| 2025-03-21 21:05:48 +0100 | <ski> | "behind the scene" or "under the (implementation covers)" doesn't matter. what matters is the interface presented to you, at the level of the language, what can be observed there, what reasoning laws you have available that preserve observable behaviour |
| 2025-03-21 21:06:09 +0100 | michalz | (~michalz@185.246.207.193) (Remote host closed the connection) |
| 2025-03-21 21:09:50 +0100 | <ski> | GHC happens to represent `IO Char' as something like `RealWorld -> (Char,RealWorld)', internally, but this is carefully set up, and easy to mess up (largely, but not only, because Haskell has no support for checking uniqueness, unlike Clean and Mercury. even if that was added, other aspects of `IO' (concurrency, exceptions, ..) is not accurately explicitly reflected here ..), internal representation (which, |
| 2025-03-21 21:09:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-21 21:09:56 +0100 | <ski> | if you'd fool around with it, would allow you to express side-effecting computations, yes). this should be treated as an internal implementation detail, which just happens to be expressed in an internal language which happens to *look* like Haskell, for convenience |
| 2025-03-21 21:10:33 +0100 | <ski> | and other Haskell implementations have internally represented `IO' in other ways (e.g. non-function ones, unlike the above) |
| 2025-03-21 21:11:05 +0100 | <EvanR> | the RealWorld -> implementation is weird and not particular helpful to using IO normally |
| 2025-03-21 21:11:18 +0100 | <ski> | yes |
| 2025-03-21 21:11:19 +0100 | <EvanR> | but I see it comes up in the guts of low level I/O stuff |
| 2025-03-21 21:12:19 +0100 | <ski> | sim590 : does this help ? |
| 2025-03-21 21:13:36 +0100 | <ski> | @quote /bin/ls |
| 2025-03-21 21:13:36 +0100 | <lambdabot> | shachaf says: getLine :: IO String contains a String in the same way that /bin/ls contains a list of files |
| 2025-03-21 21:13:37 +0100 | <sim590> | ski: by that logic, I could say that a function `f :: Int -> State Int Int` which returns the value of the state + its input would be unpure because from what I CAN SEE, when I call `runState (f 0 >> put 1 >> f 0) 0`, `f` returned `0+0=1` the first time, while it returned `1+0=1` the second time. So, from what I can tell from the signature, it was given the same argument, but returned something |
| 2025-03-21 21:13:39 +0100 | <sim590> | different both times, so `f` is impure. |
| 2025-03-21 21:15:15 +0100 | <ski> | "which returns the value of the state + its input" -- it does not do this. `f' returns a value that is a `State Int'-action. the function `f' does not "returns the value of the state + its input". *invoking*/running/executing/performing this resulting action, will yield as a result "the value of the state + its input", yes |
| 2025-03-21 21:16:13 +0100 | <ski> | i agree that if "which returns the value of the state + its input" was true, then it would be impure. but it doesn't do that, and so wouldn't need to be impure (and actually isn't) on these grounds |
| 2025-03-21 21:16:23 +0100 | forell | (~forell@user/forell) forell |
| 2025-03-21 21:18:18 +0100 | <ski> | "`f` returned `0+0=1` the first time, while it returned `1+0=1` the second time" -- no. `f' returned the same action (being a recipe expressing "yield zero added to the current state"), in both calls. but *executing*/invokking/running/performing this action, twoce, yields different results, in this situation |
| 2025-03-21 21:20:08 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) (Ping timeout: 272 seconds) |
| 2025-03-21 21:20:33 +0100 | <EvanR> | > let f n = put (n+1) >> return 0 in runState (f 0 >> put 1 >> f 0) 0 |
| 2025-03-21 21:20:35 +0100 | <lambdabot> | (0,1) |
| 2025-03-21 21:20:35 +0100 | <ski> | an action is a value, it is, on its own, just being, not peforming/doing/running/executing. only when an action is embedded in a larger action in a way that it'll get executed, when the larger one is, or when it's passed to a "run function" (like `runState') which executes the action, or (in the case of `IO') put as the definition of `main' (or entered into the interactor), does the action get executed |
| 2025-03-21 21:20:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 21:21:19 +0100 | <EvanR> | I didn't write f right |
| 2025-03-21 21:21:28 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-21 21:22:08 +0100 | <ski> | "it was given the same argument, but returned something different both times" -- no, for reasons i tried to explicate, above |
| 2025-03-21 21:22:09 +0100 | <EvanR> | > let f n = get >>= \s -> return (n+s) in runState (f 0 >> put 1 >> f 0) 0 |
| 2025-03-21 21:22:11 +0100 | <lambdabot> | (1,1) |
| 2025-03-21 21:22:16 +0100 | <EvanR> | > let f n = get >>= \s -> return (n+s) in runState (f 0 >> put 1 >> f 0) 0 |
| 2025-03-21 21:22:18 +0100 | <lambdabot> | (1,1) |
| 2025-03-21 21:22:28 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
| 2025-03-21 21:23:11 +0100 | <EvanR> | the f function is pure while the State action might be seen as "impure in context" |
| 2025-03-21 21:23:21 +0100 | <EvanR> | again the functions don't cause any effects |
| 2025-03-21 21:24:54 +0100 | <ski> | sim590 : you can think of a Haskell implementation as providing a run-time which consists of two main parts. (a) a part which evaluates expressions (typically lazily, but it only needs to be non-strict, so it's e.g. allowed to evaluate things ahead of time, speculatively, as long as some kind of time-out is used, and appropriate failure catching is applied, so that no behaviour difference can be noticed). |
| 2025-03-21 21:25:00 +0100 | <ski> | for `main :: IO T', this means evaluating "what Input/Output operations/interactions to perform" |
| 2025-03-21 21:25:17 +0100 | tabaqui | (~tabaqui@167.71.80.236) (Quit: WeeChat 4.5.2) |
| 2025-03-21 21:25:33 +0100 | <sim590> | EvanR: why would it be seen as impure? |
| 2025-03-21 21:25:39 +0100 | <sim590> | The state action. |
| 2025-03-21 21:25:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-21 21:25:55 +0100 | <ski> | sim590 : the other part being (b) an imperative interpreter, which inspects this the `main' recipe that we get by evaluating it, and actually performs the detailed I/O interactions |
| 2025-03-21 21:25:58 +0100 | <EvanR> | sim590, in context |
| 2025-03-21 21:26:09 +0100 | <sim590> | I don't get what that means. |
| 2025-03-21 21:26:24 +0100 | <ski> | in practice, though, (a) evaluation and (b) `IO' execution are interleaved processes |
| 2025-03-21 21:26:27 +0100 | <EvanR> | you could emulating being inside a stateful environment within the State program |
| 2025-03-21 21:26:40 +0100 | <EvanR> | even though you're not and it's just a trick |
| 2025-03-21 21:26:51 +0100 | <EvanR> | it just passes the state around |
| 2025-03-21 21:27:28 +0100 | <EvanR> | but when writing a State program you think of there being an ambient state (temporarily) |
| 2025-03-21 21:28:35 +0100 | <sim590> | Yes, you think "like" you benefit from a state, but it's actually just an abstraction. Like the previous signature of `f` was an abstraction for `f :: Int -> s -> (Int, s)`. |
| 2025-03-21 21:28:51 +0100 | <sim590> | I guess, `s :: Int`. |
| 2025-03-21 21:29:00 +0100 | <EvanR> | sure |
| 2025-03-21 21:29:31 +0100 | <EvanR> | all those functions have no state though regardless |
| 2025-03-21 21:30:03 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 21:30:20 +0100 | <sim590> | That's why it's easy for me to tell that State is not impure. But, for IO, it's a bit harder. And there was a awful lot amount of text I got from both of you and I didn't understand all the explanations when I was interleaving the read from one person's explanation with the other's. |
| 2025-03-21 21:30:37 +0100 | <EvanR> | well State action isn't a function |
| 2025-03-21 21:31:16 +0100 | <sim590> | I know, you made that point earlier. |
| 2025-03-21 21:31:26 +0100 | <EvanR> | so pure impure doesn't even apply |
| 2025-03-21 21:31:31 +0100 | <EvanR> | according to my definition |
| 2025-03-21 21:31:40 +0100 | <sim590> | I was talking about `f`. |
| 2025-03-21 21:31:42 +0100 | <sim590> | ... |
| 2025-03-21 21:31:58 +0100 | <EvanR> | f is a function, in Haskell, so it's pure |
| 2025-03-21 21:32:24 +0100 | <EvanR> | same as putChar |
| 2025-03-21 21:32:44 +0100 | <sim590> | That's a theorem of yours, but for now I'm only accepting the lemma about Monads such as State and others that are not IO. |
| 2025-03-21 21:32:47 +0100 | <EvanR> | or put :: s -> State a () |
| 2025-03-21 21:33:40 +0100 | <EvanR> | it's not even a monad thing |
| 2025-03-21 21:33:49 +0100 | <EvanR> | you can access State or IO using Applicative |
| 2025-03-21 21:33:59 +0100 | <sim590> | I know that this is a function-thing. |
| 2025-03-21 21:33:59 +0100 | <EvanR> | you can build programs that way |
| 2025-03-21 21:34:09 +0100 | <sim590> | But you can separate functions in subsets. |
| 2025-03-21 21:34:46 +0100 | <EvanR> | are you still thinking that some functions are not pure? The ones that return IO ? |
| 2025-03-21 21:35:04 +0100 | <sim590> | And I agree with the lemma that considers functions of the sets of all Haskell functions F minus the set of functions which have a return type `IO a` or `IO ()`. |
| 2025-03-21 21:35:21 +0100 | <EvanR> | I'll take that as a yes |
| 2025-03-21 21:36:07 +0100 | <sim590> | I would require to read something thourugh about it (not in a IRC chat where conversations are interleaving and hard to follow). Yet, I don't wish to read a scientific paper. Yet, I'd like it rigourous enough. |
| 2025-03-21 21:36:13 +0100 | <sim590> | If that resource exists? |
| 2025-03-21 21:36:27 +0100 | <EvanR> | you're making a mistake there, since A -> B and A -> IO () are the same kind of thing |
| 2025-03-21 21:36:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 21:36:42 +0100 | <EvanR> | just returning different types |
| 2025-03-21 21:36:58 +0100 | <EvanR> | same implementation behind the scenes |
| 2025-03-21 21:37:04 +0100 | <EvanR> | same lack of side effects |