| 2025-01-11 00:03:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 00:05:36 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 264 seconds) |
| 2025-01-11 00:06:14 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-11 00:06:30 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-11 00:07:12 +0100 | <euouae> | c_wraith: answer to what? |
| 2025-01-11 00:08:00 +0100 | <c_wraith> | how to enumerate rationals efficiently |
| 2025-01-11 00:08:14 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-01-11 00:11:25 +0100 | <euouae> | c_wraith: well a straightforward way is a simple generator formula that I extracted from that paper |
| 2025-01-11 00:11:44 +0100 | <euouae> | I'm not going for 100% efficiency in terms of flops and all that -- just an O(1) memory/time generating formula |
| 2025-01-11 00:13:02 +0100 | <euouae> | c_wraith: <https://termbin.com/barw> here's my Haskell code of that paper. `rats7` is the fast implementation and it only relies on `inverse` and `next`. |
| 2025-01-11 00:14:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 00:16:51 +0100 | <euouae> | not "fast". I should say "cheap" like O(1) memory/time |
| 2025-01-11 00:18:24 +0100 | <c_wraith> | ... to be clear, that's not O(1), because Rational isn't constant-space or constant-time |
| 2025-01-11 00:19:01 +0100 | <c_wraith> | But arbitrary-precision prevents those in general. It's not an issue with Rational. |
| 2025-01-11 00:19:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 00:20:23 +0100 | <euouae> | yes |
| 2025-01-11 00:20:56 +0100 | avdb13 | (~avdb13@2001-14ba-a0a9-f200--18c.rev.dnainternet.fi) |
| 2025-01-11 00:21:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 00:22:32 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Ping timeout: 265 seconds) |
| 2025-01-11 00:30:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 00:32:48 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-11 00:34:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 00:37:59 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Remote host closed the connection) |
| 2025-01-11 00:38:57 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-01-11 00:42:40 +0100 | euouae | (~euouae@user/euouae) (Ping timeout: 252 seconds) |
| 2025-01-11 00:45:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 00:46:27 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) (Ping timeout: 276 seconds) |
| 2025-01-11 00:52:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 00:54:41 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2025-01-11 00:59:10 +0100 | ahisho | (~ahisoooo@88.90.222.87.dynamic.jazztel.es) (Quit: Leaving) |
| 2025-01-11 01:10:45 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-11 01:12:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 01:16:13 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-11 01:16:16 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-01-11 01:16:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 01:23:16 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-01-11 01:23:49 +0100 | sprotte24 | (~sprotte24@p200300d16f053e002de39e6a7dd83ed5.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-11 01:24:42 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-11 01:27:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 01:31:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 01:42:07 +0100 | supercode | (~supercode@user/supercode) (Quit: Client closed) |
| 2025-01-11 01:42:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 01:43:52 +0100 | <EvanR> | "flops" to measure the efficiency of rational numbers |
| 2025-01-11 01:44:17 +0100 | <EvanR> | xD |
| 2025-01-11 01:44:54 +0100 | <EvanR> | one of these programming languages comes with rational number backed by ints instead of arbitrary precision |
| 2025-01-11 01:45:07 +0100 | <EvanR> | I guess this works about as well as "int" for representing integers |
| 2025-01-11 01:47:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 01:49:30 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-11 01:58:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 01:59:04 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-11 02:02:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 02:07:08 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-11 02:07:26 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Client Quit) |
| 2025-01-11 02:13:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 02:18:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 02:19:58 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-11 02:22:39 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-11 02:24:19 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-11 02:25:16 +0100 | <saulosilva> | Hello |
| 2025-01-11 02:28:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 02:33:13 +0100 | <geekosaur> | hi |
| 2025-01-11 02:35:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 02:35:40 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 02:38:31 +0100 | otto_s | (~user@p5de2f8cc.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2025-01-11 02:39:54 +0100 | otto_s | (~user@p5de2fce5.dip0.t-ipconnect.de) |
| 2025-01-11 02:40:07 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-11 02:46:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 02:48:44 +0100 | acidjnk | (~acidjnk@p200300d6e7283f46ed3dd32d3de732cf.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2025-01-11 02:49:00 +0100 | avdb13 | (~avdb13@2001-14ba-a0a9-f200--18c.rev.dnainternet.fi) (Ping timeout: 246 seconds) |
| 2025-01-11 02:50:20 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-11 02:50:52 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 02:51:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 02:52:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 02:56:11 +0100 | housemate | (~housemate@146.70.66.228) (Ping timeout: 252 seconds) |
| 2025-01-11 02:56:25 +0100 | housemate | (~housemate@pa49-183-118-117.pa.vic.optusnet.com.au) housemate |
| 2025-01-11 02:56:28 +0100 | housemate | (~housemate@pa49-183-118-117.pa.vic.optusnet.com.au) (Read error: Connection reset by peer) |
| 2025-01-11 02:57:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 02:57:48 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-01-11 03:01:03 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-11 03:03:42 +0100 | housemate_ | (~housemate@146.70.66.228) housemate |
| 2025-01-11 03:03:58 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 272 seconds) |
| 2025-01-11 03:05:12 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-11 03:12:42 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 276 seconds) |
| 2025-01-11 03:13:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 03:14:05 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-11 03:18:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 03:19:00 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-01-11 03:19:58 +0100 | housemate_ | (~housemate@146.70.66.228) (Quit: Nothing to see here. I wasn't there. I take IRC seriously. I do not work for any body DIRECTLY although I do represent BOT NET.) |
| 2025-01-11 03:21:15 +0100 | euouae | (~euouae@user/euouae) euouae |
| 2025-01-11 03:28:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 03:31:49 +0100 | dnerchm^ | (~dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-11 03:33:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 03:33:47 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.228) Jeanne-Kamikaze |
| 2025-01-11 03:38:17 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2025-01-11 03:44:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 03:45:16 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 252 seconds) |
| 2025-01-11 03:47:27 +0100 | euouae | (~euouae@user/euouae) (Remote host closed the connection) |
| 2025-01-11 03:48:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-11 03:59:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 04:05:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 04:05:13 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-11 04:06:16 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-01-11 04:16:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 04:19:48 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 04:22:42 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-11 04:22:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 04:23:43 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-01-11 04:32:26 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-11 04:32:45 +0100 | orangeFlu | (orangeFlu@gateway/vpn/protonvpn/orangeflu) orangeFlu |
| 2025-01-11 04:34:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 04:37:07 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 04:38:08 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 04:38:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 04:38:50 +0100 | ChanServ | +o litharge |
| 2025-01-11 04:38:51 +0100 | litharge | -bo *!*@user/rongwey litharge |
| 2025-01-11 04:40:31 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 04:41:22 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 04:49:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 04:50:50 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 04:51:50 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Quit: So long and thanks for all the fish) |
| 2025-01-11 04:52:19 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-01-11 04:54:04 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Excess Flood) |
| 2025-01-11 04:54:43 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-01-11 04:57:14 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Excess Flood) |
| 2025-01-11 04:57:55 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-01-11 04:58:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 05:05:16 +0100 | aforemny_ | (~aforemny@2001:9e8:6cc3:c600:66d6:598d:d25f:7909) aforemny |
| 2025-01-11 05:06:22 +0100 | aforemny | (~aforemny@i59F4C56A.versanet.de) (Ping timeout: 252 seconds) |
| 2025-01-11 05:09:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 05:10:37 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 244 seconds) |
| 2025-01-11 05:14:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-11 05:14:42 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-01-11 05:20:39 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-01-11 05:24:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 05:29:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 05:33:48 +0100 | olivial | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2025-01-11 05:34:03 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-01-11 05:40:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 05:40:39 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.228) (Quit: Leaving) |
| 2025-01-11 05:40:45 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Read error: Connection reset by peer) |
| 2025-01-11 05:41:01 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-11 05:44:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 05:51:12 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-01-11 05:55:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 05:55:48 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-11 06:02:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2025-01-11 06:07:21 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-01-11 06:07:27 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-11 06:12:56 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-01-11 06:13:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 06:17:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 06:28:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 06:31:33 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 248 seconds) |
| 2025-01-11 06:33:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 06:37:14 +0100 | Flow | (~none@gentoo/developer/flow) flow |
| 2025-01-11 06:44:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 06:48:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 06:53:45 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-11 06:55:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 06:59:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 07:01:54 +0100 | Me-me | (~me-me@user/me-me) (Remote host closed the connection) |
| 2025-01-11 07:04:32 +0100 | Me-me | (~me-me@user/me-me) Me-me |
| 2025-01-11 07:06:01 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 07:06:13 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 07:10:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 07:15:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 07:22:11 +0100 | housemate | (~housemate@146.70.66.228) (Quit: Nothing to see here. I wasn't there. I take IRC seriously. I do not work for any body DIRECTLY although I do represent BOT NET.) |
| 2025-01-11 07:25:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 07:27:07 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Remote host closed the connection) |
| 2025-01-11 07:30:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 07:39:01 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 07:39:57 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2025-01-11 07:39:57 +0100 | tnt2 | tnt1 |
| 2025-01-11 07:41:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 07:45:10 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:ea66:e6de:89d7:22da) (Ping timeout: 272 seconds) |
| 2025-01-11 07:48:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 07:53:21 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2025-01-11 07:56:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 08:00:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 08:00:45 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) JamesMowery |
| 2025-01-11 08:01:57 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:b02a:8bb0:8f4f:58a0) dtman34 |
| 2025-01-11 08:11:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 08:12:55 +0100 | CiaoSen | (~Jura@2a05:5800:2ef:f000:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-11 08:15:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 08:18:08 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 08:21:48 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2025-01-11 08:26:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 08:31:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 08:33:18 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-01-11 08:33:24 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2025-01-11 08:36:31 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-11 08:40:18 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Ping timeout: 276 seconds) |
| 2025-01-11 08:42:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 08:45:38 +0100 | orangeFlu | (orangeFlu@gateway/vpn/protonvpn/orangeflu) (Ping timeout: 252 seconds) |
| 2025-01-11 08:46:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 08:47:30 +0100 | orangeFlu | (~orangeFlu@240-100-179-143.ftth.glasoperator.nl) orangeFlu |
| 2025-01-11 08:57:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 09:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-11 09:00:38 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-11 09:02:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 09:03:34 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 265 seconds) |
| 2025-01-11 09:03:38 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-11 09:04:14 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 09:12:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 09:19:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 09:26:28 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-11 09:29:59 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 09:30:23 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 09:30:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 09:35:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 09:38:10 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-01-11 09:39:08 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 09:40:21 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 248 seconds) |
| 2025-01-11 09:41:27 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-11 09:42:28 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 09:45:31 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:b02a:8bb0:8f4f:58a0) (Ping timeout: 252 seconds) |
| 2025-01-11 09:45:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 09:46:06 +0100 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) dtman34 |
| 2025-01-11 09:46:57 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) |
| 2025-01-11 09:50:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 09:56:51 +0100 | housemate | (~housemate@146.70.66.228) (Read error: Connection reset by peer) |
| 2025-01-11 09:57:44 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 09:58:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 09:58:46 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-11 09:59:10 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-11 10:00:23 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-11 10:02:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 10:06:54 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-01-11 10:11:48 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 252 seconds) |
| 2025-01-11 10:13:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 10:14:54 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 10:16:33 +0100 | CiaoSen | (~Jura@2a05:5800:2ef:f000:ca4b:d6ff:fec1:99da) (Ping timeout: 265 seconds) |
| 2025-01-11 10:18:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 10:28:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 10:30:11 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-01-11 10:31:43 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2025-01-11 10:33:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 10:33:39 +0100 | hueso | (~root@user/hueso) hueso |
| 2025-01-11 10:44:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 10:45:15 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 10:49:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 10:49:39 +0100 | acidjnk | (~acidjnk@p200300d6e7283f9048e4a8ec3d592563.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 10:49:49 +0100 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) HarveyPwca |
| 2025-01-11 10:52:46 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-11 10:53:24 +0100 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) (Remote host closed the connection) |
| 2025-01-11 10:59:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 11:00:55 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-11 11:10:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 11:21:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 11:25:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 11:26:31 +0100 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) HarveyPwca |
| 2025-01-11 11:29:27 +0100 | acidjnk | (~acidjnk@p200300d6e7283f9048e4a8ec3d592563.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-01-11 11:30:36 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 276 seconds) |
| 2025-01-11 11:30:56 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-01-11 11:32:04 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-11 11:36:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 11:41:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 11:48:19 +0100 | <kaol> | I find <$>'s precedence awkward. I tend to write code like "f1 . f2 <$> g1 $ g2 x" which I'd expect to work like "f1 . f2 <$> g1 (g2 x)" and not "(f1 . f2 <$> g1) (g2 x)". |
| 2025-01-11 11:49:17 +0100 | <kaol> | I then write "fmap (f1 . f2) $ g1 $ g2 x" instead. |
| 2025-01-11 11:51:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 11:51:56 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-11 11:53:46 +0100 | CiaoSen | (~Jura@2a05:5800:2ef:f000:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-11 11:54:59 +0100 | <Rembane> | kaol: Super legit, you can also write (fmap (f1 . f2) . g1 . g2) x |
| 2025-01-11 11:56:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-11 12:08:42 +0100 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) (Quit: Leaving) |
| 2025-01-11 12:09:19 +0100 | <Leary> | kaol: The purpose of `$` is to be application that's a greedy as possible, by having the least precedence. If you have other expectations then you're misusing it. `g1 (g2 x)` and `(g1 . g2) x` are both cleaner options anyway. |
| 2025-01-11 12:11:09 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 12:11:17 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 248 seconds) |
| 2025-01-11 12:11:17 +0100 | tnt2 | tnt1 |
| 2025-01-11 12:14:41 +0100 | <kaol> | <$> is so similar to $ even down to the $ and I've gathered it's intentional except that's one thing where it isn't. |
| 2025-01-11 12:15:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 12:17:28 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) (Quit: β reduced) |
| 2025-01-11 12:17:55 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 12:18:21 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 12:19:50 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) |
| 2025-01-11 12:22:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 12:31:35 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Quit: Leaving) |
| 2025-01-11 12:32:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 12:37:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 12:42:15 +0100 | <kaol> | > let (€) = (*1.03) in (€) $ 1.0 |
| 2025-01-11 12:42:16 +0100 | <lambdabot> | 1.03 |
| 2025-01-11 12:43:20 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-11 12:48:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 12:52:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 12:54:10 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 12:54:37 +0100 | <[exa]> | kaol: wasn't there a library that literally allowed you to write "5 eur"? (via the usual typeclass trickery) |
| 2025-01-11 12:56:08 +0100 | <ncf> | > let (€) = (*1.03) in (1.0 €) |
| 2025-01-11 12:56:10 +0100 | <lambdabot> | 1.03 |
| 2025-01-11 12:59:26 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-11 12:59:27 +0100 | <tomsmeding> | the € symbol is written prefix |
| 2025-01-11 12:59:52 +0100 | <tomsmeding> | too bad that won't work with the syntax :p |
| 2025-01-11 12:59:53 +0100 | <[exa]> | not everywhere :( |
| 2025-01-11 13:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-11 13:00:24 +0100 | AlexNoo_ | (~AlexNoo@178.34.160.135) |
| 2025-01-11 13:00:28 +0100 | <tomsmeding> | TIL |
| 2025-01-11 13:00:51 +0100 | <haskellbridge> | <magic_rb> In slovakia its postfix yeah |
| 2025-01-11 13:01:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 13:01:34 +0100 | <haskellbridge> | <magic_rb> {-# LANGUAGE PrefixUnaryOperators #-} when |
| 2025-01-11 13:01:42 +0100 | <ncf> | isn't € suffixed in most places that actually use € |
| 2025-01-11 13:01:51 +0100 | <tomsmeding> | there aren't unary operators in the first place |
| 2025-01-11 13:01:53 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-11 13:02:01 +0100 | <haskellbridge> | <magic_rb> -10 is :) |
| 2025-01-11 13:02:14 +0100 | <tomsmeding> | ncf: apparently, and apparently NL is one of the few where it's written prefix |
| 2025-01-11 13:02:15 +0100 | <haskellbridge> | <magic_rb> So yea, first we need UnaryOperators |
| 2025-01-11 13:02:26 +0100 | <tomsmeding> | magic_rb: that one is built-in :p |
| 2025-01-11 13:02:34 +0100 | <haskellbridge> | <magic_rb> Ye ik :P |
| 2025-01-11 13:02:48 +0100 | <tomsmeding> | LexicalNegation is relevant |
| 2025-01-11 13:03:43 +0100 | <haskellbridge> | <magic_rb> Cant wait for (* 4 (+ 4 5)) to be valid haskell code |
| 2025-01-11 13:03:43 +0100 | <kaol> | I wrote it like that since I wanted to abuse $. |
| 2025-01-11 13:03:45 +0100 | AlexZenon | (~alzenon@94.233.240.147) (Ping timeout: 252 seconds) |
| 2025-01-11 13:03:52 +0100 | <kaol> | Even more. |
| 2025-01-11 13:04:04 +0100 | AlexNoo | (~AlexNoo@94.233.240.147) (Ping timeout: 252 seconds) |
| 2025-01-11 13:08:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 13:12:39 +0100 | AlexZenon | (~alzenon@178.34.160.135) |
| 2025-01-11 13:14:28 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 13:18:16 +0100 | mrmr155334346318 | (~mrmr@user/mrmr) mrmr |
| 2025-01-11 13:19:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 13:19:12 +0100 | housemate | (~housemate@146.70.66.228) (Read error: Connection reset by peer) |
| 2025-01-11 13:20:05 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-11 13:20:14 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 13:20:38 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 244 seconds) |
| 2025-01-11 13:20:45 +0100 | housemate | (~housemate@146.70.66.228) (Read error: Connection reset by peer) |
| 2025-01-11 13:21:29 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-11 13:24:20 +0100 | housemate | (~housemate@146.70.66.228) (Client Quit) |
| 2025-01-11 13:24:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 13:27:22 +0100 | pera | (~pera@user/pera) pera |
| 2025-01-11 13:31:49 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 248 seconds) |
| 2025-01-11 13:35:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 13:36:04 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-11 13:40:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 13:40:12 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-11 13:41:43 +0100 | FragByte_ | (~christian@user/fragbyte) FragByte |
| 2025-01-11 13:42:06 +0100 | FragByte | (~christian@user/fragbyte) (Ping timeout: 246 seconds) |
| 2025-01-11 13:42:06 +0100 | FragByte_ | FragByte |
| 2025-01-11 13:46:28 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 244 seconds) |
| 2025-01-11 13:47:35 +0100 | FragByte_ | (~christian@user/fragbyte) FragByte |
| 2025-01-11 13:48:14 +0100 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-11 13:48:32 +0100 | FragByte | (~christian@user/fragbyte) (Ping timeout: 244 seconds) |
| 2025-01-11 13:48:32 +0100 | FragByte_ | FragByte |
| 2025-01-11 13:50:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 13:51:22 +0100 | CiaoSen | (~Jura@2a05:5800:2ef:f000:ca4b:d6ff:fec1:99da) (Ping timeout: 252 seconds) |
| 2025-01-11 13:55:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 14:02:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 14:03:31 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2025-01-11 14:06:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 14:07:09 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 14:11:25 +0100 | jinsun_ | (~jinsun@user/jinsun) jinsun |
| 2025-01-11 14:11:25 +0100 | jinsun | Guest6442 |
| 2025-01-11 14:11:25 +0100 | jinsun_ | jinsun |
| 2025-01-11 14:14:28 +0100 | <zero> | > let (#) = succ in (6 #) |
| 2025-01-11 14:14:30 +0100 | <lambdabot> | 7 |
| 2025-01-11 14:15:00 +0100 | Guest6442 | (~jinsun@user/jinsun) (Ping timeout: 246 seconds) |
| 2025-01-11 14:17:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 14:18:47 +0100 | <tomsmeding> | % let (++) = succ in (6++) |
| 2025-01-11 14:18:47 +0100 | <yahb2> | 7 |
| 2025-01-11 14:19:29 +0100 | FragByte | (~christian@user/fragbyte) (Quit: Quit) |
| 2025-01-11 14:19:53 +0100 | <[exa]> | magic_rb: czechoslovak hi5 |
| 2025-01-11 14:20:14 +0100 | <zero> | zm |
| 2025-01-11 14:20:57 +0100 | <[exa]> | zero: ok wow cool |
| 2025-01-11 14:21:19 +0100 | FragByte | (~christian@user/fragbyte) FragByte |
| 2025-01-11 14:24:09 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 276 seconds) |
| 2025-01-11 14:26:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 14:26:56 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-11 14:28:22 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 14:33:41 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 14:37:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 14:41:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 14:43:05 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-11 14:43:07 +0100 | AlexZenon | (~alzenon@178.34.160.135) (Ping timeout: 252 seconds) |
| 2025-01-11 14:43:56 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-11 14:44:33 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-11 14:45:57 +0100 | AlexZenon | (~alzenon@178.34.160.135) |
| 2025-01-11 14:46:09 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-01-11 14:52:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 14:59:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 14:59:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 15:05:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 15:14:20 +0100 | AlexNoo_ | AlexNoo |
| 2025-01-11 15:16:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 15:17:40 +0100 | aforemny_ | (~aforemny@2001:9e8:6cc3:c600:66d6:598d:d25f:7909) (Ping timeout: 265 seconds) |
| 2025-01-11 15:23:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 15:23:28 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2025-01-11 15:28:48 +0100 | gentauro | (~gentauro@user/gentauro) gentauro |
| 2025-01-11 15:34:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 15:39:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 15:42:55 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-11 15:49:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 15:51:08 +0100 | califax_ | (~califax@user/califx) califx |
| 2025-01-11 15:51:12 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-01-11 15:52:21 +0100 | califax_ | califax |
| 2025-01-11 15:53:42 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-01-11 15:54:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-11 15:59:53 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Read error: Connection reset by peer) |
| 2025-01-11 16:05:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:08:06 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 16:09:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 16:14:04 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu |
| 2025-01-11 16:17:07 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Ping timeout: 244 seconds) |
| 2025-01-11 16:19:13 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-11 16:19:56 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2025-01-11 16:20:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:24:54 +0100 | <mreh> | trying to find some documentation on this bit of arrow syntax "proc ~pattern -> do" if anyone has a reference |
| 2025-01-11 16:25:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 16:26:12 +0100 | <mreh> | oh is it just a lazy pattern match? |
| 2025-01-11 16:26:39 +0100 | <haskellbridge> | <sm> So.. much.. syntax.. |
| 2025-01-11 16:33:13 +0100 | supercode | (~supercode@user/supercode) (Quit: Client closed) |
| 2025-01-11 16:33:37 +0100 | <mreh> | don't see them very often |
| 2025-01-11 16:36:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:37:03 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu |
| 2025-01-11 16:37:09 +0100 | <juri_> | is anyone else here a user of the 'repa' library? |
| 2025-01-11 16:37:27 +0100 | <juri_> | I don't have any questions yet, just looking for general opinions, as i wade in. |
| 2025-01-11 16:39:25 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-01-11 16:40:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 16:44:31 +0100 | <geekosaur> | yeh, that's just a lazy pattern match, and indeed they're not used often. but when you need them, you really need them |
| 2025-01-11 16:45:18 +0100 | <geekosaur> | there are other ways to do it (they're syntax sugar for an irrefutable match and a later lambda) but the lazy pattern match syntax is so much cleaner |
| 2025-01-11 16:45:21 +0100 | <mreh> | This page was pretty clear https://wiki.haskell.org/Lazy_pattern_match |
| 2025-01-11 16:46:34 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-01-11 16:49:50 +0100 | <mreh> | I'm still not entirely clear how it applies to the arrow syntax though |
| 2025-01-11 16:50:05 +0100 | <mreh> | these arrows aren't functions |
| 2025-01-11 16:51:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:52:17 +0100 | <mreh> | e.g. https://github.com/tobbebex/GPipe-Core/blob/4f512f1ea6e6c32bbefaae1be38a68508337b1fa/GPipe-Core/sr… |
| 2025-01-11 16:52:55 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-11 16:58:18 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2025-01-11 16:59:58 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 17:02:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 17:14:13 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Read error: Connection reset by peer) |
| 2025-01-11 17:17:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:21:00 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-11 17:22:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 17:23:04 +0100 | <haskellbridge> | <loonycyborg> What is the proper way to trigger TypeError from a type family? If I just try to return TypeError as a type ghc says that undecidable instances would be required. |
| 2025-01-11 17:26:00 +0100 | <geekosaur> | that's not wrong, it follows normal rules and kinda by definition doesn't actually solve any types, so by said normal rules would normally lead to an infinite loop in the typechecker (except that it catches that specifically and aborts) |
| 2025-01-11 17:27:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 17:29:09 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-01-11 17:29:14 +0100 | michalz | (~michalz@185.246.207.218) |
| 2025-01-11 17:30:14 +0100 | <geekosaur> | one could argue that the loop checker that gets disabled with `UndecidableInstances` should recognize `TypeError` but I wonder how much extra work that would be |
| 2025-01-11 17:30:35 +0100 | Digit | (~user@user/digit) (Ping timeout: 265 seconds) |
| 2025-01-11 17:32:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:33:39 +0100 | <haskellbridge> | <loonycyborg> Are there more granular ways of enabling Undecidable instances than module-wide? |
| 2025-01-11 17:35:56 +0100 | <geekosaur> | no, and I suspect it would be problematic |
| 2025-01-11 17:35:58 +0100 | <int-e> | I don't think so. (It's essentially a syntactic check... there's no change to how type checking operates outside of checking instance heads.) |
| 2025-01-11 17:36:31 +0100 | <haskellbridge> | <loonycyborg> seems I can't fool it by attaching TypeError to Proxy or using it in Tagged |
| 2025-01-11 17:37:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 17:39:59 +0100 | <int-e> | I personally never worry about enabling UndecidableInstances. |
| 2025-01-11 17:40:23 +0100 | <kaol> | Dr. Strangelove and |
| 2025-01-11 17:41:31 +0100 | Digitteknohippie | Digit |
| 2025-01-11 17:41:39 +0100 | <int-e> | It's really not so bad... the compiler can fail to terminate (in reasonable time!) for all sorts of reasons. |
| 2025-01-11 17:41:48 +0100 | <int-e> | There are no fireworks. |
| 2025-01-11 17:41:56 +0100 | <monochrom> | how I stopped worrying and love strange loops |
| 2025-01-11 17:43:00 +0100 | <monochrom> | no fireworks? wait til your computer overheats :) |
| 2025-01-11 17:43:24 +0100 | <kaol> | My experience with UndecidableInstances is that it can make code compile but it may paper over a design issue that will explode when you try to generalise the code more. |
| 2025-01-11 17:44:01 +0100 | <kaol> | Or rather, try to add more instances of whatever you make one first. |
| 2025-01-11 17:44:24 +0100 | <int-e> | odd |
| 2025-01-11 17:45:12 +0100 | <int-e> | The scary extensions start with OverlappingInstances (which is a slippery slope leading towards IncoherentInstances which is the actually scary one) |
| 2025-01-11 17:45:45 +0100 | <kaol> | It was a while ago, may have been some other IncomprehensibleExtension. |
| 2025-01-11 17:46:03 +0100 | <hellwolf> | Per instance declaration of undecidable/ambiguous instances seem a recurring question, and it has open issues tracking it I believe |
| 2025-01-11 17:46:04 +0100 | <int-e> | But I guess you can inadvertently make type checking expensive and UndecidableInstances makes that more likely. |
| 2025-01-11 17:46:37 +0100 | <int-e> | We have dedicated per-instance pragmas for overlapping instances. |
| 2025-01-11 17:46:42 +0100 | <geekosaur> | UndecidableInstances just says "don't exclude entirely valid programs because they can't be proven to terminate at type level" |
| 2025-01-11 17:47:04 +0100 | <int-e> | Which makes sense, since that actually affects type-checking for users of those instances. |
| 2025-01-11 17:47:18 +0100 | <kaol> | Sorry, I may not be adding anything to the discussion and it was very likely some other extension. |
| 2025-01-11 17:47:19 +0100 | <int-e> | So the finer granularity bears fruits. |
| 2025-01-11 17:47:27 +0100 | <geekosaur> | I think there are other limits to prevent things getting too out of hand? "let it loop" vs. "too many loops" |
| 2025-01-11 17:48:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:48:17 +0100 | <hellwolf> | that's UndecidableSuperClasses ? |
| 2025-01-11 17:48:56 +0100 | <kaol> | I mainly just write Haskell and add extensions when GHC tells me to. It seems weird but it works. |
| 2025-01-11 17:49:06 +0100 | <geekosaur> | that's anything that can lead to looping, from type level to Core-Core passes |
| 2025-01-11 17:50:12 +0100 | <hellwolf> | Though, at numerous times I could eventually eliminate the usage of UndecidableInstances; if it were used more freely, like what I do with ambiguous types, I might not pay the necessary attention to simplify things when there is opportunity of doing so. |
| 2025-01-11 17:50:57 +0100 | <hellwolf> | that's why I would hope there is per instance declaration for them, that makes it more tamed. |
| 2025-01-11 17:51:15 +0100 | <hellwolf> | I could be irrational though, as people pointing out that it should not be feared as much. |
| 2025-01-11 17:52:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 17:55:19 +0100 | <int-e> | It certainly could be a per class thing but I don't think the demand for that is high. The extension is mostly harmless. |
| 2025-01-11 17:56:32 +0100 | rynite | (~bwkam@user/rynite) rynite |
| 2025-01-11 17:57:27 +0100 | <hellwolf> | As this discussion usually lead to, that assessment of "harmless" is very inaccessible to all walks of Haskellers. I don't think it would be surprising that many are deterred by such an extension, and some might still think it's dangerous. |
| 2025-01-11 17:58:06 +0100 | <hellwolf> | So, works still needed to clarify this. But we are repeating here... each time this topic brought up, it is the same dicussion :) |
| 2025-01-11 17:58:54 +0100 | <int-e> | https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Mostly_Harmless |
| 2025-01-11 18:00:53 +0100 | <monochrom> | IMO the conflicting experiences are due to conflicting understandings of, for example, what "instance Ord a => Eq a" means. One of the two understandings, the more popular one, is wrong, and it also leads you to misuse UndecidableInstances, and it still won't do what you think. |
| 2025-01-11 18:00:54 +0100 | <int-e> | hellwolf: Literally the only thing that UndecidableInstances does is turn off the "The constraint ... is no smaller than the instance head ..." error. |
| 2025-01-11 18:01:28 +0100 | <hellwolf> | I sorta understand. But not everyone is off type theory background to understand its implication... |
| 2025-01-11 18:01:56 +0100 | <monochrom> | Whereas if you have the correct understanding, then you will find that, e.g., Data Types a la Carte needs UndecidableInstances and it is a correct use. |
| 2025-01-11 18:03:06 +0100 | <c_wraith> | There are a lot of shapes of recursive data type that just need UndecidableInstances to write *any* instance for. |
| 2025-01-11 18:03:17 +0100 | <hellwolf> | I think maybe we could even move it to a GHC warning, and GHC warning can be turned off per definition iirc. |
| 2025-01-11 18:03:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:03:36 +0100 | <int-e> | Which is a check that I guess will save some beginners from doing certain stupid things. But in practice the implemented termination check is woefully naive and excludes a lot of instances where type checking terminates just fine. |
| 2025-01-11 18:04:25 +0100 | <int-e> | Also accidental compile-time non-termination is far less scary than accidental runtime non-termination. |
| 2025-01-11 18:08:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 18:10:33 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2025-01-11 18:17:34 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-11 18:18:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:23:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-11 18:24:00 +0100 | sim590 | (~simon@24-122-69-233.resi.cgocable.ca) (Ping timeout: 276 seconds) |
| 2025-01-11 18:25:52 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 18:26:46 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 18:30:12 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-01-11 18:30:40 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-01-11 18:32:06 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-01-11 18:34:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:34:59 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 18:38:14 +0100 | rynite | (~bwkam@user/rynite) (Quit: WeeChat 4.4.1) |
| 2025-01-11 18:41:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 18:46:16 +0100 | <haskellbridge> | <Jade> hellwolf @irc_libera.chat_hellwolf:kf8nh.com: we don't have scoped warning enable/disable yet, there's a ticket which has been open for quite some time |
| 2025-01-11 18:50:13 +0100 | <bailsman> | I have a record full of IORefs and IOVectors. I would like to make a function that can make a frozen copy of it - having essentially the same type but all the IORefs replaced by the underlying and all the IOVectors replaced by frozen vectors. Is this something I can do with generics? Write "deriving freezable" or something like this and get a freeze that works on any such mutable record? Is this |
| 2025-01-11 18:50:14 +0100 | <bailsman> | an insane thing to want? (I'm discouraged by the fact that it does not seem to already exist) |
| 2025-01-11 18:52:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:57:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 18:58:54 +0100 | <hellwolf> | Jade: good to know! |
| 2025-01-11 18:59:18 +0100 | <hellwolf> | bailsman: code smells. just an instinct. others may have a better picture what's going on for you. |
| 2025-01-11 19:04:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:04:26 +0100 | <bailsman> | hellwolf: I'm not sure what you mean. Are you agreeing with me that it seems like it's an insane thing to want? |
| 2025-01-11 19:05:16 +0100 | <hellwolf> | a little. would you clarify what does "freeze" mean in your context? |
| 2025-01-11 19:08:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 19:11:34 +0100 | <bailsman> | turn IORef a into a, and IOVector a into Vector a. BTW, google has now taught me the word "type family" |
| 2025-01-11 19:12:04 +0100 | geekosaur | thinks this sounds just a bit like zonking. is something ghc's typechecker does a code smell? 😛 |
| 2025-01-11 19:14:17 +0100 | <bailsman> | I want to automatically (recursively) freeze all the fields of my record without writing any boilerplate. Primarily because I want to then serialize it to JSON. |
| 2025-01-11 19:15:03 +0100 | <bailsman> | It feels like it shouldn't be too difficult to make this work generically in principle, but the fact that there doesn't already exist a function that does this make me pause. |
| 2025-01-11 19:15:29 +0100 | <geekosaur> | tbh if that's all you're doing, I wouldn't bother freezing first. if you plan to do other things with it afterward then maybe it's worthwhile |
| 2025-01-11 19:15:47 +0100 | <haskellbridge> | <magic_rb> Its definitely possible, easy to do? No |
| 2025-01-11 19:16:11 +0100 | <geekosaur> | (the cost of doing the replacements would be higher than the cost of traversing the non-frozen version to make JSON) |
| 2025-01-11 19:16:12 +0100 | <bailsman> | Huh? but I can't directly serialize a io vector. For one thing, it requires IO to read, no? |
| 2025-01-11 19:16:49 +0100 | <bailsman> | I thought I was going to need to freeze it to be able to make it serializable |
| 2025-01-11 19:16:49 +0100 | <geekosaur> | or use unsafeIOtoST 🙂 |
| 2025-01-11 19:17:17 +0100 | <bailsman> | ...I see. Why is that unsafe? Or is that perfectly safe. |
| 2025-01-11 19:17:26 +0100 | <geekosaur> | well, I am assuming you're not going to use an autogenerated serialization. but again the question comes down to, which one costs more? |
| 2025-01-11 19:17:34 +0100 | <geekosaur> | it's usually perfectly safe |
| 2025-01-11 19:17:35 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-11 19:17:50 +0100 | <bailsman> | I was hoping I'd just write one "deriving" thing and the rest would magically work |
| 2025-01-11 19:17:54 +0100 | <geekosaur> | there are ways to get unsafeCoerce from it, but most things are fine |
| 2025-01-11 19:18:02 +0100 | <bailsman> | instead of writing a custom ToJSON instance or something |
| 2025-01-11 19:18:41 +0100 | <bailsman> | A vector is just a list after all. And there are already ToJSON instances for vectors. |
| 2025-01-11 19:18:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:18:54 +0100 | <geekosaur> | okay, the problem is you'll be going through not one but two Generic-based traversals, and Generics is pretty expensive (it's optimized for generation by the compiler, at the cost of lousy runtime performance) |
| 2025-01-11 19:19:30 +0100 | <bailsman> | Yes, exactly. I'm terrified about compile times (template haskell makes compilation take like tens of seconds longer) and I don't care at all about how fast this is at runtime, it's mostly a debugging thing that will run maybe once. |
| 2025-01-11 19:19:35 +0100 | <geekosaur> | one for your removal of IO, the other for the ToJSON instance which is probably via Generics unless you're writing it by hand |
| 2025-01-11 19:21:05 +0100 | <bailsman> | I'm using generics for everything already. To make my records storable, and whenever I access record fields, for example. I didn't know it was slow at runtime. Oops. (I hadn't noticed yet, so I guess its good enough) |
| 2025-01-11 19:21:14 +0100 | <bailsman> | Generating lenses with template haskell just completely destroys my compilation speeds |
| 2025-01-11 19:21:50 +0100 | <geekosaur> | mm. my take on that is that I usually compile a few times and run many times, so runtime performance matters to me more |
| 2025-01-11 19:22:05 +0100 | <geekosaur> | but I'm from the 80s, you kids think a few extra seconds is slow 🙂 |
| 2025-01-11 19:22:19 +0100 | <bailsman> | yes waiting 10 seconds for it to compile is unacceptable, waiting an extra nanosecond at runtime is fine |
| 2025-01-11 19:22:25 +0100 | <bailsman> | Someone should make generics fast btw, they're very useful |
| 2025-01-11 19:22:39 +0100 | <geekosaur> | they did, you just don't get them from ghc |
| 2025-01-11 19:23:29 +0100 | <bailsman> | Why isn't it a zero cost abstraction? What acceptable happens if I use generics everywhere? |
| 2025-01-11 19:23:33 +0100 | <bailsman> | actually* |
| 2025-01-11 19:23:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 19:23:59 +0100 | <bailsman> | Right now I'm having generics generate "setField" and "getField" for me so I can use overloadedrecordupdate |
| 2025-01-11 19:24:05 +0100 | <bailsman> | so basically whenever I update a field I'm going through generics |
| 2025-01-11 19:24:27 +0100 | <haskellbridge> | <magic_rb> geekosaur its not just you, im 20 and i dont think 20 seconds to compile is that bad. Gives me time to take a break, relax, plan my next move |
| 2025-01-11 19:24:54 +0100 | <geekosaur> | uniplate, syb, generics-sop |
| 2025-01-11 19:25:01 +0100 | <bailsman> | Programmeer feedback loops should be measured in milliseconds, not seconds. 20 seconds to compile is completely unacceptable. |
| 2025-01-11 19:25:20 +0100 | <geekosaur> | yeh, but my context is expecting 5 minutes to compile, what's 20 seconds? |
| 2025-01-11 19:25:34 +0100 | <bailsman> | You're probably using template haskell :P |
| 2025-01-11 19:25:53 +0100 | <haskellbridge> | <maerwald> bailsman: Well, one can dream |
| 2025-01-11 19:26:05 +0100 | <haskellbridge> | <magic_rb> I cant even comprehend i compiled within 20 miliseconds :) let alone figure out what to do next |
| 2025-01-11 19:27:27 +0100 | <geekosaur> | sop offers TH support but I think doesn't depend on it |
| 2025-01-11 19:27:43 +0100 | <bailsman> | Anyway what's the actual runtime cost of GHC.Generics? How does it work? Is this documented anywhere? I was overjoyed that it all just worked automatically as soon as I imported generic-lens and started putting deriving Generic on all my records. |
| 2025-01-11 19:28:17 +0100 | <geekosaur> | although I guess if you want automated deriving of instances it's TH, GHC.Gnenerics, or compiler plugins (not that I know any implementations that use the latter) |
| 2025-01-11 19:28:40 +0100 | <geekosaur> | GHC.Generics is documented in its haddock |
| 2025-01-11 19:29:10 +0100 | <bailsman> | It describes how to use it, not how expensive it is to use at runtime |
| 2025-01-11 19:29:16 +0100 | <bailsman> | I thought it all happened at compile time BTW |
| 2025-01-11 19:29:35 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-01-11 19:30:29 +0100 | <geekosaur> | compile time creates the data structures representing the structure of a value, runtime traverses them to actually do things with those values (such as serialize to JSON) |
| 2025-01-11 19:31:16 +0100 | <bailsman> | but why isn't this "as if" i manually defined those derived instances? Isn't the compiler perfectly capable of optimizing the original out? |
| 2025-01-11 19:31:29 +0100 | <geekosaur> | the compiler does not generate the serialize-to-JSON code, a default typeclass method for the ToJSON typeclass implements that at runtime |
| 2025-01-11 19:32:34 +0100 | <bailsman> | And the same happens to getField and setField? Those go and figure out the actual field to use at runtime based on the generic representation of my type? And this doesn't get inlined and optimized away? |
| 2025-01-11 19:32:36 +0100 | <geekosaur> | it's not, no. generation of the Generic representation of a type is entirely separate from consumption and may be spread over both space and time |
| 2025-01-11 19:33:10 +0100 | _73 | (~user@pool-173-76-100-193.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-01-11 19:33:18 +0100 | <geekosaur> | (the same Gneric rep is used for anything that consumes a Generic instance for whatever reason; that "whatever reason" is typically per typeclass) |
| 2025-01-11 19:33:41 +0100 | <bailsman> | I can kind of see why toJSON wouldn't work. Because it's probably too clever to optimize out |
| 2025-01-11 19:33:47 +0100 | <bailsman> | but getField and setField I would have expected to be zero cost |
| 2025-01-11 19:34:37 +0100 | <geekosaur> | my understanding, as I said earlier, is that generation and consumption of Generic representations are too separated to be optimized |
| 2025-01-11 19:35:18 +0100 | <bailsman> | In theory you could annotate them right? With the actual original type? Although it would require you to add a special optimization pass for generics. |
| 2025-01-11 19:35:53 +0100 | <geekosaur> | on the one hand, enough people don't care that GHC.Generics is still widely used; on the other, enough people do care that SYB, Uniplate, generics-sop, and another that I'm not finding quickly and never remember the name of are also widely used |
| 2025-01-11 19:36:10 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-11 19:36:17 +0100 | <probie> | If you want to know about the performance penalty (if any), you might be able to answer the question by making GHC to spit out the core and seeing what it looks like |
| 2025-01-11 19:36:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:37:10 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2025-01-11 19:37:33 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-11 19:38:11 +0100 | <geekosaur> | (SYB predates GHC generics and is still going strong) |
| 2025-01-11 19:38:30 +0100 | <bailsman> | Back when I was profiling this, using Generic, derive-storable and storable vectors was like 100x faster than either normal Haskell lists (pure) or boxed mutable vectors. Although that was kind of a micro benchmark and my code has grown somewhat. Haven't checked if it still holds now. I also didn't study the core output in detail. |
| 2025-01-11 19:39:08 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-11 19:40:33 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 19:40:49 +0100 | pera | (~pera@user/pera) (Ping timeout: 248 seconds) |
| 2025-01-11 19:40:53 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) rekahsoft |
| 2025-01-11 19:41:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 19:42:32 +0100 | pera | (~pera@user/pera) pera |
| 2025-01-11 19:42:38 +0100 | pera | (~pera@user/pera) (Client Quit) |
| 2025-01-11 19:43:32 +0100 | <bailsman> | Correction, only 10x |
| 2025-01-11 19:44:02 +0100 | <bailsman> | well, 10x faster than pure lists, 50x faster than boxed mutable vectors (unspecialized) |
| 2025-01-11 19:44:42 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 246 seconds) |
| 2025-01-11 19:44:49 +0100 | <geekosaur> | doesn't take much to be faster than lists |
| 2025-01-11 19:45:06 +0100 | <bailsman> | I don't understand, if it's going through some generic indirection, I'd expect that to be about as slow as boxed vectors. I thought what made those slow was the indirection |
| 2025-01-11 19:45:09 +0100 | <geekosaur> | consecutive memory locations are always going to be faster than lots of pointer chasing |
| 2025-01-11 19:45:19 +0100 | <bailsman> | But why doesn't the generic layer cause pointer chasing? |
| 2025-01-11 19:45:28 +0100 | cheater_ | (~Username@user/cheater) cheater |
| 2025-01-11 19:45:29 +0100 | <bailsman> | If it's runtime as you say |
| 2025-01-11 19:45:41 +0100 | <geekosaur> | you said storable vectors |
| 2025-01-11 19:45:56 +0100 | <geekosaur> | there's no reason to chase pointers in that case, all elements are laid out next to each other |
| 2025-01-11 19:45:59 +0100 | <bailsman> | made storable with "instance GStorable myrecord" |
| 2025-01-11 19:46:07 +0100 | <bailsman> | in one line |
| 2025-01-11 19:46:36 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 19:46:38 +0100 | <geekosaur> | I, uh, think we're not communicating |
| 2025-01-11 19:46:46 +0100 | <geekosaur> | I thought I explained that already |
| 2025-01-11 19:46:49 +0100 | stef204 | (~stef204@user/stef204) stef204 |
| 2025-01-11 19:46:58 +0100 | <bailsman> | no you're communicating, I'm just missing a lot of stuff because I'm new |
| 2025-01-11 19:47:46 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2025-01-11 19:47:53 +0100 | cheater_ | cheater |
| 2025-01-11 19:48:05 +0100 | <geekosaur> | in the case of lists vs. GStorable: you convert once, you do possibly many accesses afterward. if you go directly via pure lists you're dereferencing pointers to values, then pointers to the next list cell, then pointer to its value, etc. |
| 2025-01-11 19:48:30 +0100 | <geekosaur> | but the result of GStorable is everything next to each other. |
| 2025-01-11 19:49:33 +0100 | <geekosaur> | this may end up being equal cost, if there's a single iteration, because making the `Storable` does the same list traversal unless you were starting from a vector to begin with (in which case there is no point in comparing these because vectors will always beat lists) |
| 2025-01-11 19:49:41 +0100 | <bailsman> | OK I think I get it. What is going through the generic layer is "how do I lay this out in memory?" but the data access does not go through that layer in this case. |
| 2025-01-11 19:49:54 +0100 | <geekosaur> | right |
| 2025-01-11 19:50:38 +0100 | <bailsman> | but if I use a generically derived "setField" it would go indirect? (let me try to figure out how to dump the core output for such a field access) |
| 2025-01-11 19:51:12 +0100 | <geekosaur> | setField I'm not sure of. if it's only done once instead of once per use it probably ends up being a win depending on how often it's used |
| 2025-01-11 19:51:21 +0100 | <geekosaur> | (creation cost is amortized over the uses) |
| 2025-01-11 19:51:59 +0100 | <geekosaur> | if it has to "re-derive" the setField at runtime for every use, you could be very unhappy. I haven't delved into generics deeply enough to know how smart that part is |
| 2025-01-11 19:52:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:52:14 +0100 | <geekosaur> | (most of my programming doesn't benefot from generics_ |
| 2025-01-11 19:52:18 +0100 | <geekosaur> | ) |
| 2025-01-11 19:52:44 +0100 | <geekosaur> | but from what I know of ghc generics I think if I needed them I'd eat the cost of TH and use generics-sop instead |
| 2025-01-11 19:53:22 +0100 | <geekosaur> | maybe if it really mattered I'd consider writing a compiler plugin to replace the TH, I think you can add new "default deriving" mechanisms that way |
| 2025-01-11 19:53:28 +0100 | <c_wraith> | ghc generics are something I've still never learned the how or why of. |
| 2025-01-11 19:53:35 +0100 | <geekosaur> | `deriving stock` that is |
| 2025-01-11 19:54:00 +0100 | <bailsman> | Anyway my experience with generics has been very positive. generic-lens, derive-storable etc, its one line and it just works TM. That's why I figured maybe I can make my data types serializable in one line too |
| 2025-01-11 19:54:02 +0100 | <c_wraith> | It turns out you can just ignore generics for nearly everything you do! |
| 2025-01-11 19:54:42 +0100 | <bailsman> | And the best part is it still compiles instantly, unlike template haskell, which is an abomination that should be scoured from the earth. |
| 2025-01-11 19:54:57 +0100 | <c_wraith> | template haskell is a lot faster than it used to be in the 8.x and earlier days |
| 2025-01-11 19:55:06 +0100 | <geekosaur> | I know the why, I just don't need them. I looked into how they work only because someone at one point tossed out the thing about GHC generics being a lousy implementation of sums-of-products |
| 2025-01-11 19:55:08 +0100 | <bailsman> | It literally goes from compiling instantly to taking 20+ seconds every time. |
| 2025-01-11 19:55:19 +0100 | <c_wraith> | ... yeah, TH isn't that slow anymore |
| 2025-01-11 19:55:25 +0100 | <c_wraith> | it definitely used to be |
| 2025-01-11 19:55:31 +0100 | <bailsman> | What do you mean anymore? |
| 2025-01-11 19:55:35 +0100 | <bailsman> | that's with GHC 9.13 |
| 2025-01-11 19:55:40 +0100 | <geekosaur> | I'm afraid to ask what you're doing that takes 20 seconds |
| 2025-01-11 19:55:49 +0100 | <bailsman> | Just deriving lenses |
| 2025-01-11 19:55:53 +0100 | <c_wraith> | I mean they fixed the "starting an interpreter takes 10 seconds of flat overhead" thing. |
| 2025-01-11 19:56:08 +0100 | <c_wraith> | Oh, I'd never derive lenses. Just write them by hand. They're like 2 lines each. |
| 2025-01-11 19:56:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 19:56:40 +0100 | <bailsman> | I'm not using lenses anymore either. I like overloadedrecordupdate better |
| 2025-01-11 19:56:44 +0100 | <EvanR> | python script to write all your lenses for you xD |
| 2025-01-11 19:56:46 +0100 | <bailsman> | but that still requires generics |
| 2025-01-11 19:59:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 246 seconds) |
| 2025-01-11 19:59:28 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-01-11 20:05:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 20:05:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-11 20:06:10 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-01-11 20:06:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 20:06:51 +0100 | <monochrom> | The GHC.Generics route has a linear-time runtime cost (to and from clones your input), whereas the TH route generates direct code that skips that. To be sure, I am lazy so I just use the generics route and not care about performance. :) |
| 2025-01-11 20:08:10 +0100 | <monochrom> | If someone else has already written the TH version, of course you can just use it and do nothing. But if no one has written either version and you have to write one yourself, the generics route is easier to write. |
| 2025-01-11 20:10:35 +0100 | <EvanR> | haskell script to generate haskell |
| 2025-01-11 20:10:43 +0100 | <bailsman> | OK I checked -ddump-simpl output, comparing -O0 and -O2. In -O0, there is "setField" all over the place. In -O2, there's no setField calls anywhere. Can I conclude these are actually getting optimized out, despite being generic? |
| 2025-01-11 20:10:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 20:11:02 +0100 | sprotte24 | (~sprotte24@p200300d16f109200d837c3a3f02cbb16.dip0.t-ipconnect.de) |
| 2025-01-11 20:11:32 +0100 | <haskellbridge> | <Bowuigi> They might be inlined but still there |
| 2025-01-11 20:12:02 +0100 | <haskellbridge> | <Bowuigi> Check for calls to the generic methods instead |
| 2025-01-11 20:12:07 +0100 | <c_wraith> | why not -O1? that's the most relevant level |
| 2025-01-11 20:12:08 +0100 | <monochrom> | Yeah the -O0 code is also suspiciously much shorter. >:) |
| 2025-01-11 20:12:46 +0100 | <c_wraith> | (most code is compiled at -O1, as it's the default and hackage even warns you about uploading -O2) |
| 2025-01-11 20:12:53 +0100 | <monochrom> | And yeah, actually ghc : 1 : 2 :: gcc : 2 : 3 |
| 2025-01-11 20:13:35 +0100 | <bailsman> | BEcause when I did my microbenchmarks with the storable vectors -O2 was much much faster, I believe because it was specializing better |
| 2025-01-11 20:13:48 +0100 | <bailsman> | I don't actually really know what the difference is. |
| 2025-01-11 20:14:37 +0100 | <monochrom> | OK vector is one of the few exceptions where O2 is necessary. |
| 2025-01-11 20:16:11 +0100 | <monochrom> | I haven't seen an example, but it is said that O2 can be slower than O1 for some code, hence I analogize it to gcc's O3. |
| 2025-01-11 20:16:33 +0100 | <bailsman> | so far as I can understand - I'm not an expert in reading the simpl output - it has entirely optimized out my setfield calls to just creating a new record passing in values from the original values by direct field access and/or the values that I passed in, which seems optimal. No mention of generic anything. |
| 2025-01-11 20:17:11 +0100 | <haskellbridge> | <Bowuigi> Interesting, GHC is actually very smart |
| 2025-01-11 20:19:41 +0100 | <monochrom> | My favourite example is https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107775.html and it's already last decade. Imagine what it can do today. :) |
| 2025-01-11 20:20:45 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 20:20:49 +0100 | <darkling> | Needle nardle noo. |
| 2025-01-11 20:21:40 +0100 | <monochrom> | There is a fairly general scheme where if you have "case m of Just z -> ... case m of Just z again -> ..." the 2nd conditional branching can be eliminated. |
| 2025-01-11 20:21:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 20:22:37 +0100 | <monochrom> | And there is also one where if you have "case (case y of x:_ -> Just x) of Just z -> foo" the middle Just can also be eliminated. |
| 2025-01-11 20:23:31 +0100 | <monochrom> | The vector library's stream fusion actually relies on that fundamentally. |
| 2025-01-11 20:24:47 +0100 | <c_wraith> | lens also depends on case-of-case to be efficient without tons of rewrite rules. |
| 2025-01-11 20:25:43 +0100 | <c_wraith> | (when both the lens and the operation are statically known) |
| 2025-01-11 20:26:18 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-11 20:26:19 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 252 seconds) |
| 2025-01-11 20:26:39 +0100 | <monochrom> | And my favourite example linked above, some of you asked "why doesn't GHC take one step further and just generate 'eval = fval'?" Guess what, these days it does! :) |
| 2025-01-11 20:27:30 +0100 | <c_wraith> | the recent optimizations doing join point analysis really help out with specific types of code, too. |
| 2025-01-11 20:27:43 +0100 | <monochrom> | Yeah that too. |
| 2025-01-11 20:28:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 20:31:05 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2025-01-11 20:32:02 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-11 20:34:58 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 20:35:30 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 20:38:23 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 20:39:32 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 20:39:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 20:42:32 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 20:43:06 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 276 seconds) |
| 2025-01-11 20:43:06 +0100 | tnt2 | tnt1 |
| 2025-01-11 20:44:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 20:46:42 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 20:48:18 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 276 seconds) |
| 2025-01-11 20:49:55 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Ping timeout: 264 seconds) |
| 2025-01-11 20:50:01 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 20:50:12 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 20:50:57 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 244 seconds) |
| 2025-01-11 20:55:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 20:59:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 21:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-11 21:00:43 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-11 21:00:52 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f9009bc3096dfcfc887.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 21:01:10 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-01-11 21:02:42 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-01-11 21:05:33 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 21:06:04 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 21:06:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 21:11:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-11 21:11:11 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-11 21:11:38 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-11 21:11:40 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-11 21:14:21 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 252 seconds) |
| 2025-01-11 21:16:46 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 21:19:01 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Ping timeout: 248 seconds) |
| 2025-01-11 21:20:29 +0100 | swistak | (~swistak@185.21.216.141) (Remote host closed the connection) |
| 2025-01-11 21:21:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 21:25:31 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-01-11 21:26:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 21:29:41 +0100 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2025-01-11 21:35:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 21:37:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 21:38:03 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Ping timeout: 265 seconds) |
| 2025-01-11 21:39:10 +0100 | supercode | (~supercode@user/supercode) (Ping timeout: 240 seconds) |
| 2025-01-11 21:39:23 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2025-01-11 21:40:48 +0100 | Everything | (~Everythin@195.138.86.118) Everything |
| 2025-01-11 21:41:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 21:43:13 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 21:45:05 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-11 21:46:23 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-11 21:52:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 21:53:26 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-01-11 21:57:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 21:58:39 +0100 | <ash3en> | is this a case where dependent types would shine? https://paste.tomsmeding.com/ZYCCmjse |
| 2025-01-11 22:00:02 +0100 | <ash3en> | It looks so inviting to give the type as a function parameter |
| 2025-01-11 22:00:32 +0100 | <ash3en> | ah, or just type parameter 'a' lol |
| 2025-01-11 22:01:11 +0100 | petrichor | (~znc-user@user/petrichor) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-11 22:02:38 +0100 | <ash3en> | or not. i don't know for sure but don't want to ask gpt or similar |
| 2025-01-11 22:02:56 +0100 | petrichor | (~znc-user@user/petrichor) petrichor |
| 2025-01-11 22:04:42 +0100 | <geekosaur> | that's not really a dependent type as I read it. higher order function, I think? |
| 2025-01-11 22:05:41 +0100 | <EvanR> | yes sort of like the binary operator parser combinator that takes a binary function to apply to the two operands |
| 2025-01-11 22:05:50 +0100 | <EvanR> | as a value, not a type |
| 2025-01-11 22:06:21 +0100 | <geekosaur> | it could be even simpler but you need to apply more than just the constructor sometimes (e.g. Integer) |
| 2025-01-11 22:07:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 22:08:19 +0100 | <ash3en> | i'm still not sure how i'd make a single function out of these. |
| 2025-01-11 22:11:09 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-01-11 22:11:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-11 22:11:34 +0100 | <geekosaur> | you can make one "master function" with wrappers for the specific uses, unless you want to pass the extra HOF at use sites. you pass a function (Text -> <whatever type rtToken is>) |
| 2025-01-11 22:12:19 +0100 | <geekosaur> | so tokenizeAddressPattern becomes tokenize AddrPattern, tokenizeInt becomes tokenize (Integer . read . BS.unpack), etc. |
| 2025-01-11 22:13:04 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2025-01-11 22:14:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 22:14:45 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2025-01-11 22:14:51 +0100 | <ash3en> | this probably won't work, but im not sure, since the functions are called using Alex like this: |
| 2025-01-11 22:14:54 +0100 | <ash3en> | @id = ($alpha | \_) ($alpha | $digit | \_ | \' | \?)* |
| 2025-01-11 22:15:02 +0100 | <ash3en> | <0> @id { tokenizeString } |
| 2025-01-11 22:16:17 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2025-01-11 22:16:38 +0100 | <geekosaur> | why wouldn't that work? |
| 2025-01-11 22:16:47 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-01-11 22:17:14 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-01-11 22:17:58 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-01-11 22:17:58 +0100 | <geekosaur> | you can put any Haskell code inside the braces, and as long as the type of rtToken is available (since it's generating a normal Haskell source file and not using TH, it will be) you can use it |
| 2025-01-11 22:18:29 +0100 | <ncf> | monochrom: i'm still curious. how do you prove the obvious free theorem for forall a b. b -> ((a -> a) -> b) -> b ? |
| 2025-01-11 22:20:12 +0100 | <ash3en> | i think i get it now and i will try it out |
| 2025-01-11 22:20:33 +0100 | <ash3en> | geekosaur: thank you! |
| 2025-01-11 22:25:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 22:29:29 +0100 | philopsos | (~caecilius@user/philopsos) philopsos |
| 2025-01-11 22:29:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 22:30:37 +0100 | supercode | (~supercode@user/supercode) (Quit: Client closed) |
| 2025-01-11 22:32:30 +0100 | <tomsmeding> | is there a shorter way to write (\case [] -> True ; x:xs -> all (== x) xs) |
| 2025-01-11 22:32:39 +0100 | <tomsmeding> | i.e. "allEqual" |
| 2025-01-11 22:37:29 +0100 | <ash3en> | geekosaur: this is what i did now. does it look good to you? https://paste.tomsmeding.com/WfD77OU3 |
| 2025-01-11 22:38:14 +0100 | <probie> | :t and . (zipWith (==) <*> tail) |
| 2025-01-11 22:38:15 +0100 | <lambdabot> | Eq a => [a] -> Bool |
| 2025-01-11 22:38:28 +0100 | <ash3en> | tomsmeding: i am not aware of something off the top of my hat |
| 2025-01-11 22:39:18 +0100 | tomsmeding | . o O ( (<*>) = S = \f g x -> f x (g x) ) |
| 2025-01-11 22:39:24 +0100 | <tomsmeding> | ah yes I can read that |
| 2025-01-11 22:39:41 +0100 | <probie> | You didn't specify that you wanted it to be readable |
| 2025-01-11 22:39:43 +0100 | <tomsmeding> | > (and . (zipWith (==) <*> tail)) [] |
| 2025-01-11 22:39:44 +0100 | <lambdabot> | True |
| 2025-01-11 22:39:58 +0100 | <tomsmeding> | oh the zipWith saves you here, cute |
| 2025-01-11 22:40:02 +0100 | <tomsmeding> | probie: I did not |
| 2025-01-11 22:40:41 +0100 | <tomsmeding> | the tail blows up but the zipWith doesn't evaluate the tail on [] |
| 2025-01-11 22:40:46 +0100 | <geekosaur> | ash3en, that works. I think you should also be able to write tokenizeNumber in terms of tokenizeString though |
| 2025-01-11 22:40:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 22:41:32 +0100 | <tomsmeding> | I think I'm going to stay with a helper function. :) |
| 2025-01-11 22:42:03 +0100 | <ash3en> | geekosaur: yes, thank you. i will keep it like this for now and maybe put them into a single function later on : ) |
| 2025-01-11 22:43:13 +0100 | <geekosaur> | you'll get used to HOFs eventually 🙂 |
| 2025-01-11 22:45:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 22:45:23 +0100 | <ash3en> | i did use them in the past already, but I often am too afraid to use anti-patterns I am not aware of |
| 2025-01-11 22:46:27 +0100 | <geekosaur> | ("anti-pattern"?) |
| 2025-01-11 22:53:25 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) (Remote host closed the connection) |
| 2025-01-11 22:53:58 +0100 | <c_wraith> | there are anti-patterns in Haskell. Things like the existential typeclass pattern, which laziness turns out to be a much simpler solution to in nearly every case. |
| 2025-01-11 22:54:34 +0100 | <c_wraith> | But it's rare that factoring something in terms of higher-order functions turns out to be a negative. |
| 2025-01-11 22:56:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 23:00:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-11 23:01:12 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-11 23:01:35 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-11 23:02:32 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-11 23:02:32 +0100 | tnt2 | tnt1 |
| 2025-01-11 23:03:16 +0100 | <ash3en> | maybe anti-pattern is not the best term |
| 2025-01-11 23:03:35 +0100 | <ash3en> | more like non-idiomatic, too complicated, verbose code |
| 2025-01-11 23:04:41 +0100 | <c_wraith> | Ah, that's much more common. But there's only one way out of that. Write code, ask for feedback, try out alternatives, develop your tastes. |
| 2025-01-11 23:04:49 +0100 | <c_wraith> | Same as every other language, really. |
| 2025-01-11 23:06:39 +0100 | <geekosaur> | it's very idiomatic in Haskell |