Newest at the top
2025-10-16 20:22:09 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-10-16 20:22:01 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
2025-10-16 20:21:48 +0200 | <mreh> | in core, seq a b is translated to something like case a of... isn't it? |
2025-10-16 20:20:12 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 272 seconds) |
2025-10-16 20:20:06 +0200 | <ski> | yes, this is reasoning from the denotational meaning of `seq', not about what a particular implementation does |
2025-10-16 20:18:03 +0200 | <mreh> | ski: was he reading from the spec, because empirically I've never seen that behaviour |
2025-10-16 20:16:44 +0200 | gustrb | (~gustrb@191.243.134.87) |
2025-10-16 20:16:03 +0200 | trickard_ | (~trickard@cpe-57-98-47-163.wireline.com.au) |
2025-10-16 20:15:50 +0200 | trickard | (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-10-16 20:12:15 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 20:10:07 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 260 seconds) |
2025-10-16 20:07:46 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 246 seconds) |
2025-10-16 20:06:41 +0200 | Inline | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline |
2025-10-16 20:06:39 +0200 | <tomsmeding> | endokqr: right, I was asking because of the arch stuff: is your ghc from ghcup or from the system package manager? If the latter, and certainly if it's arch, get rid of that and use ghcup instead |
2025-10-16 20:06:21 +0200 | Inline | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Remote host closed the connection) |
2025-10-16 20:05:03 +0200 | <monochrom> | By default, GHC chooses static linking. Unless Arch's build of GHC, which chooses dynamic linking. |
2025-10-16 20:03:28 +0200 | <endokqr> | tomsmeding, one of the broken dependencies is base... but I have a vague feeling GHC is not supposed to look for these .p_dyn_hi files when it builds with profiling, but instead choose not to dynamically link but there's something in that process going wrong. not at all sure though. |
2025-10-16 20:02:25 +0200 | gustrb | (~gustrb@191.243.134.87) (Ping timeout: 256 seconds) |
2025-10-16 20:02:02 +0200 | Inline_ | Inline |
2025-10-16 20:02:02 +0200 | Guest6419 | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Killed (calcium.libera.chat (Nickname regained by services))) |
2025-10-16 20:02:02 +0200 | Inline | Guest6419 |
2025-10-16 20:01:12 +0200 | Inline_ | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline |
2025-10-16 20:00:34 +0200 | Inline_ | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Max SendQ exceeded) |
2025-10-16 20:00:22 +0200 | synchromesh | (~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) synchromesh |
2025-10-16 19:59:36 +0200 | Inline_ | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline |
2025-10-16 19:59:29 +0200 | synchromesh | (~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) (Read error: Connection reset by peer) |
2025-10-16 19:59:28 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-10-16 19:58:37 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 19:57:44 +0200 | <monochrom> | (even though in theory it could) |
2025-10-16 19:57:37 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 246 seconds) |
2025-10-16 19:57:35 +0200 | Everything | (~Everythin@46.96.48.125) (Quit: leaving) |
2025-10-16 19:57:24 +0200 | <monochrom> | Yeah pseq is the only that guarantees order. OTOH I haven't seen an empirical case of seq failing to solve laziness-caused unwanted space growth. |
2025-10-16 19:47:08 +0200 | kuribas | (~user@2a02-1810-2825-6000-5d7f-1d97-1f8d-30e0.ip6.access.telenet.be) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)) |
2025-10-16 19:43:58 +0200 | tromp | (~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-10-16 19:37:40 +0200 | karenw_ | (~karenw@user/karenw) karenw |
2025-10-16 19:34:12 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 19:33:57 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Client Quit) |
2025-10-16 19:33:27 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 19:28:06 +0200 | qqe | (~qqq@185.54.23.200) (Remote host closed the connection) |
2025-10-16 19:28:02 +0200 | Inline | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline |
2025-10-16 19:26:45 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds) |
2025-10-16 19:19:42 +0200 | <ski> | otoh, i think `pseq a b' has the guarantee that `a' will be reduced tp WHNF, at or before when `b' is |
2025-10-16 19:19:07 +0200 | ft | (~ft@p4fc2a207.dip0.t-ipconnect.de) ft |
2025-10-16 19:17:41 +0200 | <ski> | `seq (seq a b) c = seq a (seq b c) = seq b (seq a c)' would be another example |
2025-10-16 19:17:00 +0200 | <ski> | mreh : "your seq there simply guarantees that tmp will be in WHNF after your `in` clause is evaluated" -- i don't think this is the case. pretty sure `let ... in seq a b = seq a (let ... in b)'. similarly `(\... -> seq a b) (...) = seq a ((\... -> b) (...))'. so, `seq a's probably can be floated out of `let' and function bodies, as long as `a' is eventually evaluated when the body is |
2025-10-16 19:12:15 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 19:10:48 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds) |
2025-10-16 19:05:56 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-16 19:05:18 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds) |
2025-10-16 18:56:55 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |