Newest at the top
2024-09-04 02:16:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-04 02:14:19 +0200 | Fooo | (~Square@user/square) (Ping timeout: 252 seconds) |
2024-09-04 02:10:53 +0200 | Square2 | (~Square4@user/square) |
2024-09-04 02:10:49 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
2024-09-04 02:08:05 +0200 | acidjnk_new | (~acidjnk@p200300d6e72cfb5469ca77b0637d5192.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
2024-09-04 02:05:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:3618:2400:ae18:e1a3) (Ping timeout: 246 seconds) |
2024-09-04 02:05:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-04 02:02:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2024-09-04 02:00:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-04 02:00:46 +0200 | jespada | (~jespada@r190-64-133-178.su-static.adinet.com.uy) (Ping timeout: 252 seconds) |
2024-09-04 01:58:11 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
2024-09-04 01:54:30 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 246 seconds) |
2024-09-04 01:51:47 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
2024-09-04 01:50:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
2024-09-04 01:45:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-04 01:42:25 +0200 | bliminse | (~bliminse@user/bliminse) |
2024-09-04 01:36:13 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
2024-09-04 01:34:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-04 01:30:20 +0200 | bliminse | (~bliminse@user/bliminse) (Ping timeout: 252 seconds) |
2024-09-04 01:29:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-04 01:29:07 +0200 | acidjnk_new | (~acidjnk@p200300d6e72cfb5469ca77b0637d5192.dip0.t-ipconnect.de) |
2024-09-04 01:27:21 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
2024-09-04 01:24:52 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-09-04 01:21:00 +0200 | <davean> | Just I better not care about any specific improvements |
2024-09-04 01:20:31 +0200 | <davean> | but if someone wants to abstractly think about some business logic, I'm happy to expect it to be generally improved |
2024-09-04 01:20:26 +0200 | <c_wraith> | I mean, in that case that's the code I want to run. Something simple where performance isn't critical |
2024-09-04 01:20:12 +0200 | <davean> | It should never be terrible! |
2024-09-04 01:20:04 +0200 | <davean> | c_wraith: right, for at least core stuff. I'm happy when I have a lot of code saying "it'll do a decent job on cleaning up this code that runs only a few times and isn't core" |
2024-09-04 01:19:56 +0200 | jespada | (~jespada@r190-64-133-178.su-static.adinet.com.uy) |
2024-09-04 01:19:49 +0200 | oo_miguel | (~Thunderbi@78.10.207.45) (Ping timeout: 248 seconds) |
2024-09-04 01:19:31 +0200 | <c_wraith> | My general philosophy is to write the code I want to run. Not some other code that I hope the compiler magically fixes for me. :) |
2024-09-04 01:18:50 +0200 | <davean> | Optimizations are great, but they're there to clean up your average code and so should target the best average improvements. Thus they're prone to tunning, and changes. Core peroformance critical code is best done directly. |
2024-09-04 01:18:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-04 01:17:04 +0200 | <monochrom> | That's fair. |
2024-09-04 01:15:52 +0200 | <davean> | So I will repeat that IME this sort of thing is very unstable across GHC versions |
2024-09-04 01:15:18 +0200 | <Axman6> | {} -> [] |
2024-09-04 01:14:55 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 252 seconds) |
2024-09-04 01:14:47 +0200 | <monochrom> | "only one way to find out" :) |
2024-09-04 01:14:43 +0200 | <Axman6> | not sure |
2024-09-04 01:14:13 +0200 | <c_wraith> | do literals get compiled like that? |
2024-09-04 01:13:49 +0200 | <Axman6> | if the literal {a,b,c,d} turns into build (\(*) z -> a * b * c * d * z) then it might get optimised away |
2024-09-04 01:13:38 +0200 | <davean> | This is also the sort of thing that tends not to be stable across GHC versions |
2024-09-04 01:13:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-04 01:12:39 +0200 | <davean> | c_wraith: right |
2024-09-04 01:12:29 +0200 | <davean> | its fixed enough I'd have to look at what the optimizer did, it can handle some cases like that from pure inlining. |
2024-09-04 01:12:28 +0200 | <c_wraith> | It's possible a foldr/build would do something useful there, though, as that would erase the recursion entirely and GHC would just see it as a few function applications. |
2024-09-04 01:12:08 +0200 | <davean> | One could even add a RULE for that if one wanted it to work right now for sure. |
2024-09-04 01:11:06 +0200 | <c_wraith> | I'm pretty sure GHC doesn't have a pass that does that, but it certainly *could* treat fixed-length list literals specially for optimization purposes. I'm just not sure it'd be worth the implementation cost. |
2024-09-04 01:11:03 +0200 | <davean> | well it knows for sure the list is finite in that case. |
2024-09-04 01:10:27 +0200 | vglfr | (~vglfr@c-73-163-164-68.hsd1.md.comcast.net) |