| 2025-12-03 00:00:07 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-12-03 00:00:29 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 260 seconds) |
| 2025-12-03 00:03:23 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-12-03 00:04:30 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 245 seconds) |
| 2025-12-03 00:06:19 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-03 00:07:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 00:10:33 +0100 | trickard_ | trickard |
| 2025-12-03 00:11:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 00:12:02 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-12-03 00:19:44 +0100 | Miroboru | (~myrvoll@84.215.250.50) Miroboru |
| 2025-12-03 00:22:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 00:24:46 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 00:24:59 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 00:26:56 +0100 | tromp | (~textual@2001:1c00:3487:1b00:40c9:191b:e4f:324a) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-03 00:27:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 00:38:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 00:41:14 +0100 | <iqubic> | Is there a list of Haskell code style things I should know about, like how many spaces to indent things and what have you? |
| 2025-12-03 00:43:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-03 00:43:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 00:43:44 +0100 | trickard_ | trickard |
| 2025-12-03 00:43:57 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-03 00:44:30 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 245 seconds) |
| 2025-12-03 00:47:58 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-03 00:48:13 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 255 seconds) |
| 2025-12-03 00:50:22 +0100 | <geekosaur> | in terms of style, the closest thing to a standard is what various code formatters do — but ormolu, fourmolu, stylish-haskell, brittany (now defunct, I think), etc. all have different opinions |
| 2025-12-03 00:52:27 +0100 | <iqubic> | Is there anywhere I can go to see what they all do? Is there a comparison anywhere? |
| 2025-12-03 00:54:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 00:58:57 +0100 | <EvanR> | I looked at ormolu's output and it didn't match my expectations of style |
| 2025-12-03 00:59:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-03 00:59:14 +0100 | <iqubic> | EvanR: What do you use? |
| 2025-12-03 00:59:31 +0100 | <EvanR> | nothing |
| 2025-12-03 00:59:55 +0100 | <iqubic> | I see. |
| 2025-12-03 01:00:26 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-12-03 01:00:48 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-03 01:01:24 +0100 | Anarchos | (~Anarchos@91-161-254-16.subs.proxad.net) () |
| 2025-12-03 01:05:44 +0100 | Googulator11 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 01:05:46 +0100 | Googulator95 | (~Googulato@85-238-68-117.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 01:06:22 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla |
| 2025-12-03 01:06:22 +0100 | <geekosaur> | likewise fwiw. I think I'd prefer stylish-haskell if someone held a gun to my head and forced me to use a formatter |
| 2025-12-03 01:09:30 +0100 | <jackdk> | ormolu's choices are mostly well-argued but somehow it manages to emit the least aesthetic code I've seen. this is not just an ormulu problem, btw - it seems that each new nix language formatter discovers new frontiers in uglifying code =(. Regardless, I still use autoformatters in a lot of projects just to avoid having style discussions. If I had the time and inclination, I'd look at twiddling the knobs on fourmolu to do more of what i wanted. |
| 2025-12-03 01:10:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 01:11:11 +0100 | <ski> | iqubic : <https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md> is one resource, that might be useful to check and ponder |
| 2025-12-03 01:11:18 +0100 | <ski> | (re tabs vs. spaces, "Yet Another Tabs v. Spaces Debate - I mix tabs and spaces" by dmwit at <http://dmwit.com/tabs/> (also <https://3.bp.blogspot.com/-kX7Gs0lFG_0/V9GIDlF59cI/AAAAAAAAG9E/8OXtloszZRMwd0_NjkWGk6qYedy_0m6jgCL…>) is another opinion) |
| 2025-12-03 01:11:20 +0100 | <EvanR> | autoformatter fans I've talked to would say if there are configuration options it's defeating the purpose (to have everyone use the same format) |
| 2025-12-03 01:11:57 +0100 | <int-e> | but if you don't have options then you're defeating adaptation :-P |
| 2025-12-03 01:11:59 +0100 | <ski> | i would not trust an autoformatter, without closely checking out its opinions |
| 2025-12-03 01:12:15 +0100 | <int-e> | I meant adoptation, though both work |
| 2025-12-03 01:12:19 +0100 | <jackdk> | EvanR: I disagree, because you can still maintain consistency within a codebase, which is where I feel it's most important. |
| 2025-12-03 01:12:27 +0100 | <jackdk> | (with autoformatter fans, not with you) |
| 2025-12-03 01:12:49 +0100 | <EvanR> | really |
| 2025-12-03 01:13:11 +0100 | <EvanR> | so like project1 is somehow set up with config 1, project 2 config 2 and everyone can actually keep it straight |
| 2025-12-03 01:13:44 +0100 | ski | indents by two spaces (including the whole module body, from the `where') |
| 2025-12-03 01:13:44 +0100 | xff0x | (~xff0x@2405:6580:b080:900:b577:52ee:470:5943) (Ping timeout: 244 seconds) |
| 2025-12-03 01:14:23 +0100 | <iqubic> | Wait... are you serieous? |
| 2025-12-03 01:15:24 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 01:15:29 +0100 | <ski> | of course |
| 2025-12-03 01:16:04 +0100 | <ski> | (exception is if there's no `module ... where' part) |
| 2025-12-03 01:16:54 +0100 | <geekosaur> | my response to said autoformatter fans is that as soon as there's more than one such the purpose is already defeated |
| 2025-12-03 01:17:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-03 01:17:09 +0100 | <jackdk> | EvanR: Yes, the configurable formatters I'm aware of can store the project config in version control next to the source. |
| 2025-12-03 01:17:18 +0100 | <geekosaur> | and you will not convince everyone in the Haskell community to use One True Formatter |
| 2025-12-03 01:17:47 +0100 | <haskellbridge> | <loonycyborg> if there was one true way then compiler would enforce it :P |
| 2025-12-03 01:18:09 +0100 | <geekosaur> | (case in point, brittany's origins — and its demise) |
| 2025-12-03 01:18:27 +0100 | <haskellbridge> | <loonycyborg> I think it emits warning if you stick "\t" somewhere already |
| 2025-12-03 01:18:38 +0100 | <haskellbridge> | <loonycyborg> while in YAML they're illegal altogether |
| 2025-12-03 01:18:49 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 255 seconds) |
| 2025-12-03 01:19:57 +0100 | <ski> | i also not that seldom divide the source into pages (separated by form feeds) of size between thirtythree and sixtysix lines (c.f. "Riastradh's Lisp Style Rules" <https://mumble.net/~campbell/scheme/style.txt>) |
| 2025-12-03 01:20:07 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 264 seconds) |
| 2025-12-03 01:20:42 +0100 | <geekosaur> | now I'm being reminded of C source code formatted with formfeeds in comments between functions, thanks |
| 2025-12-03 01:28:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 01:33:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-03 01:35:44 +0100 | Googulator88 | (~Googulato@85-238-68-117.pool.digikabel.hu) |
| 2025-12-03 01:35:45 +0100 | Googulator11 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 01:41:44 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
| 2025-12-03 01:44:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 01:49:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-12-03 01:52:54 +0100 | DetourNetworkUK | (DetourNetw@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2025-12-03 01:54:12 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2025-12-03 01:56:20 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 02:01:14 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 260 seconds) |
| 2025-12-03 02:09:59 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-12-03 02:13:58 +0100 | <iqubic> | I can't tell if my LSP is configured incorrectly or if weird things are happening here. |
| 2025-12-03 02:14:25 +0100 | <iqubic> | By default, is hlint supposed to give a warning for unused function inputs? |
| 2025-12-03 02:14:31 +0100 | <iqubic> | part1 :: String -> Int |
| 2025-12-03 02:14:39 +0100 | <iqubic> | part1 i = undefined |
| 2025-12-03 02:15:10 +0100 | <iqubic> | It's not telling me anything about the parameter i being unused. |
| 2025-12-03 02:15:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 02:16:30 +0100 | acidjnk | (~acidjnk@p200300d6e71719443da791614ae70cbb.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2025-12-03 02:16:45 +0100 | <davean> | I'm at a loss why people care about style. It takes real work to make a style so bad it actually matters. |
| 2025-12-03 02:18:18 +0100 | <davean> | You can do it, but I've not seen it outside of obfuscation contests. |
| 2025-12-03 02:19:41 +0100 | omidmash5 | (~omidmash@user/omidmash) omidmash |
| 2025-12-03 02:19:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-03 02:21:25 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2025-12-03 02:21:25 +0100 | omidmash5 | omidmash |
| 2025-12-03 02:22:28 +0100 | <probie> | davean: Broken window theory. If the style is inconsistent, it'll encourage other bad behaviours that actually have consequences |
| 2025-12-03 02:24:45 +0100 | <davean> | That doesn't follow the structure of the broken window theory to me |
| 2025-12-03 02:24:55 +0100 | X-Scale | (~ARM@6.67.114.89.rev.vodafone.pt) (Ping timeout: 240 seconds) |
| 2025-12-03 02:25:00 +0100 | <davean> | The same "therefor" doesn't hold or apply |
| 2025-12-03 02:25:48 +0100 | X-Scale | (~ARM@50.65.114.89.rev.vodafone.pt) X-Scale |
| 2025-12-03 02:26:37 +0100 | mehbark | (~mehbark@joey.luug.ece.vt.edu) |
| 2025-12-03 02:26:58 +0100 | mehbark | (~mehbark@joey.luug.ece.vt.edu) (Changing host) |
| 2025-12-03 02:26:58 +0100 | mehbark | (~mehbark@user/mehbark) mehbark |
| 2025-12-03 02:27:19 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) (Ping timeout: 240 seconds) |
| 2025-12-03 02:30:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 02:31:56 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-12-03 02:32:46 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 02:33:00 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 02:33:15 +0100 | img | (~img@user/img) img |
| 2025-12-03 02:33:28 +0100 | <davean> | "I don't like their style" is different from "this isn't maintained. The equivilence for the broken window theory would be coming across a place with gothic arches |
| 2025-12-03 02:34:07 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-12-03 02:35:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 02:36:24 +0100 | divya | (divya@140.238.251.170) (Ping timeout: 244 seconds) |
| 2025-12-03 02:44:24 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 02:46:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 02:48:34 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 246 seconds) |
| 2025-12-03 02:52:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 02:55:51 +0100 | <geekosaur> | the usual argument I hear for forcing formatting in projects is they usually enforce a style that minimizes diffs |
| 2025-12-03 03:02:04 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-03 03:02:08 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 03:04:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 03:06:46 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 265 seconds) |
| 2025-12-03 03:07:33 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-03 03:09:38 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-12-03 03:09:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-03 03:20:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 03:24:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 03:33:34 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-12-03 03:34:24 +0100 | finsternis | (~X@23.226.237.192) finsternis |
| 2025-12-03 03:36:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 03:36:56 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2025-12-03 03:40:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-03 03:49:35 +0100 | wbooze | (~wbooze@2001-4dd7-9813-0-4568-5322-9334-ddaa.ipv6dyn.netcologne.de) Inline |
| 2025-12-03 03:51:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 03:52:15 +0100 | trickard_ | trickard |
| 2025-12-03 03:56:20 +0100 | AlexNoo_ | (~AlexNoo@85.174.183.177) |
| 2025-12-03 03:56:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 03:57:50 +0100 | AlexZenon | (~alzenon@85.174.183.216) (Ping timeout: 245 seconds) |
| 2025-12-03 03:59:35 +0100 | AlexNoo | (~AlexNoo@85.174.183.216) (Ping timeout: 240 seconds) |
| 2025-12-03 04:01:57 +0100 | AlexZenon | (~alzenon@85.174.183.177) |
| 2025-12-03 04:04:41 +0100 | <EvanR> | that would be a good argument |
| 2025-12-03 04:04:43 +0100 | <EvanR> | if it were true |
| 2025-12-03 04:05:01 +0100 | <EvanR> | auto formatting after a code change may have collateral damage when hit with the autoformatter |
| 2025-12-03 04:05:05 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-03 04:07:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 04:08:28 +0100 | mesaoptimizer | (~user@user/PapuaHardyNet) (Remote host closed the connection) |
| 2025-12-03 04:12:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 04:20:27 +0100 | <geekosaur> | theoretically you only get that when initially applying formatting |
| 2025-12-03 04:21:20 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 240 seconds) |
| 2025-12-03 04:23:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 04:23:16 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-03 04:25:54 +0100 | <EvanR> | with a properly designed algorithm? |
| 2025-12-03 04:26:07 +0100 | <EvanR> | is there a no collateral damage theorem |
| 2025-12-03 04:28:42 +0100 | td_ | (~td@i53870902.versanet.de) (Ping timeout: 252 seconds) |
| 2025-12-03 04:29:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 04:30:20 +0100 | td_ | (~td@i5387093E.versanet.de) |
| 2025-12-03 04:31:59 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 250 seconds) |
| 2025-12-03 04:35:28 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-03 04:37:28 +0100 | inline__ | (~wbooze@cgn-195-14-219-152.nc.de) Inline |
| 2025-12-03 04:40:30 +0100 | wbooze | (~wbooze@2001-4dd7-9813-0-4568-5322-9334-ddaa.ipv6dyn.netcologne.de) (Ping timeout: 244 seconds) |
| 2025-12-03 04:41:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 04:45:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 04:56:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 05:01:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-12-03 05:07:56 +0100 | oppili- | oppili |
| 2025-12-03 05:07:56 +0100 | oppili | (~oppili@lewi-27-b2-v4wan-165682-cust505.vm4.cable.virginm.net) (Changing host) |
| 2025-12-03 05:07:56 +0100 | oppili | (~oppili@user/nerdypepper) nerdy |
| 2025-12-03 05:11:58 +0100 | Square | (~Square@user/square) Square |
| 2025-12-03 05:12:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 05:13:54 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-03 05:15:53 +0100 | Googulator45 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 05:15:53 +0100 | Googulator88 | (~Googulato@85-238-68-117.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 05:16:09 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Remote host closed the connection) |
| 2025-12-03 05:17:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-03 05:18:09 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-03 05:28:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 05:32:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 05:44:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 05:48:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 05:50:01 +0100 | <haskellbridge> | <zoil> i cant beleive i went to all the trouble of putting together an example just to discover the advice was corrupt |
| 2025-12-03 05:52:12 +0100 | <haskellbridge> | <zoil> Leary |
| 2025-12-03 05:52:13 +0100 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/meQNVtzNxaPzTuQoVMpGePld/Wmc2FsApiyo (7 lines) |
| 2025-12-03 05:52:42 +0100 | <haskellbridge> | <zoil> i didnt read the bit where it was "and then you get these new constraints instead" |
| 2025-12-03 05:52:45 +0100 | <haskellbridge> | <zoil> ... |
| 2025-12-03 05:52:56 +0100 | <haskellbridge> | <zoil> _thats the whole point_ |
| 2025-12-03 05:53:26 +0100 | <haskellbridge> | <zoil> it wasnt a question about "how do i refactor these dumb constraints so i can carry around a more effecient expression" |
| 2025-12-03 05:53:36 +0100 | <haskellbridge> | <zoil> it was, whats up with having to carry around these constraints |
| 2025-12-03 05:54:00 +0100 | <haskellbridge> | <zoil> why cant I _assert to the compiler_ that the exhaustiveness is something i have ensured I have taken care of |
| 2025-12-03 05:54:16 +0100 | <haskellbridge> | <zoil> if i have to tell it that Bool has an Eq instance, then its fine |
| 2025-12-03 05:54:35 +0100 | <haskellbridge> | <zoil> but if its, that the head and tail of a hetroginous container both have a recursive instance |
| 2025-12-03 05:54:39 +0100 | <EvanR> | a type level trust me |
| 2025-12-03 05:54:43 +0100 | <EvanR> | sounds dangerous |
| 2025-12-03 05:54:57 +0100 | <haskellbridge> | <zoil> but we have exhaustiveness elsewhere |
| 2025-12-03 05:55:03 +0100 | <haskellbridge> | <zoil> maybe not that the user can specify it |
| 2025-12-03 05:55:20 +0100 | <haskellbridge> | <zoil> we have had this whole dependant types singletons debate for years |
| 2025-12-03 05:55:25 +0100 | <haskellbridge> | <zoil> isnt this the whole point!? |
| 2025-12-03 05:55:43 +0100 | <haskellbridge> | <zoil> these damn eta constraints or whatever they are |
| 2025-12-03 05:56:06 +0100 | <EvanR> | every time I disable the type system in e.g. C it usually results in a segfault xD |
| 2025-12-03 05:56:06 +0100 | <EvanR> | it's crazy |
| 2025-12-03 05:56:06 +0100 | <EvanR> | how good humans are at messing up logic |
| 2025-12-03 05:56:15 +0100 | <haskellbridge> | <zoil> if its an exhaustiveness issue, thats at least an expression of the problem in a way, that, at least personally, i have never heard it phrased |
| 2025-12-03 05:56:51 +0100 | <haskellbridge> | <zoil> EvanR: sure, i dont want some unknown way to break the compiler |
| 2025-12-03 05:56:57 +0100 | <haskellbridge> | <zoil> we wouldnt know how to give reasonable errors |
| 2025-12-03 05:57:07 +0100 | <haskellbridge> | <zoil> "you aserted something wrong!" |
| 2025-12-03 05:57:24 +0100 | <haskellbridge> | <zoil> but still. languages like lean have this whole business dedicated to assertion proving |
| 2025-12-03 05:57:44 +0100 | <EvanR> | does lean let you explicitly deal with or disable exhaustiveness |
| 2025-12-03 05:57:47 +0100 | <haskellbridge> | <zoil> its like. iv even had situations where i pick up a constraint like 1 + n ~ n + 1 |
| 2025-12-03 05:58:15 +0100 | <haskellbridge> | <zoil> EvanR: idk how lean works. i think its more like a hackage for assertions |
| 2025-12-03 05:58:23 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2025-12-03 05:58:40 +0100 | <haskellbridge> | <zoil> like, there is some transistivity axiom that allows you to prove something and it does everything like that in a rigerous derived way |
| 2025-12-03 05:58:57 +0100 | <glguy> | zoil: the thing you were asking about earlier wasn't about exhaustiveness, it's about not knowing what instance to use at runtime |
| 2025-12-03 05:59:20 +0100 | <haskellbridge> | <zoil> there was some confusion, which iiuc, is because it requires 2 instances |
| 2025-12-03 05:59:30 +0100 | <haskellbridge> | <zoil> iiuc thats a problem because its not exhaustive |
| 2025-12-03 05:59:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:00:14 +0100 | <EvanR> | exhaustive sounds like something to do with a closed world assumption. type classes are open world and can never be exhaustive |
| 2025-12-03 06:00:32 +0100 | <EvanR> | for all types there either is or not an instance |
| 2025-12-03 06:00:49 +0100 | <haskellbridge> | <zoil> its saying (f :: [Type] -> Constraint) (xs :: [Type]) instance does not exist. and im saying "but i gave you a f [], and a f (x:xs) case, foolish compiler" |
| 2025-12-03 06:00:49 +0100 | <EvanR> | (yet) |
| 2025-12-03 06:01:17 +0100 | <haskellbridge> | <zoil> its exhaustive in the sum GADT cases |
| 2025-12-03 06:01:21 +0100 | <haskellbridge> | <zoil> its not an open datatype |
| 2025-12-03 06:01:35 +0100 | <haskellbridge> | <zoil> if it was a data family i would agree |
| 2025-12-03 06:01:45 +0100 | <haskellbridge> | <zoil> but its not, so i have something that can be exhaustive |
| 2025-12-03 06:02:35 +0100 | <haskellbridge> | <zoil> it seems to be like "what!? more than one instance, im confused" |
| 2025-12-03 06:02:38 +0100 | <haskellbridge> | <zoil> which doesnt seem right at all!! |
| 2025-12-03 06:03:07 +0100 | <haskellbridge> | <zoil> its like "where is the xs case, i only see [] and (x:xs), this is not xs" |
| 2025-12-03 06:03:19 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 260 seconds) |
| 2025-12-03 06:03:26 +0100 | <haskellbridge> | <zoil> and the user is like "but it is!! its exhaustive!!" |
| 2025-12-03 06:04:07 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-03 06:04:26 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2025-12-03 06:04:45 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-03 06:04:56 +0100 | <haskellbridge> | <zoil> then someone said, "so just put it in one instance, and like, match the cases by a type family" |
| 2025-12-03 06:05:19 +0100 | <haskellbridge> | <zoil> and then someone else said "but this needs a type witness, use singletons" |
| 2025-12-03 06:05:51 +0100 | <haskellbridge> | <zoil> and then there was this KnownNonempty thing where head and tail could be given value level case matching that would bring the type into scope |
| 2025-12-03 06:06:20 +0100 | <haskellbridge> | <zoil> and then i picked up this KnownNonempty constraint, and this still indicates the compiler is not happy that the assertion is satisfied |
| 2025-12-03 06:06:31 +0100 | <haskellbridge> | <zoil> it says. "no. idk this instance exists, put it in a constraint" |
| 2025-12-03 06:06:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-03 06:07:02 +0100 | <haskellbridge> | <zoil> because the instances for KnownNonempty have the same problem. idk if this can be solved by the same typefamily idea or something |
| 2025-12-03 06:07:11 +0100 | <haskellbridge> | <zoil> or if its that GHC is not advanced, or what |
| 2025-12-03 06:07:15 +0100 | <EvanR> | either you missed the simple way to do what you're doing, the only way to do it in haskell is so arcane that it's probably not worth it, or it's just impossible |
| 2025-12-03 06:07:16 +0100 | <haskellbridge> | <zoil> so i need some expert input |
| 2025-12-03 06:08:08 +0100 | <EvanR> | sophisticated stuff at the type level is just easily overcomplicated here |
| 2025-12-03 06:08:39 +0100 | <haskellbridge> | <zoil> iiuc the "singletons idea" requires these exhastive instances are provided. and these have to be done in one class, and there was another idea to use type families to do this, but im totally confused. |
| 2025-12-03 06:09:07 +0100 | <haskellbridge> | <zoil> i just want to be able to describe the situation so people can understand the issue and maybe help produce a working example |
| 2025-12-03 06:10:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:10:21 +0100 | <haskellbridge> | <zoil> i had this example to work with so far; https://play.haskell.org/saved/GwyPOlmo |
| 2025-12-03 06:11:06 +0100 | <EvanR> | cool |
| 2025-12-03 06:11:34 +0100 | <haskellbridge> | <zoil> also, glguy suggested that the name singleton should not apply to the recursive KnownNE situation, but im not sure why |
| 2025-12-03 06:11:40 +0100 | <haskellbridge> | <zoil> im not sure it matters |
| 2025-12-03 06:12:04 +0100 | <haskellbridge> | <zoil> its like, a recursively defined case that covers many situations, as opposed to (an infinite number) of explicit assertions |
| 2025-12-03 06:12:29 +0100 | <EvanR> | because KnownNE isn't even a type |
| 2025-12-03 06:13:06 +0100 | <EvanR> | and you're making two instances of it, so what's "single" about that |
| 2025-12-03 06:13:33 +0100 | <haskellbridge> | <zoil> sorry, WhichNE |
| 2025-12-03 06:13:44 +0100 | <haskellbridge> | <zoil> data WhichNE xs where |
| 2025-12-03 06:13:44 +0100 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/QHgkurBjvEckITCLYEHUHCfc/FL5KnP9OiZg (3 lines) |
| 2025-12-03 06:14:09 +0100 | <haskellbridge> | <zoil> its the singletons idea of having this type witness that is matchable upon values to bring the corresponding type into scope |
| 2025-12-03 06:14:19 +0100 | <haskellbridge> | <zoil> if thats not what a singleston is, idk, what this is |
| 2025-12-03 06:14:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-03 06:15:26 +0100 | <haskellbridge> | <zoil> here was glguys paste about how to use the type family to condense the two instances into one |
| 2025-12-03 06:15:30 +0100 | <haskellbridge> | <zoil> https://paste.tomsmeding.com/UEfrQUiN |
| 2025-12-03 06:15:46 +0100 | <EvanR> | anyway your code compiles so |
| 2025-12-03 06:16:02 +0100 | <haskellbridge> | <zoil> you dont understand the issue!? |
| 2025-12-03 06:16:07 +0100 | <haskellbridge> | <zoil> its picking up these constraints! |
| 2025-12-03 06:16:08 +0100 | <EvanR> | absolutely not |
| 2025-12-03 06:16:28 +0100 | <haskellbridge> | <zoil> the compiler will forever ask for a constraint to an instance that exists at top level |
| 2025-12-03 06:16:38 +0100 | <haskellbridge> | <zoil> simply because it exists in a distributed way |
| 2025-12-03 06:17:29 +0100 | <haskellbridge> | <zoil> it would be like if i wrote a function matching the [] and (x:xs) cases in different function cases, and it was like "the function is not defined" |
| 2025-12-03 06:17:41 +0100 | <haskellbridge> | <zoil> just because it cant tell if its exhaustive in these cases |
| 2025-12-03 06:18:52 +0100 | <haskellbridge> | <zoil> as long as its "i insist that the KnownNE constraint is explicity specified", then its failing to appreciate the instance has been written at top level |
| 2025-12-03 06:19:06 +0100 | <haskellbridge> | <zoil> now, if theres a "special way" of doing this, like, ensuring everything is written in just one instance |
| 2025-12-03 06:19:12 +0100 | <haskellbridge> | <zoil> then at least there is a workaround |
| 2025-12-03 06:19:33 +0100 | <haskellbridge> | <zoil> which should be pretty clearly indicated! since otherwise this insane behaviour from the compiler is commonly encountered |
| 2025-12-03 06:19:42 +0100 | <haskellbridge> | <zoil> or it indicates a compiler fix is required |
| 2025-12-03 06:20:39 +0100 | <haskellbridge> | <zoil> "compiler is nolonger blind to instances defined over several cases" |
| 2025-12-03 06:20:59 +0100 | <haskellbridge> | <zoil> but then, i could just give the basecase instance. and then it would be like "wtf, this doesnt match" |
| 2025-12-03 06:21:35 +0100 | <haskellbridge> | <zoil> "nonexhaustive instance encountered in this code you were trying to write on line 11" |
| 2025-12-03 06:22:13 +0100 | <haskellbridge> | <zoil> which it _currently always says_ |
| 2025-12-03 06:22:33 +0100 | <haskellbridge> | <zoil> except in the case where no pattern matching takes place |
| 2025-12-03 06:23:15 +0100 | <haskellbridge> | <zoil> then it is like "i see the instance exists, i will not require the constraint is explicitly specified, i cannot forsee an instance where the instance does not exist where then i would require it as a constraint" |
| 2025-12-03 06:25:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:25:43 +0100 | EvanR | looks at line 11 |
| 2025-12-03 06:25:57 +0100 | <EvanR> | there's nothing there |
| 2025-12-03 06:26:38 +0100 | <haskellbridge> | <zoil> > :-( |
| 2025-12-03 06:27:11 +0100 | <haskellbridge> | <zoil> > :-| |
| 2025-12-03 06:27:19 +0100 | <haskellbridge> | <zoil> ... >:-( |
| 2025-12-03 06:28:01 +0100 | <haskellbridge> | <zoil> i dont know why this type witness idea was even suggested |
| 2025-12-03 06:28:12 +0100 | <haskellbridge> | <zoil> there was apparently something different about show and read |
| 2025-12-03 06:28:16 +0100 | <EvanR> | what are you trying to do |
| 2025-12-03 06:28:33 +0100 | <haskellbridge> | <zoil> like, show could resolve the type, but read would require something like an instance version of allowambiguous types |
| 2025-12-03 06:28:50 +0100 | <haskellbridge> | <zoil> EvanR: im sorry mate, im not enjoying you just talking past everything iv written |
| 2025-12-03 06:29:21 +0100 | <haskellbridge> | <zoil> i think "what im trying to do" is very much inferable from the discussion so far. |
| 2025-12-03 06:29:22 +0100 | <EvanR> | I guess you can keep spamming the channel with nonsense |
| 2025-12-03 06:29:32 +0100 | <haskellbridge> | <zoil> THANKS! |
| 2025-12-03 06:29:39 +0100 | <EvanR> | without being rudely interrupted |
| 2025-12-03 06:29:48 +0100 | <haskellbridge> | <zoil> ill guess you can just keep using a time machine to write a compiler without any focus grouping from the future |
| 2025-12-03 06:30:01 +0100 | <haskellbridge> | <zoil> im not trying to be rude |
| 2025-12-03 06:30:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 06:30:28 +0100 | <haskellbridge> | <zoil> if you could maybe not just, stonewall me, and then, as soon as this is noticed, start accusing me of not talking to you in the prescribed manner |
| 2025-12-03 06:30:41 +0100 | <haskellbridge> | <zoil> what specifically is it that you dont understand |
| 2025-12-03 06:31:05 +0100 | <haskellbridge> | <zoil> instead of just this most vague assertion that you cannot seem to convey any degree of understanding at all of the situation described |
| 2025-12-03 06:31:07 +0100 | <haskellbridge> | <zoil> its vexating |
| 2025-12-03 06:31:59 +0100 | <haskellbridge> | <zoil> "its a burden of proof, i insist i dont understand the users query and by virtue of this its nonesense" |
| 2025-12-03 06:32:18 +0100 | <haskellbridge> | <zoil> its an awful precedent and it makes our community inpenetrable and unfrinedly |
| 2025-12-03 06:36:23 +0100 | michalz | (~michalz@185.246.207.205) |
| 2025-12-03 06:41:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:45:54 +0100 | Googulator45 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 06:45:56 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 06:46:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-03 06:48:27 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2025-12-03 06:48:55 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 06:49:08 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 06:54:08 +0100 | <probie> | +1 for could not infer what you're trying to do. There's no need to be mean about it. You're obviously frustrated by something, type families are involved, you did something with singletons but it was the wrong path(?) |
| 2025-12-03 06:55:00 +0100 | <probie> | Since your problem seems to be at the type level, can you give an expression you want to type check, or not type check as appropriate? |
| 2025-12-03 06:55:35 +0100 | Fijxu | (~Fijxu@user/fijxu) (Quit: XD!!) |
| 2025-12-03 06:56:10 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-12-03 06:57:02 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2025-12-03 06:57:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:57:41 +0100 | Fijxu | (~Fijxu@user/fijxu) (Remote host closed the connection) |
| 2025-12-03 06:59:01 +0100 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2025-12-03 06:59:15 +0100 | Square | (~Square@user/square) (Ping timeout: 240 seconds) |
| 2025-12-03 07:02:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 07:02:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 07:05:30 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-12-03 07:06:26 +0100 | trickard_ | trickard |
| 2025-12-03 07:07:08 +0100 | poscat0x04 | (~poscat@user/poscat) (Ping timeout: 244 seconds) |
| 2025-12-03 07:07:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 07:14:27 +0100 | <haskellbridge> | <zoil> thanks, im sorry i rage quit |
| 2025-12-03 07:16:19 +0100 | <haskellbridge> | <zoil> so far i have this; |
| 2025-12-03 07:16:19 +0100 | <haskellbridge> | https://play.haskell.org/saved/GwyPOlmo |
| 2025-12-03 07:16:40 +0100 | <haskellbridge> | <zoil> er, sorry, that was the previous version, now i have this |
| 2025-12-03 07:16:41 +0100 | <haskellbridge> | <zoil> https://play.haskell.org/saved/GJqAvv67 |
| 2025-12-03 07:17:30 +0100 | <haskellbridge> | <zoil> its saying the injectivity condition here is not accepted |
| 2025-12-03 07:17:30 +0100 | <haskellbridge> | <zoil> type family StatefulTransfers (xs :: Nonempty Type) i o = (c :: Constraint) | c -> xs i o where |
| 2025-12-03 07:18:04 +0100 | <haskellbridge> | <zoil> like, i cant get the fundeps to go through the injective type family properly |
| 2025-12-03 07:18:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 07:21:39 +0100 | <haskellbridge> | <zoil> so, whatever this apparent workaround was supposed to acheive, it cant |
| 2025-12-03 07:21:57 +0100 | <haskellbridge> | <zoil> because the injective type family fails to impart the same data as the fundep |
| 2025-12-03 07:22:24 +0100 | <haskellbridge> | <zoil> i have concluded that the compiler hates me, and i was wrong not to have rage quit. |
| 2025-12-03 07:23:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 07:23:27 +0100 | <Leary> | Let's kill all the cruft so others can follow along; the core issue is this: https://play.haskell.org/saved/BeYSIaVz |
| 2025-12-03 07:24:15 +0100 | <Leary> | There are two instances, and GHC won't let you pretend they're the same as `Read (Two b)`, because that implies you have a way to choose which instance you want to use **at runtime** from type information alone. |
| 2025-12-03 07:26:16 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-03 07:26:49 +0100 | <EvanR> | thanks |
| 2025-12-03 07:34:02 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2025-12-03 07:34:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 07:36:12 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 07:39:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-03 07:40:44 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 260 seconds) |
| 2025-12-03 07:42:21 +0100 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-12-03 07:45:10 +0100 | chenjf | (~chenjf@68.64.178.54) |
| 2025-12-03 07:49:19 +0100 | chenjf | (~chenjf@68.64.178.54) (Client Quit) |
| 2025-12-03 07:51:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 07:54:06 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-12-03 07:55:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 07:59:13 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-03 08:06:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 08:11:16 +0100 | <jackdk> | I had a similar issue the other day, and ended up with something akin to this. Then I realised I'd need to manufacture an SBoolI dictionary somehow, and I may as well use package `singletons` if I want that. So I found a way to do what I wanted with less typelevel stuff. https://www.irccloud.com/pastebin/vNHqRN0S/OneTwoSBool.hs |
| 2025-12-03 08:11:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-03 08:12:16 +0100 | <jackdk> | It would still mean writing `parse :: SBoolI b => String -> Two b`; the `noConstraint` form is not possible AFAIK. |
| 2025-12-03 08:13:46 +0100 | user363627 | (~user@user/user363627) (Remote host closed the connection) |
| 2025-12-03 08:18:37 +0100 | peterbecich | (~Thunderbi@172.222.148.214) (Ping timeout: 246 seconds) |
| 2025-12-03 08:20:28 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-12-03 08:20:43 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 08:22:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 08:25:12 +0100 | <glguy> | If you finish aoc tonight check out my infinite list of solutions for when you get to turn on 1, 2, 3... batteries |
| 2025-12-03 08:26:46 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-12-03 08:27:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-03 08:30:59 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 08:32:46 +0100 | fp1 | (~Thunderbi@130.233.53.128) fp |
| 2025-12-03 08:36:52 +0100 | iqubic | (~sophia@2601:602:9203:1660:dd83:8e66:bfcb:8c1e) (Remote host closed the connection) |
| 2025-12-03 08:38:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 08:41:35 +0100 | fp1 | (~Thunderbi@130.233.53.128) (Ping timeout: 245 seconds) |
| 2025-12-03 08:42:09 +0100 | iqubic | (~sophia@2601:602:9203:1660:661f:14db:875e:5d74) iqubic |
| 2025-12-03 08:43:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-03 08:43:42 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-12-03 08:54:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 08:57:12 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 09:00:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-03 09:03:36 +0100 | trickard_ | trickard |
| 2025-12-03 09:04:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 09:08:03 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2025-12-03 09:08:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-03 09:10:48 +0100 | Googulator63 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 09:10:48 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 09:16:43 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-12-03 09:19:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 09:20:15 +0100 | tessier | (~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds) |
| 2025-12-03 09:20:39 +0100 | chele | (~chele@user/chele) chele |
| 2025-12-03 09:24:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 09:27:39 +0100 | tessier | (~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) tessier |
| 2025-12-03 09:30:17 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-03 09:30:23 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-03 09:33:42 +0100 | Vq | (~vq@90-224-37-169-no600.tbcn.telia.com) (Changing host) |
| 2025-12-03 09:33:42 +0100 | Vq | (~vq@user/vq) Vq |
| 2025-12-03 09:33:50 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-03 09:34:03 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 09:34:14 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2025-12-03 09:34:32 +0100 | ft | (~ft@p508db844.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-12-03 09:34:43 +0100 | akegalj | (~akegalj@78-0-210-92.adsl.net.t-com.hr) akegalj |
| 2025-12-03 09:35:09 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-12-03 09:35:26 +0100 | <akegalj> | Is there a flag for ghci that saves output to a file ? IIRC there is option for this, but can't find it. |
| 2025-12-03 09:37:00 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 272 seconds) |
| 2025-12-03 09:37:25 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-12-03 09:37:45 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 09:38:22 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2025-12-03 09:40:45 +0100 | Googulator63 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 09:40:52 +0100 | Googulator86 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 09:46:07 +0100 | fp1 | (~Thunderbi@130.233.53.128) fp |
| 2025-12-03 09:47:39 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 09:54:54 +0100 | fp1 | (~Thunderbi@130.233.53.128) (Ping timeout: 260 seconds) |
| 2025-12-03 09:56:52 +0100 | inline__ | (~wbooze@cgn-195-14-219-152.nc.de) (Quit: Leaving) |
| 2025-12-03 09:59:35 +0100 | mesaoptimizer | (~user@user/PapuaHardyNet) PapuaHardyNet |
| 2025-12-03 10:00:37 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-12-03 10:00:47 +0100 | mesaoptimizer | (~user@user/PapuaHardyNet) (Client Quit) |
| 2025-12-03 10:01:03 +0100 | mesaoptimizer | (~user@user/PapuaHardyNet) PapuaHardyNet |
| 2025-12-03 10:03:13 +0100 | <lucabtz> | is there a way to drop the last n elements of a list? |
| 2025-12-03 10:03:38 +0100 | <lucabtz> | im composing init with itself n times, but im pretty sure it isnt a great way |
| 2025-12-03 10:03:49 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 10:06:08 +0100 | <Leary> | lucabtz: There won't be a /great/ way, but `reverse . drop n . reverse` should be better than that. |
| 2025-12-03 10:06:28 +0100 | <lucabtz> | yeah i though of that too |
| 2025-12-03 10:07:35 +0100 | Googulator86 | Googulator |
| 2025-12-03 10:08:50 +0100 | <lucabtz> | i think with a list of length n repeating init N times should have complexity O(n * N), while yeah reverse . drop N . reverse should scale like 2n + N ~ O(n) |
| 2025-12-03 10:08:55 +0100 | X-Scale | (~ARM@50.65.114.89.rev.vodafone.pt) (Ping timeout: 240 seconds) |
| 2025-12-03 10:09:56 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 10:10:44 +0100 | Googulator | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 10:10:49 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 10:11:44 +0100 | <Leary> | This should be moderately faster: https://play.haskell.org/saved/E1adTNLc |
| 2025-12-03 10:14:07 +0100 | acidjnk | (~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) acidjnk |
| 2025-12-03 10:16:33 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 10:16:46 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 10:17:00 +0100 | <lucabtz> | yeah thats cool |
| 2025-12-03 10:25:18 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 10:25:24 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-03 10:26:12 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-12-03 10:26:45 +0100 | Inline | (~inlinE@2001-4dd3-7fc8-0-434a-a4b1-7362-b14b.ipv6dyn.netcologne.de) (Ping timeout: 252 seconds) |
| 2025-12-03 10:27:42 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 10:28:41 +0100 | kuribas | (~user@2a02:1808:c7:cecf:a041:fccb:9242:86e9) kuribas |
| 2025-12-03 10:29:26 +0100 | hdggxin | (~hdggxin@223.181.46.243) |
| 2025-12-03 10:29:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 10:36:18 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-12-03 10:40:49 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 10:40:56 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 10:44:00 +0100 | trickard_ | trickard |
| 2025-12-03 10:47:35 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 10:50:02 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-12-03 10:50:24 +0100 | X-Scale | (~ARM@50.65.114.89.rev.vodafone.pt) X-Scale |
| 2025-12-03 10:54:01 +0100 | <chromoblob> | i think you should first find the length, then take (l - n) where l is length |
| 2025-12-03 11:06:16 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds) |
| 2025-12-03 11:06:55 +0100 | <Axman6> | > let dropEnd n xs = zipWith const xs (drop n xs) in dropEnd 3 "ABCDEFG" |
| 2025-12-03 11:06:59 +0100 | <lambdabot> | "ABCD" |
| 2025-12-03 11:07:13 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 260 seconds) |
| 2025-12-03 11:07:28 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 11:07:38 +0100 | <Axman6> | This has the benefit of being lazy too, it only eevaluates n elements ahead of the the output. lucabtz ^ |
| 2025-12-03 11:07:56 +0100 | <Axman6> | zipWith const is an incredibly useful thing to know about |
| 2025-12-03 11:08:16 +0100 | <Axman6> | > let dropEnd n xs = zipWith const xs (drop n xs) in dropEnd 3 [0..] |
| 2025-12-03 11:08:20 +0100 | <lambdabot> | [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,2... |
| 2025-12-03 11:08:39 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-12-03 11:09:45 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-03 11:09:59 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 11:11:32 +0100 | <lucabtz> | thank you Axman6 |
| 2025-12-03 11:13:16 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2025-12-03 11:18:32 +0100 | <lucabtz> | i think Leary's way with foldr should be lazy too |
| 2025-12-03 11:19:03 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) (Remote host closed the connection) |
| 2025-12-03 11:19:27 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) hsw |
| 2025-12-03 11:21:30 +0100 | Googulator93 | Googulator |
| 2025-12-03 11:22:50 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 11:26:56 +0100 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-12-03 11:27:03 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 11:28:48 +0100 | kuribas | (~user@2a02:1808:c7:cecf:a041:fccb:9242:86e9) (Ping timeout: 260 seconds) |
| 2025-12-03 11:30:34 +0100 | dhil | (~dhil@5.151.29.137) dhil |
| 2025-12-03 11:31:20 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 11:36:29 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-03 11:36:42 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-03 11:40:44 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 11:40:59 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 11:43:40 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-03 11:52:20 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 11:56:55 +0100 | trickard_ | trickard |
| 2025-12-03 11:56:59 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 12:01:07 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9a8d:d213:9a6f:7468) |
| 2025-12-03 12:01:21 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 250 seconds) |
| 2025-12-03 12:04:05 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 12:04:10 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 12:08:20 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-03 12:09:05 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 12:09:38 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 272 seconds) |
| 2025-12-03 12:11:30 +0100 | gawen | (~gawen@user/gawen) (Client Quit) |
| 2025-12-03 12:15:20 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2025-12-03 12:16:31 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 12:20:51 +0100 | trickard__ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 12:21:16 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 244 seconds) |
| 2025-12-03 12:24:15 +0100 | Inline | (~inlinE@2001-4dd3-7fc8-0-f57-6413-8f27-9a87.ipv6dyn.netcologne.de) Inline |
| 2025-12-03 12:27:57 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 12:32:58 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-12-03 12:35:29 +0100 | trickard__ | trickard |
| 2025-12-03 12:43:07 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-12-03 12:44:07 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 12:48:35 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-03 12:57:07 +0100 | <__monty__> | edwardk: Do the AI videos set the tone for future content on your YouTube? |
| 2025-12-03 13:00:56 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 13:01:10 +0100 | <Leary> | Looks like his account got hacked? |
| 2025-12-03 13:01:22 +0100 | <__monty__> | That's what I'm hoping. |
| 2025-12-03 13:01:53 +0100 | <__monty__> | But maybe it's to show off the AI hardware they're working on? |
| 2025-12-03 13:05:35 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-03 13:08:46 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-12-03 13:10:48 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 13:13:30 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) |
| 2025-12-03 13:15:34 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 13:16:03 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-03 13:17:52 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117) (Ping timeout: 246 seconds) |
| 2025-12-03 13:23:21 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-12-03 13:24:54 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-12-03 13:31:34 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-12-03 13:34:14 +0100 | yin | (~zero@user/zero) (Ping timeout: 260 seconds) |
| 2025-12-03 13:46:20 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: WeeChat 4.8.0) |
| 2025-12-03 13:48:41 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-03 13:50:34 +0100 | causal | (~eric@50.46.156.145) (Quit: WeeChat 4.6.3) |
| 2025-12-03 14:02:44 +0100 | <lucabtz> | is there a way i can improve the Day type here https://paste.tomsmeding.com/pO7MeUTu |
| 2025-12-03 14:03:38 +0100 | <lucabtz> | i dont like it has a lot of parameters with no names, but records dont seem to work with existential types (i can put them but i still need to pattern match it seems) |
| 2025-12-03 14:03:55 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2025-12-03 14:04:43 +0100 | arandombit | (~arandombi@2603:7000:4600:ffbe:28ad:499f:4e0e:de68) |
| 2025-12-03 14:04:43 +0100 | arandombit | (~arandombi@2603:7000:4600:ffbe:28ad:499f:4e0e:de68) (Changing host) |
| 2025-12-03 14:04:43 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2025-12-03 14:04:48 +0100 | yin | (~zero@user/zero) zero |
| 2025-12-03 14:07:29 +0100 | akegalj | (~akegalj@78-0-210-92.adsl.net.t-com.hr) (Ping timeout: 260 seconds) |
| 2025-12-03 14:09:19 +0100 | <tomsmeding> | what doesn't work about records? |
| 2025-12-03 14:09:51 +0100 | <Leary> | lucabtz: I would still name the fields, then use `NamedFieldPuns` when pattern matching. It's just selectors that won't work. |
| 2025-12-03 14:09:59 +0100 | <tomsmeding> | ah |
| 2025-12-03 14:12:07 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 246 seconds) |
| 2025-12-03 14:13:54 +0100 | <lucabtz> | yeah selectors dont work |
| 2025-12-03 14:14:10 +0100 | <lucabtz> | sorry i wasnt very clear |
| 2025-12-03 14:14:23 +0100 | <lucabtz> | but yeah your idea seems good, at least for documentation purpose |
| 2025-12-03 14:17:06 +0100 | AlexNoo_ | AlexNoo |
| 2025-12-03 14:17:45 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-03 14:17:55 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 240 seconds) |
| 2025-12-03 14:18:08 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-03 14:18:49 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 14:19:03 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 14:20:04 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 14:20:09 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-12-03 14:23:27 +0100 | akegalj | (~akegalj@141-138-27-206.dsl.iskon.hr) |
| 2025-12-03 14:43:43 +0100 | <lucabtz> | Leary: https://paste.tomsmeding.com/fuEJWIam looks great! |
| 2025-12-03 14:44:41 +0100 | <lucabtz> | day03 = Day "2025-3" parseInput solve1 solve2 (testInput, testOutput) |
| 2025-12-03 14:44:51 +0100 | <lucabtz> | now it is only the construction which looks ugly |
| 2025-12-03 14:45:46 +0100 | <lucabtz> | though i could initialize them with the brackets i guess |
| 2025-12-03 14:48:28 +0100 | <Leary> | You can also use `NamedFieldPuns` in construction if you name your functions correspondingly. |
| 2025-12-03 14:49:29 +0100 | <__monty__> | Is there a fold/mapAccum where you can shortcircuit the folding and return the tail unaltered? |
| 2025-12-03 14:49:57 +0100 | <lucabtz> | yeah i realized |
| 2025-12-03 14:50:10 +0100 | <lucabtz> | i put NamedFieldPuns on the whole cabal project now |
| 2025-12-03 14:54:03 +0100 | <lucabtz> | actually i cant get it to work in construction |
| 2025-12-03 14:54:35 +0100 | trickard_ | trickard |
| 2025-12-03 14:56:19 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 15:01:44 +0100 | <lucabtz> | having colliding names does work as nicely because i need to import the record selectors for the construction to work |
| 2025-12-03 15:02:26 +0100 | <lucabtz> | but when importing the selector it will collide with the other thing named the same |
| 2025-12-03 15:03:40 +0100 | <Leary> | `NoFieldSelectors` might help |
| 2025-12-03 15:04:01 +0100 | <merijn> | NoFieldSelectors is bae |
| 2025-12-03 15:05:06 +0100 | divlamir_ | (~divlamir@user/divlamir) divlamir |
| 2025-12-03 15:05:18 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-03 15:05:38 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 15:06:03 +0100 | <lucabtz> | great |
| 2025-12-03 15:07:09 +0100 | <lucabtz> | i will try |
| 2025-12-03 15:07:12 +0100 | <lucabtz> | thank you again |
| 2025-12-03 15:07:16 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 256 seconds) |
| 2025-12-03 15:07:17 +0100 | divlamir_ | divlamir |
| 2025-12-03 15:08:15 +0100 | akegalj | (~akegalj@141-138-27-206.dsl.iskon.hr) (Ping timeout: 240 seconds) |
| 2025-12-03 15:09:58 +0100 | wbooze | (~inline@cgn-195-14-221-120.nc.de) |
| 2025-12-03 15:10:22 +0100 | wbooze | Guest6657 |
| 2025-12-03 15:14:18 +0100 | leah2 | (~leah@vuxu.org) (Quit: Sprechen Sie noch? Wird noch gesprochen? Ich trenne.) |
| 2025-12-03 15:15:35 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-12-03 15:15:53 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-03 15:16:54 +0100 | <__monty__> | `mapAccumL` with a Maybe for the state to indicate when the map should fall back to basically `id` feels wrong. |
| 2025-12-03 15:17:28 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2025-12-03 15:17:29 +0100 | leah2 | (~leah@vuxu.org) leah2 |
| 2025-12-03 15:17:41 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-12-03 15:21:01 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 15:27:59 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) |
| 2025-12-03 15:28:29 +0100 | <kuribas`> | __monty__: sounds like you want mapAccumR |
| 2025-12-03 15:28:32 +0100 | <kuribas`> | :t mapAccumR |
| 2025-12-03 15:28:35 +0100 | <lambdabot> | Traversable t => (s -> a -> (s, b)) -> s -> t a -> (s, t b) |
| 2025-12-03 15:29:04 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) (Client Quit) |
| 2025-12-03 15:29:16 +0100 | <kuribas`> | err |
| 2025-12-03 15:29:23 +0100 | <__monty__> | I don't think so. Neither direction allows "shortcutting". |
| 2025-12-03 15:29:38 +0100 | <kuribas`> | scanr? |
| 2025-12-03 15:30:04 +0100 | <kuribas`> | scanr over tails... |
| 2025-12-03 15:30:15 +0100 | <__monty__> | I don't see how that relates. |
| 2025-12-03 15:30:28 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) |
| 2025-12-03 15:30:37 +0100 | Googulator68 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 15:30:44 +0100 | Googulator | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 15:30:44 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-03 15:31:00 +0100 | <__monty__> | The output is the same structure and length as the input. I'm pushing a value down into a structure, based on a condition I either push another value down or stop pushing any values down. |
| 2025-12-03 15:31:08 +0100 | Googulator68 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Client Quit) |
| 2025-12-03 15:31:13 +0100 | Googulator40 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 15:31:19 +0100 | <tomsmeding> | do you have a specific reason for wanting this to be a pre-existing combinator? |
| 2025-12-03 15:31:59 +0100 | <__monty__> | Intellectual curiosity mostly. It seems like something that could have an elegant combinator. |
| 2025-12-03 15:32:17 +0100 | <tomsmeding> | I don't think any of the standard L/R combinators apply here -- the L ones because they continue recursing regardless, and the R ones because the information flow is the wrong way |
| 2025-12-03 15:32:43 +0100 | <tomsmeding> | you can implement this with a foldr in a way similar that you can build foldl using foldr |
| 2025-12-03 15:32:56 +0100 | <tomsmeding> | but I don't think it's a pre-existing combinator, at least in base |
| 2025-12-03 15:33:07 +0100 | Guest35 | (~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d) (Write error: Broken pipe) |
| 2025-12-03 15:33:26 +0100 | <__monty__> | Yep, but foldr and mapAccumL both have to process every element of the structure, no? Since I don't want to outright drop the tail. |
| 2025-12-03 15:33:40 +0100 | <kuribas`> | __monty__: not foldr |
| 2025-12-03 15:33:57 +0100 | <tomsmeding> | yeah thinking about this more I'm not sure anymore that you can do this using foldr |
| 2025-12-03 15:34:11 +0100 | <__monty__> | tomsmeding: You can implement mapAccumL using foldr. |
| 2025-12-03 15:34:15 +0100 | <tomsmeding> | I know |
| 2025-12-03 15:34:29 +0100 | <tomsmeding> | base's foldl is implemented using foldr |
| 2025-12-03 15:34:46 +0100 | <tomsmeding> | but while that construction is cute, I don't think you get access to the unadulterated tail |
| 2025-12-03 15:35:01 +0100 | <__monty__> | kuribas`: Show me a foldr that doesn't drop any values and also doesn't visit a tail of several values. |
| 2025-12-03 15:35:58 +0100 | <__monty__> | Yeah, with foldr you can either process every element, or drop whatever's left. |
| 2025-12-03 15:36:23 +0100 | <tomsmeding> | yes I think so |
| 2025-12-03 15:37:20 +0100 | <sprout> | you can do a scan instead of a fold and lazily stop evaluating when you hit something |
| 2025-12-03 15:37:26 +0100 | <__monty__> | But that's not the "shortcutting" I'm looking for. I want to recurse up to a point and at that point return the tail unprocessed. The latter is just for efficiency rather than correctness. |
| 2025-12-03 15:37:48 +0100 | <tomsmeding> | sprout: scan doesn't give you access to the actual original tail |
| 2025-12-03 15:37:53 +0100 | <__monty__> | sprout: Again, that leaves me with only part of the input, no? |
| 2025-12-03 15:37:55 +0100 | akegalj | (~akegalj@141-138-27-206.dsl.iskon.hr) |
| 2025-12-03 15:37:57 +0100 | <sprout> | hmyah |
| 2025-12-03 15:37:58 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-03 15:39:45 +0100 | <sprout> | put it in a monad? I feel like parser combinators will often return the unprocessed tokens on an error, so you should be able to reuse the idiom |
| 2025-12-03 15:40:24 +0100 | <tomsmeding> | then you just punt the problem to the implementation of that monad |
| 2025-12-03 15:40:33 +0100 | <sprout> | yah |
| 2025-12-03 15:45:27 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 15:47:39 +0100 | Guest6657 | (~inline@cgn-195-14-221-120.nc.de) (Quit: Leaving) |
| 2025-12-03 15:51:23 +0100 | wbooze | (~inline@cgn-195-14-221-120.nc.de) Inline |
| 2025-12-03 15:59:30 +0100 | <kuribas`> | > foldr (\(x:xs) cont -> \xs2 -> if (x > 5) then (x:xs) else (x*2) : cont xs) id (tails [1..10]) [] |
| 2025-12-03 15:59:36 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 15:59:41 +0100 | <kuribas`> | ^ __monty__ |
| 2025-12-03 16:00:00 +0100 | <kuribas`> | obviously needs some lambdacase. |
| 2025-12-03 16:00:45 +0100 | spew | (~spew@user/spew) (Ping timeout: 245 seconds) |
| 2025-12-03 16:01:28 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 244 seconds) |
| 2025-12-03 16:01:59 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Quit: Fading out...) |
| 2025-12-03 16:02:40 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-12-03 16:03:03 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-03 16:04:23 +0100 | <kuribas`> | > take 10 $ foldr (\(x:xs) cont -> \xs2 -> if (x > 5) then (x:xs) else (x*2) : cont xs) id (tails [1..]) [] |
| 2025-12-03 16:04:26 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 16:04:39 +0100 | <kuribas`> | --proof that it doesn't visit the tail :) |
| 2025-12-03 16:04:45 +0100 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
| 2025-12-03 16:05:29 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-12-03 16:05:52 +0100 | <__monty__> | Only shortcoming is if the condition is never fulfilled, needs more case analysis. |
| 2025-12-03 16:07:06 +0100 | <__monty__> | Feels a lot like span/break and folding the fst. |
| 2025-12-03 16:07:41 +0100 | <__monty__> | Hmm, no the span/break would need to carry state forward. |
| 2025-12-03 16:08:38 +0100 | <kuribas`> | Actually, this doesn't use the continuation ... |
| 2025-12-03 16:08:41 +0100 | <kuribas`> | > foldr (\(x:xs) xs2 -> if (x > 5) then (x:xs) else (x*2) : xs2) [] (tails [1..10]) |
| 2025-12-03 16:08:44 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 16:09:08 +0100 | <kuribas`> | You can use the continuation if you need to pass some state. |
| 2025-12-03 16:09:40 +0100 | wbooze | (~inline@cgn-195-14-221-120.nc.de) (Quit: Leaving) |
| 2025-12-03 16:10:08 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 16:10:27 +0100 | <__monty__> | > foldr (\(x:xs) xs2 -> if False then (x:xs) else (x*2) : xs2) [] (tails [1..10]) |
| 2025-12-03 16:10:30 +0100 | <lambdabot> | [2,4,6,8,10,12,14,16,18,20*Exception: <interactive>:3:8-59: Non-exhaustive p... |
| 2025-12-03 16:10:39 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-03 16:10:44 +0100 | <__monty__> | This is the missing case analysis I was referring to. |
| 2025-12-03 16:10:56 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-03 16:10:56 +0100 | <kuribas`> | > foldr (\(x:xs) cont s -> if (s > 7) then (x:xs) else (x*2) : cont (s+x)) (const []) (tails [1..10]) 0 |
| 2025-12-03 16:11:00 +0100 | <__monty__> | But the idea works. |
| 2025-12-03 16:11:00 +0100 | <lambdabot> | [2,4,6,8,5,6,7,8,9,10] |
| 2025-12-03 16:12:22 +0100 | califax_ | (~califax@user/califx) califx |
| 2025-12-03 16:13:49 +0100 | chexum_ | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-12-03 16:14:06 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 272 seconds) |
| 2025-12-03 16:14:06 +0100 | califax | (~califax@user/califx) (Ping timeout: 272 seconds) |
| 2025-12-03 16:14:06 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Ping timeout: 272 seconds) |
| 2025-12-03 16:14:07 +0100 | califax_ | califax |
| 2025-12-03 16:15:02 +0100 | <lucabtz> | kuribas` if there is no state can't you just use break |
| 2025-12-03 16:15:15 +0100 | <kuribas`> | break? |
| 2025-12-03 16:15:27 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-12-03 16:15:40 +0100 | <lucabtz> | or span |
| 2025-12-03 16:15:59 +0100 | <kuribas`> | sure |
| 2025-12-03 16:16:26 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-12-03 16:16:43 +0100 | <kuribas`> | > let (xs, ys) = break (> 5) [1..10] in map (*2) xs ++ ys |
| 2025-12-03 16:16:46 +0100 | <lambdabot> | [2,4,6,8,10,6,7,8,9,10] |
| 2025-12-03 16:16:54 +0100 | <lucabtz> | yep |
| 2025-12-03 16:21:12 +0100 | aljazmc | (~aljazmc@user/aljazmc) aljazmc |
| 2025-12-03 16:22:30 +0100 | st_aldini | (~Thunderbi@2605:a601:a07c:7400:6e26:f360:f11d:472c) (Quit: st_aldini) |
| 2025-12-03 16:22:58 +0100 | st_aldini | (~Thunderbi@2605:a601:a07c:7400:6e26:f360:f11d:472c) st_aldini |
| 2025-12-03 16:26:09 +0100 | akegalj | (~akegalj@141-138-27-206.dsl.iskon.hr) (Quit: leaving) |
| 2025-12-03 16:27:23 +0100 | <__monty__> | Yes, already mentioned that. |
| 2025-12-03 16:27:51 +0100 | <kuribas`> | > foldr (\(x:xs) xs2 -> if False then (x:xs) else (x*2) : xs2) [] (init $ tails [1..10]) -- __monty__ |
| 2025-12-03 16:27:54 +0100 | <lambdabot> | [2,4,6,8,10,12,14,16,18,20] |
| 2025-12-03 16:28:37 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-12-03 16:29:14 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-12-03 16:30:47 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 16:31:10 +0100 | <__monty__> | Yeah, that works. |
| 2025-12-03 16:32:44 +0100 | <__monty__> | "Foldr the init of the tails" is not quite the elegance I was hoping for but it does make foldr more useful still. |
| 2025-12-03 16:33:02 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 16:33:59 +0100 | Googulator40 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Ping timeout: 250 seconds) |
| 2025-12-03 16:35:51 +0100 | <kuribas`> | :t tails1 |
| 2025-12-03 16:35:54 +0100 | <lambdabot> | error: [GHC-88464] |
| 2025-12-03 16:35:54 +0100 | <lambdabot> | Variable not in scope: tails1 |
| 2025-12-03 16:35:54 +0100 | <lambdabot> | Suggested fix: |
| 2025-12-03 16:38:06 +0100 | <kuribas`> | https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-List.html#v:tails1 |
| 2025-12-03 16:39:54 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-03 16:40:02 +0100 | <kuribas`> | removed apparently... |
| 2025-12-03 16:41:05 +0100 | <__monty__> | Probably because it's partial? |
| 2025-12-03 16:41:18 +0100 | <__monty__> | Oh, it's not. |
| 2025-12-03 16:44:30 +0100 | <kuribas`> | ah no, it's added |
| 2025-12-03 16:44:33 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) |
| 2025-12-03 16:45:34 +0100 | <kuribas`> | __monty__: tbf if you really care about performance, you shouldn't use linked lists. |
| 2025-12-03 16:46:53 +0100 | <__monty__> | I wasn't really asking about lists though. More like anything Foldable or Somethingable if folds are not a powerful enough concept to capture the behavior. |
| 2025-12-03 16:48:12 +0100 | <Leary> | `Witherable`, probably. |
| 2025-12-03 16:49:33 +0100 | <Leary> | Well, if you want to drop any elements. Maybe `Traversable` is enough if you don't. |
| 2025-12-03 16:49:57 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 250 seconds) |
| 2025-12-03 16:50:26 +0100 | <__monty__> | I'm open to suggestions for a data structure for the specific case of pushing a value into the flat structure from the front and stopping when the value being pushed is smaller than the next. Think of a row of marbles, the first marble smaller than the one pushing against it falls out. |
| 2025-12-03 16:50:30 +0100 | <kuribas`> | __monty__: folds are isomorphic to a list |
| 2025-12-03 16:50:38 +0100 | <kuribas`> | :t toList |
| 2025-12-03 16:50:41 +0100 | <lambdabot> | Foldable t => t a -> [a] |
| 2025-12-03 16:51:37 +0100 | <Leary> | __monty__: In that case, why flat? It really sounds like you want a heap or a set. |
| 2025-12-03 16:52:16 +0100 | Jackneill | (~Jackneill@178-164-177-218.pool.digikabel.hu) (Read error: Connection reset by peer) |
| 2025-12-03 16:52:21 +0100 | <__monty__> | In my case the extra structure isn't necessary. |
| 2025-12-03 16:52:28 +0100 | Jackneill | (~Jackneill@178-164-177-218.pool.digikabel.hu) Jackneill |
| 2025-12-03 16:55:13 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-03 16:56:04 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 16:56:08 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-12-03 16:58:18 +0100 | acidjnk | (~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2025-12-03 17:02:28 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 255 seconds) |
| 2025-12-03 17:02:51 +0100 | tromp | (~textual@2001:1c00:3487:1b00:a4ed:9e46:fd5d:6b4e) |
| 2025-12-03 17:04:39 +0100 | <tomsmeding> | __monty__: if the values have a well-defined ordering, a binary tree will give you O(log(n)) insertion instead of O(n) |
| 2025-12-03 17:04:43 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 2025-12-03 17:04:56 +0100 | <tomsmeding> | but the fact that you're asking about a list suggests you have no such ordering :) |
| 2025-12-03 17:05:43 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-03 17:05:45 +0100 | Googulator56 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 17:05:47 +0100 | Googulator88 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 17:06:01 +0100 | <tomsmeding> | (that data structure is Data.Set) |
| 2025-12-03 17:16:21 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 17:17:58 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-12-03 17:25:15 +0100 | acidjnk | (~acidjnk@p200300d6e71719231986af8ebf40e0fc.dip0.t-ipconnect.de) acidjnk |
| 2025-12-03 17:28:55 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-03 17:30:19 +0100 | <tomsmeding> | can I override GHC's arity analysis to force a particular function to have lower arity than GHC would otherwise infer? |
| 2025-12-03 17:30:50 +0100 | <tomsmeding> | I have some data that I can already compute based on only the first argument that I would like to share over multiple calls that have the same first argument, and GHC isn't doing it |
| 2025-12-03 17:31:20 +0100 | <Lycurgus> | wo TH or nuthin i presume |
| 2025-12-03 17:31:22 +0100 | <tomsmeding> | I can force GHC to do what I want by making the "inner function" NOINLINE (at which point the (inlined) "outer function" does the proper sharing), but that feels like a hack |
| 2025-12-03 17:32:33 +0100 | <tomsmeding> | (I don't see how TH is relevant here) |
| 2025-12-03 17:32:45 +0100 | <Lycurgus> | nor "nuthin"? |
| 2025-12-03 17:32:55 +0100 | <tomsmeding> | well, presumably something is relevant here, yes |
| 2025-12-03 17:33:28 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-03 17:33:37 +0100 | <Lycurgus> | i couild expand as a very rude name of this category of quety has occured to me but being a real person i know better |
| 2025-12-03 17:34:05 +0100 | <Leary> | tomsmeding: Does it work if you push the latter args into lambdas and bang the shared binding? |
| 2025-12-03 17:34:29 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Remote host closed the connection) |
| 2025-12-03 17:34:35 +0100 | <Lycurgus> | *query |
| 2025-12-03 17:34:56 +0100 | aljazmc | (~aljazmc@user/aljazmc) aljazmc |
| 2025-12-03 17:34:58 +0100 | <Lycurgus> | *could |
| 2025-12-03 17:35:27 +0100 | <tomsmeding> | Leary: doesn't seem to; they were already in a separate lambda (within a 'let' that defines the shared binding), but adding a ! doesn't seem to help |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2025-12-03 17:35:50 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-12-03 17:35:53 +0100 | <Leary> | `NOINLINE` it is, then. |
| 2025-12-03 17:36:33 +0100 | <tomsmeding> | the downside is that that makes performance slightly worse if the function is only called once |
| 2025-12-03 17:36:45 +0100 | <tomsmeding> | but I'll just have to live with that I suppose :) |
| 2025-12-03 17:37:06 +0100 | <tomsmeding> | (it's a 2x improvement when called many times, at the cost of a 10% slowdown when called once) |
| 2025-12-03 17:37:32 +0100 | <Leary> | Oh, you're putting that on the inner /function/? Why not on the shared value? |
| 2025-12-03 17:37:50 +0100 | <tomsmeding> | how do you suggest I put it on the shared value? |
| 2025-12-03 17:38:11 +0100 | <tomsmeding> | the function looks like: \sh -> let suffixes = ... in \i -> ...body... |
| 2025-12-03 17:38:46 +0100 | <tomsmeding> | putting the (\i -> body) in a separate binding and NOINLINE-marking that binding seems to ensure that 'suffixes' is properly shared over multiple adjacent calls |
| 2025-12-03 17:39:21 +0100 | <Leary> | `let { {-# NOINLINE suffixes #-}; suffixes = ... } in \i -> ...` |
| 2025-12-03 17:39:58 +0100 | <tomsmeding> | doesn't work |
| 2025-12-03 17:40:28 +0100 | <Leary> | Weird. I've used it in a `where` block. |
| 2025-12-03 17:40:45 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-12-03 17:40:45 +0100 | <tomsmeding> | I recall that it worked before, in this very function -- something broke it |
| 2025-12-03 17:41:20 +0100 | <tomsmeding> | anyway, I'll just live with the 10% :) |
| 2025-12-03 17:41:25 +0100 | <tomsmeding> | thanks for thinking along |
| 2025-12-03 17:43:41 +0100 | <fgarcia> | /buffer 2 |
| 2025-12-03 17:47:17 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
| 2025-12-03 17:49:38 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) |
| 2025-12-03 17:50:45 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Quit: Leaving) |
| 2025-12-03 17:56:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-03 18:02:45 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-12-03 18:02:46 +0100 | trickard_ | trickard |
| 2025-12-03 18:03:40 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2025-12-03 18:05:43 +0100 | Googulator55 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) |
| 2025-12-03 18:05:51 +0100 | Googulator56 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 18:07:23 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-12-03 18:07:31 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 250 seconds) |
| 2025-12-03 18:09:15 +0100 | ouilemur | (~jgmerritt@user/ouilemur) (Quit: WeeChat 4.7.2) |
| 2025-12-03 18:09:46 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) (Ping timeout: 246 seconds) |
| 2025-12-03 18:13:19 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) |
| 2025-12-03 18:13:39 +0100 | spew | (~spew@user/spew) (Ping timeout: 260 seconds) |
| 2025-12-03 18:15:11 +0100 | <ski> | @hoogle (a -> [a] -> b -> b) -> b -> [a] -> b |
| 2025-12-03 18:15:11 +0100 | <lambdabot> | No results found |
| 2025-12-03 18:15:16 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-03 18:17:11 +0100 | mikess | (~sam@user/mikess) mikess |
| 2025-12-03 18:19:50 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-12-03 18:23:51 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-03 18:26:23 +0100 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2025-12-03 18:28:16 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla |
| 2025-12-03 18:35:51 +0100 | Googulator55 | (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 18:36:04 +0100 | Googulator55 | (~Googulato@85-238-68-117.pool.digikabel.hu) |
| 2025-12-03 18:39:53 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 260 seconds) |
| 2025-12-03 18:40:25 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-03 18:41:49 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-12-03 18:41:54 +0100 | pr1sm | (~pr1sm@24.91.163.31) |
| 2025-12-03 18:42:18 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-12-03 18:47:16 +0100 | pr1sm | (~pr1sm@24.91.163.31) (Remote host closed the connection) |
| 2025-12-03 18:47:32 +0100 | Jackneill | (~Jackneill@178-164-177-218.pool.digikabel.hu) (Remote host closed the connection) |
| 2025-12-03 18:47:42 +0100 | Jackneill | (~Jackneill@178-164-177-218.pool.digikabel.hu) Jackneill |
| 2025-12-03 18:56:08 +0100 | divlamir_ | (~divlamir@user/divlamir) divlamir |
| 2025-12-03 18:56:37 +0100 | annamalai | (~annamalai@157.32.222.111) (Read error: Connection reset by peer) |
| 2025-12-03 18:56:57 +0100 | annamalai | (~annamalai@157.32.222.111) annamalai |
| 2025-12-03 18:59:01 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 255 seconds) |
| 2025-12-03 18:59:01 +0100 | divlamir_ | divlamir |
| 2025-12-03 19:02:09 +0100 | wbooze | (~wbooze@2001-4dd7-9813-0-5961-9b55-d1ca-8eee.ipv6dyn.netcologne.de) Inline |
| 2025-12-03 19:05:22 +0100 | Anarchos | (~Anarchos@91-161-254-16.subs.proxad.net) Anarchos |
| 2025-12-03 19:05:46 +0100 | Googulator55 | (~Googulato@85-238-68-117.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-03 19:08:44 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 19:09:08 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 19:09:55 +0100 | mulk | (~mulk@pd9514972.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-12-03 19:14:38 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-12-03 19:18:11 +0100 | mulk | (~mulk@pd9514972.dip0.t-ipconnect.de) mulk |
| 2025-12-03 19:23:38 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 19:23:46 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-12-03 19:23:52 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-03 19:25:53 +0100 | <__monty__> | tomsmeding: That part of the structure is necessary. Ordering of the elements is significant. |
| 2025-12-03 19:27:33 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-12-03 19:31:25 +0100 | Anarchos | (~Anarchos@91-161-254-16.subs.proxad.net) () |
| 2025-12-03 19:31:52 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-03 19:33:59 +0100 | skum | (~skum@user/skum) (Quit: WeeChat 4.7.2) |
| 2025-12-03 19:34:22 +0100 | skum | (~skum@user/skum) skum |
| 2025-12-03 19:37:36 +0100 | ouilemur | (~jgmerritt@user/ouilemur) ouilemur |
| 2025-12-03 19:42:46 +0100 | <haskellbridge> | <Zemyla> If f is representational and Applicative, then does that necessarily imply that liftA2 coerce a b = coerce a <*> b? |
| 2025-12-03 19:44:24 +0100 | <tomsmeding> | well, `liftA2 f x y = f <$> x <*> y` is a law |
| 2025-12-03 19:45:33 +0100 | <tomsmeding> | so it sounds like you're asking: if f's argument is representational, do we have `fmap coerce x = coerce x` for `x :: f (a -> b)` |
| 2025-12-03 19:46:11 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-12-03 19:47:48 +0100 | <tomsmeding> | which sounds like it _ought_ to be true, but I don't know what to conclude that from |
| 2025-12-03 19:48:48 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-03 19:49:01 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-03 19:49:56 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-03 20:01:45 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-03 20:03:15 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-03 20:03:15 +0100 | ljdarj1 | ljdarj |
| 2025-12-03 20:07:28 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-03 20:07:41 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
