2025/10/16

Newest at the top

2025-10-16 20:22:09 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-10-16 20:22:01 +0200bitdex(~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 +0200bitdex(~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 +0200gustrb(~gustrb@191.243.134.87)
2025-10-16 20:16:03 +0200trickard_(~trickard@cpe-57-98-47-163.wireline.com.au)
2025-10-16 20:15:50 +0200trickard(~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-10-16 20:12:15 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 20:10:07 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 260 seconds)
2025-10-16 20:07:46 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 246 seconds)
2025-10-16 20:06:41 +0200Inline(~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 +0200Inline(~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 +0200gustrb(~gustrb@191.243.134.87) (Ping timeout: 256 seconds)
2025-10-16 20:02:02 +0200Inline_Inline
2025-10-16 20:02:02 +0200Guest6419(~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Killed (calcium.libera.chat (Nickname regained by services)))
2025-10-16 20:02:02 +0200InlineGuest6419
2025-10-16 20:01:12 +0200Inline_(~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline
2025-10-16 20:00:34 +0200Inline_(~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Max SendQ exceeded)
2025-10-16 20:00:22 +0200synchromesh(~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) synchromesh
2025-10-16 19:59:36 +0200Inline_(~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline
2025-10-16 19:59:29 +0200synchromesh(~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) (Read error: Connection reset by peer)
2025-10-16 19:59:28 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-10-16 19:58:37 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 19:57:44 +0200 <monochrom> (even though in theory it could)
2025-10-16 19:57:37 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 246 seconds)
2025-10-16 19:57:35 +0200Everything(~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 +0200kuribas(~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 +0200tromp(~textual@2001:1c00:3487:1b00:d983:2af2:5deb:9bbb) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-10-16 19:37:40 +0200karenw_(~karenw@user/karenw) karenw
2025-10-16 19:34:12 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 19:33:57 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-10-16 19:33:27 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 19:28:06 +0200qqe(~qqq@185.54.23.200) (Remote host closed the connection)
2025-10-16 19:28:02 +0200Inline(~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) Inline
2025-10-16 19:26:45 +0200GdeVolpiano(~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 +0200ft(~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 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 19:10:48 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds)
2025-10-16 19:05:56 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-16 19:05:18 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds)
2025-10-16 18:56:55 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell