| 2024-06-12 00:09:15 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-06-12 00:11:00 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-06-12 00:13:19 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-06-12 00:14:05 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:3133:5b8c:8231:983f) |
| 2024-06-12 00:15:29 +0200 | falafel | (~falafel@2a0c:5a87:3103:ec01::62b8) |
| 2024-06-12 00:22:53 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-06-12 00:41:19 +0200 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-06-12 00:42:42 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 00:45:15 +0200 | falafel | (~falafel@2a0c:5a87:3103:ec01::62b8) (Ping timeout: 264 seconds) |
| 2024-06-12 00:51:37 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2024-06-12 00:56:06 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3306-1145-352a-53a6-543c-8dd1.rev.sfr.net) (Remote host closed the connection) |
| 2024-06-12 00:57:53 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) (Quit: ZNC 1.8.2+cygwin2 - https://znc.in) |
| 2024-06-12 00:58:45 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) |
| 2024-06-12 00:59:30 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-06-12 01:02:09 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-06-12 01:03:46 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 255 seconds) |
| 2024-06-12 01:07:41 +0200 | acidjnk | (~acidjnk@p200300d6e714dc992098ece2ddb096ca.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2024-06-12 01:08:01 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-06-12 01:12:46 +0200 | mei | (~mei@user/mei) |
| 2024-06-12 01:12:49 +0200 | dmj` | (uid72307@id-72307.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-12 01:14:38 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-12 01:24:54 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 255 seconds) |
| 2024-06-12 01:26:54 +0200 | dcoutts | (~duncan@185.110.91.104) |
| 2024-06-12 01:31:17 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-06-12 01:37:43 +0200 | zopsicle | (~zopsicle@2001:1c02:2f00:2f00:e4c:72df:ff5c:6bc2) (Quit: WeeChat 4.2.2) |
| 2024-06-12 01:42:36 +0200 | phma | (~phma@2001:5b0:211f:6dd8:9ffc:e310:b6f5:9e6f) (Read error: Connection reset by peer) |
| 2024-06-12 01:44:03 +0200 | phma | (~phma@2001:5b0:2143:81d8:b3f6:8ae3:d398:5c40) |
| 2024-06-12 01:50:23 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-06-12 01:50:52 +0200 | euleritian | (~euleritia@dynamic-176-000-199-065.176.0.pool.telefonica.de) |
| 2024-06-12 02:09:21 +0200 | vadparaszt | (~Rodney@176.254.244.83) (Ping timeout: 272 seconds) |
| 2024-06-12 02:10:16 +0200 | Rodney_ | (~Rodney@85.255.233.18) |
| 2024-06-12 02:11:09 +0200 | tertek_ | (~tertek@101.175.150.247) (Quit: %quit%) |
| 2024-06-12 02:11:27 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-06-12 02:11:34 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2024-06-12 02:12:11 +0200 | vadparaszt | (~Rodney@176.254.244.83) |
| 2024-06-12 02:12:51 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-06-12 02:13:10 +0200 | Rodney_ | (~Rodney@85.255.233.18) (Read error: No route to host) |
| 2024-06-12 02:13:26 +0200 | zlqrvx_ | (~zlqrvx@101.175.150.247) (Quit: %quit%) |
| 2024-06-12 02:13:47 +0200 | zlqrvx | (~zlqrvx@user/zlqrvx) |
| 2024-06-12 02:16:11 +0200 | dcoutts | (~duncan@185.110.91.104) (Ping timeout: 264 seconds) |
| 2024-06-12 02:22:03 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2024-06-12 02:27:17 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 240 seconds) |
| 2024-06-12 02:32:13 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-12 02:33:44 +0200 | califax | (~califax@user/califx) |
| 2024-06-12 02:40:28 +0200 | <cheater> | hello |
| 2024-06-12 02:40:37 +0200 | <cheater> | i heard this is a cult now is that true |
| 2024-06-12 02:41:13 +0200 | <EvanR> | "now" ? |
| 2024-06-12 02:41:29 +0200 | <cheater> | yeah there was a haskell hit piece |
| 2024-06-12 02:41:34 +0200 | <cheater> | recently on the news |
| 2024-06-12 02:41:44 +0200 | <cheater> | lol |
| 2024-06-12 02:41:49 +0200 | <EvanR> | what was the AOL keyword so I can find it |
| 2024-06-12 02:44:10 +0200 | <cheater> | https://www.wired.com/story/inside-the-cult-of-the-haskell-programmer/ |
| 2024-06-12 02:45:00 +0200 | <EvanR> | the cover art fails to compile |
| 2024-06-12 02:45:10 +0200 | <haskellbridge> | <sm> that's us starting to go mainstream |
| 2024-06-12 02:45:42 +0200 | <cheater> | wired isn't mainstream |
| 2024-06-12 02:47:51 +0200 | Guest40 | (~Guest40@c-98-37-216-109.hsd1.ca.comcast.net) |
| 2024-06-12 02:49:13 +0200 | <EvanR> | the last comment on the article says he turned a 100,000 line C rule engine for medical devices into 11 lines of haskell xD |
| 2024-06-12 02:49:34 +0200 | <EvanR> | what an elitist! |
| 2024-06-12 02:49:48 +0200 | <Guest40> | loop :: a -> (a -> Bool) -> (a -> a) -> [a] |
| 2024-06-12 02:49:49 +0200 | <Guest40> | loop seed pred next = go seed pred next [] |
| 2024-06-12 02:49:49 +0200 | <Guest40> | where go curr pred next xs = if pred curr |
| 2024-06-12 02:49:50 +0200 | <Guest40> | then xs |
| 2024-06-12 02:49:50 +0200 | <Guest40> | else go (next curr) pred next (curr : xs) |
| 2024-06-12 02:49:51 +0200 | <Guest40> | is there a function in base/monad-loops/some other library that replicates this functionality but with more polymorphism? |
| 2024-06-12 02:50:47 +0200 | <EvanR> | no need for monads there |
| 2024-06-12 02:51:23 +0200 | <EvanR> | but you could rewrite it using a combination of existing functions |
| 2024-06-12 02:51:51 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-06-12 02:52:20 +0200 | <EvanR> | :t \seed pred next -> takeWhile pred (iterate next seed) |
| 2024-06-12 02:52:21 +0200 | <lambdabot> | a -> (a -> Bool) -> (a -> a) -> [a] |
| 2024-06-12 02:53:57 +0200 | <EvanR> | cheater, any idea what the operator :>: is? |
| 2024-06-12 02:54:33 +0200 | <cheater> | some sorta subtyping shit? |
| 2024-06-12 02:54:42 +0200 | <cheater> | i think i saw it used with effects |
| 2024-06-12 02:54:44 +0200 | <cheater> | or with servant |
| 2024-06-12 02:55:34 +0200 | <EvanR> | Guest40, loop seed pred next = takeWhile pred (iterate next seed) |
| 2024-06-12 02:56:01 +0200 | <EvanR> | you might be able to rearrange the arguments to make that a nicer combo |
| 2024-06-12 02:56:25 +0200 | <cheater> | EvanR: where did you see it |
| 2024-06-12 02:56:48 +0200 | <EvanR> | it's in the article complaining about how haskell syntax is terse and incomprehensible because of operators such as >>=, <$>, and :>: |
| 2024-06-12 02:57:03 +0200 | <EvanR> | you don't usually get complaints about this last one xD |
| 2024-06-12 02:57:05 +0200 | <cheater> | why are you reading articles like that |
| 2024-06-12 02:57:07 +0200 | <cheater> | it's unhealthy |
| 2024-06-12 02:59:04 +0200 | <Guest40> | EvanR Makes sense, thanks |
| 2024-06-12 03:04:11 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 264 seconds) |
| 2024-06-12 03:06:06 +0200 | <EvanR> | gratuitous awful use of monads for the same thing |
| 2024-06-12 03:06:15 +0200 | <EvanR> | :t \seed pred next -> execWriter (fix (\loop s -> if pred s then return () else tell s >> loop (next s)) seed) |
| 2024-06-12 03:06:16 +0200 | <lambdabot> | Monoid t => t -> (t -> Bool) -> (t -> t) -> t |
| 2024-06-12 03:07:13 +0200 | <EvanR> | ok that's botched |
| 2024-06-12 03:07:46 +0200 | <EvanR> | :t \seed pred next -> execWriter (fix (\loop s -> if pred s then return () else tell [s] >> loop (next s)) seed) |
| 2024-06-12 03:07:47 +0200 | <lambdabot> | t -> (t -> Bool) -> (t -> t) -> [t] |
| 2024-06-12 03:16:12 +0200 | Guest40 | (~Guest40@c-98-37-216-109.hsd1.ca.comcast.net) (Quit: Client closed) |
| 2024-06-12 03:16:26 +0200 | <joeyadams> | :t \predicate -> takeWhile predicate . iterate |
| 2024-06-12 03:16:27 +0200 | <lambdabot> | error: |
| 2024-06-12 03:16:27 +0200 | <lambdabot> | • Couldn't match type ‘a1 -> [a1]’ with ‘[a]’ |
| 2024-06-12 03:16:27 +0200 | <lambdabot> | Expected type: (a1 -> a1) -> [a] |
| 2024-06-12 03:17:51 +0200 | <joeyadams> | :t \pred next seed -> takeWhile pred (iterate next seed) |
| 2024-06-12 03:17:52 +0200 | <lambdabot> | (a -> Bool) -> (a -> a) -> a -> [a] |
| 2024-06-12 03:18:04 +0200 | <joeyadams> | I think that's what Guest40 was looking for, but I was 10 seconds too late. |
| 2024-06-12 03:18:18 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2024-06-12 03:21:19 +0200 | <EvanR> | yeah I said that one |
| 2024-06-12 03:21:34 +0200 | <EvanR> | to compose all that you will need .: |
| 2024-06-12 03:23:25 +0200 | <EvanR> | @define (.:) = (.) . (.) |
| 2024-06-12 03:23:26 +0200 | <lambdabot> | Defined. |
| 2024-06-12 03:23:39 +0200 | <EvanR> | :t \predicate -> takeWhile predicate .: iterate |
| 2024-06-12 03:23:40 +0200 | <lambdabot> | (a -> Bool) -> (a -> a) -> a -> [a] |
| 2024-06-12 03:23:53 +0200 | <EvanR> | but I don't know if that's very clear |
| 2024-06-12 03:29:19 +0200 | <geekosaur> | they should have used that operator instead of :>: |
| 2024-06-12 03:44:13 +0200 | divya | (~user@202.170.201.94) |
| 2024-06-12 03:44:48 +0200 | divya | (~user@202.170.201.94) (Client Quit) |
| 2024-06-12 03:45:14 +0200 | divya | (~user@202.170.201.94) |
| 2024-06-12 03:51:02 +0200 | <monochrom> | Also, a -> Maybe a is better than a pair of a->Bool, a->a. |
| 2024-06-12 03:53:50 +0200 | <EvanR> | iterate doesn't work with a -> Maybe a :( |
| 2024-06-12 03:54:16 +0200 | <EvanR> | :t unfoldr |
| 2024-06-12 03:54:17 +0200 | <lambdabot> | (b -> Maybe (a, b)) -> b -> [a] |
| 2024-06-12 03:54:22 +0200 | <monochrom> | iterate doesn't plan to end. But you can use unfoldr. |
| 2024-06-12 03:54:50 +0200 | <monochrom> | And there is a reason why it is not a triple of b->Bool, b->a, b->b. |
| 2024-06-12 03:55:17 +0200 | <EvanR> | after all this shenanigans are worked out, I can finally create my a -> Maybe a to feed into it by combining my a -> a and a -> Bool that I started with xD |
| 2024-06-12 03:55:58 +0200 | <monochrom> | Despite how much misguided beginners wish for it in, e.g., https://discourse.haskell.org/t/equivalence-of-unfoldr-and-unfold/9657 |
| 2024-06-12 03:57:12 +0200 | <EvanR> | :t \f seed -> unfoldr (let g x = (x,x) in g . f) seed |
| 2024-06-12 03:57:13 +0200 | <lambdabot> | error: |
| 2024-06-12 03:57:13 +0200 | <lambdabot> | • Couldn't match type ‘(b, b)’ with ‘Maybe (a1, a)’ |
| 2024-06-12 03:57:13 +0200 | <lambdabot> | Expected type: a -> Maybe (a1, a) |
| 2024-06-12 03:57:35 +0200 | <EvanR> | :t \f seed -> unfoldr (let g x = (x,x) in fmap g f) seed |
| 2024-06-12 03:57:36 +0200 | <lambdabot> | error: |
| 2024-06-12 03:57:36 +0200 | <lambdabot> | • Couldn't match type ‘(b1, b1)’ with ‘Maybe (a, b)’ |
| 2024-06-12 03:57:36 +0200 | <lambdabot> | Expected type: b -> Maybe (a, b) |
| 2024-06-12 03:57:40 +0200 | <EvanR> | frak |
| 2024-06-12 03:59:07 +0200 | <monochrom> | I think it is fmap g . f |
| 2024-06-12 03:59:39 +0200 | <EvanR> | :t \f seed -> unfoldr (let g x = (x,x) in fmap (fmap g) f) seed |
| 2024-06-12 03:59:40 +0200 | <lambdabot> | (a -> Maybe a) -> a -> [a] |
| 2024-06-12 04:00:07 +0200 | <monochrom> | :) |
| 2024-06-12 04:01:32 +0200 | <EvanR> | :t \next pred x -> if pred x then Nothing else Just (next x) |
| 2024-06-12 04:01:33 +0200 | <lambdabot> | (t -> a) -> (t -> Bool) -> t -> Maybe a |
| 2024-06-12 04:02:28 +0200 | <EvanR> | apparently the types can change |
| 2024-06-12 04:08:27 +0200 | <probie> | :t \f seed -> catMaybes $ takeWhile isJust $ iterate (>>= f) (Just seed) |
| 2024-06-12 04:08:29 +0200 | <lambdabot> | (a -> Maybe a) -> a -> [a] |
| 2024-06-12 04:16:07 +0200 | <probie> | :t unfoldr . (fmap (join (,)) .) |
| 2024-06-12 04:16:08 +0200 | <lambdabot> | (a -> Maybe a) -> a -> [a] |
| 2024-06-12 04:39:23 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-12 04:56:21 +0200 | td_ | (~td@i53870920.versanet.de) (Ping timeout: 268 seconds) |
| 2024-06-12 04:58:04 +0200 | td_ | (~td@i5387092E.versanet.de) |
| 2024-06-12 05:07:13 +0200 | rdcdr | (~rdcdr@user/rdcdr) (Read error: Connection reset by peer) |
| 2024-06-12 05:09:15 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 264 seconds) |
| 2024-06-12 05:11:54 +0200 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-06-12 05:45:57 +0200 | aforemny | (~aforemny@2001:9e8:6cf6:d100:13b7:91e0:122d:7bf6) |
| 2024-06-12 05:47:13 +0200 | aforemny_ | (~aforemny@i59F516DE.versanet.de) (Ping timeout: 256 seconds) |
| 2024-06-12 06:00:21 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10:fbf2:b01f:1d47:7542) |
| 2024-06-12 06:03:27 +0200 | <probie> | I don't suppose anyone knows what language I mean when I say "functional, but looks procedural with an effect system with some sort of reference counting". I can't seem to recall the name or even enough for a search engine to find it |
| 2024-06-12 06:05:06 +0200 | <glguy> | Nim? |
| 2024-06-12 06:07:17 +0200 | <probie> | Nah, it was newer than that (and not production ready) |
| 2024-06-12 06:09:27 +0200 | <probie> | Found it; https://koka-lang.github.io (sorry for the slightly off-topic spam) |
| 2024-06-12 06:15:41 +0200 | <Lycurgus> | it's on topic for telepathy, my last interlocution here |
| 2024-06-12 06:17:20 +0200 | <Lycurgus> | also this is a pretty permissive channel, and that query was about FP |
| 2024-06-12 06:24:45 +0200 | Guest27 | (~Guest37@123.24.49.96) |
| 2024-06-12 06:24:55 +0200 | michalz | (~michalz@185.246.207.201) |
| 2024-06-12 06:26:15 +0200 | Guest27 | (~Guest37@123.24.49.96) (Client Quit) |
| 2024-06-12 06:30:24 +0200 | euleritian | (~euleritia@dynamic-176-000-199-065.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-12 06:30:41 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-06-12 06:31:15 +0200 | vadparaszt | (~Rodney@176.254.244.83) (Quit: Connection error?!) |
| 2024-06-12 06:31:23 +0200 | vizimajac | (vizimajac@shell.xshellz.com) |
| 2024-06-12 06:45:56 +0200 | <mauke> | "with some sort of reference counting" made me think of perceus |
| 2024-06-12 06:46:42 +0200 | <mauke> | ... which is indeed what's implemented in koka: https://www.microsoft.com/en-us/research/publication/perceus-garbage-free-reference-counting-with-… |
| 2024-06-12 06:57:18 +0200 | sp1ff | (~user@c-24-21-45-157.hsd1.wa.comcast.net) (Read error: Connection reset by peer) |
| 2024-06-12 06:58:26 +0200 | sp1ff | (~user@c-24-21-45-157.hsd1.wa.comcast.net) |
| 2024-06-12 07:07:24 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-06-12 07:11:17 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-06-12 07:11:50 +0200 | sympt | (~sympt@user/sympt) (Ping timeout: 252 seconds) |
| 2024-06-12 07:15:15 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-06-12 07:16:28 +0200 | euleritian | (~euleritia@dynamic-176-004-148-108.176.4.pool.telefonica.de) |
| 2024-06-12 07:17:47 +0200 | euleritian | (~euleritia@dynamic-176-004-148-108.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-12 07:19:05 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-06-12 07:25:27 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2024-06-12 07:30:01 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-06-12 07:37:40 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2024-06-12 07:56:50 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10:fbf2:b01f:1d47:7542) (Remote host closed the connection) |
| 2024-06-12 08:04:50 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-06-12 08:05:44 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-06-12 08:06:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 08:07:07 +0200 | euleritian | (~euleritia@dynamic-176-004-148-108.176.4.pool.telefonica.de) |
| 2024-06-12 08:11:10 +0200 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2024-06-12 08:15:15 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:3133:5b8c:8231:983f) (Quit: Leaving) |
| 2024-06-12 08:15:37 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-06-12 08:16:08 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-06-12 08:27:18 +0200 | Flow_ | (~none@gentoo/developer/flow) |
| 2024-06-12 08:27:31 +0200 | qhong | (~qhong@rescomp-21-400677.stanford.edu) |
| 2024-06-12 08:27:50 +0200 | Flow | (~none@gentoo/developer/flow) (Read error: Connection reset by peer) |
| 2024-06-12 08:34:46 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-06-12 08:37:48 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 08:39:25 +0200 | rdcdr | (~rdcdr@user/rdcdr) |
| 2024-06-12 08:41:51 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 255 seconds) |
| 2024-06-12 08:52:18 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-06-12 09:01:49 +0200 | <cheater> | i'm surprised we don't have refcounting in ghc |
| 2024-06-12 09:02:09 +0200 | <cheater> | you'd think that would be the one thing a functional language would be good at |
| 2024-06-12 09:03:38 +0200 | dcoutts | (~duncan@212.23.229.86) (Ping timeout: 268 seconds) |
| 2024-06-12 09:04:21 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 09:04:45 +0200 | <probie> | refcounting is a poor choice for a lazy language where cycles lurk everywhere |
| 2024-06-12 09:07:10 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-12 09:07:44 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-06-12 09:08:00 +0200 | acidjnk | (~acidjnk@p200300d6e714dc68856d8905203ea039.dip0.t-ipconnect.de) |
| 2024-06-12 09:09:40 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-06-12 09:13:56 +0200 | dcoutts | (~duncan@212.23.229.86) (Ping timeout: 252 seconds) |
| 2024-06-12 09:15:21 +0200 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2024-06-12 09:18:00 +0200 | fun-safe-math | (~fun-safe-@24.21.106.247) |
| 2024-06-12 09:18:01 +0200 | zetef | (~quassel@136.255.76.202) |
| 2024-06-12 09:22:47 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2024-06-12 09:23:12 +0200 | chele | (~chele@user/chele) |
| 2024-06-12 09:27:17 +0200 | zetef | (~quassel@136.255.76.202) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-06-12 09:31:18 +0200 | euleritian | (~euleritia@dynamic-176-004-148-108.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-12 09:31:47 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-06-12 09:34:27 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:f1a2:838a:8749:d076) (Ping timeout: 256 seconds) |
| 2024-06-12 09:34:39 +0200 | Luj | (~Luj@2a01:e0a:de4:a0e1:be24:11ff:febc:b5b5) (Quit: Ping timeout (120 seconds)) |
| 2024-06-12 09:34:58 +0200 | Luj | (~Luj@2a01:e0a:de4:a0e1:be24:11ff:febc:b5b5) |
| 2024-06-12 09:35:33 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:8e83:44df:afb0:80e1) |
| 2024-06-12 09:45:07 +0200 | rosco | (~rosco@175.136.155.137) |
| 2024-06-12 09:46:18 +0200 | sadome | (~sadome@user/sadome) |
| 2024-06-12 09:46:19 +0200 | sadome | (~sadome@user/sadome) (Excess Flood) |
| 2024-06-12 09:49:00 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-06-12 09:53:55 +0200 | danza | (~francesco@rm-19-59-6.service.infuturo.it) |
| 2024-06-12 09:57:28 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-06-12 09:57:56 +0200 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) (Ping timeout: 252 seconds) |
| 2024-06-12 09:59:59 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 10:00:35 +0200 | fun-safe-math | (~fun-safe-@24.21.106.247) (Ping timeout: 264 seconds) |
| 2024-06-12 10:03:55 +0200 | <cheater> | eh |
| 2024-06-12 10:04:03 +0200 | <cheater> | there's solutions to that... |
| 2024-06-12 10:05:03 +0200 | dcoutts | (~duncan@212.23.229.86) (Ping timeout: 264 seconds) |
| 2024-06-12 10:06:51 +0200 | danza | (~francesco@rm-19-59-6.service.infuturo.it) (Ping timeout: 264 seconds) |
| 2024-06-12 10:15:02 +0200 | pyooque | (~puke@user/puke) |
| 2024-06-12 10:15:02 +0200 | puke | Guest6730 |
| 2024-06-12 10:15:02 +0200 | Guest6730 | (~puke@user/puke) (Killed (mercury.libera.chat (Nickname regained by services))) |
| 2024-06-12 10:15:02 +0200 | pyooque | puke |
| 2024-06-12 10:16:25 +0200 | puke | (~puke@user/puke) (Max SendQ exceeded) |
| 2024-06-12 10:16:35 +0200 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) |
| 2024-06-12 10:18:09 +0200 | puke | (~puke@user/puke) |
| 2024-06-12 10:19:22 +0200 | puke | (~puke@user/puke) (Max SendQ exceeded) |
| 2024-06-12 10:19:51 +0200 | puke | (~puke@user/puke) |
| 2024-06-12 10:20:16 +0200 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2024-06-12 10:28:51 +0200 | <probie> | the solution is garbage collection |
| 2024-06-12 10:32:13 +0200 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) (Ping timeout: 272 seconds) |
| 2024-06-12 10:33:00 +0200 | danse-nr3 | (~danse-nr3@rm-19-59-6.service.infuturo.it) |
| 2024-06-12 10:33:34 +0200 | danse-nr3 | (~danse-nr3@rm-19-59-6.service.infuturo.it) (Remote host closed the connection) |
| 2024-06-12 10:33:58 +0200 | danse-nr3 | (~danse-nr3@rm-19-59-6.service.infuturo.it) |
| 2024-06-12 10:52:20 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-06-12 10:56:12 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-06-12 10:56:25 +0200 | Franciman | (~Franciman@mx1.fracta.dev) (Ping timeout: 255 seconds) |
| 2024-06-12 10:59:50 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) |
| 2024-06-12 11:00:51 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-06-12 11:09:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 11:14:29 +0200 | zmt01 | (~zmt00@user/zmt00) |
| 2024-06-12 11:18:04 +0200 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 268 seconds) |
| 2024-06-12 11:18:35 +0200 | ft | (~ft@p508db8fc.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-06-12 11:21:31 +0200 | <lortabac> | is there a cabal option to force recompilation of a single file? I have some Template Haskell code which needs to be executed on each build |
| 2024-06-12 11:22:37 +0200 | <sclv> | nope. you can add a dependent file in th tho which forces recomp if that dependent file changed |
| 2024-06-12 11:23:06 +0200 | <sclv> | or have a build.sh that touches the file then runs cabal build |
| 2024-06-12 11:25:41 +0200 | <tomsmeding> | lortabac: https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH-Syntax.html… |
| 2024-06-12 11:27:15 +0200 | <lortabac> | tomsmeding: this doesn't look like what I was asking for |
| 2024-06-12 11:27:38 +0200 | <tomsmeding> | it's not, but if the reason you want to re-execute is that some non-haskell file changed, then that might have been the solution to the X problem :) |
| 2024-06-12 11:28:27 +0200 | <lortabac> | the TH code returns the current Git hash |
| 2024-06-12 11:29:21 +0200 | <lortabac> | maybe I can add some Git internal file as a dependent file? |
| 2024-06-12 11:29:22 +0200 | <tomsmeding> | hm, yeah there's not a single file that contains that |
| 2024-06-12 11:29:30 +0200 | <tomsmeding> | .git/HEAD contains a ref, but not necessarily the commit hash |
| 2024-06-12 11:29:42 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-12 11:29:47 +0200 | <tomsmeding> | you could parse that manually and add a dependent file on .git/refs/heads/THE_HEAD_NAME |
| 2024-06-12 11:31:44 +0200 | <lortabac> | maybe .git/refs/heads/production |
| 2024-06-12 11:31:53 +0200 | <tomsmeding> | if you know that it will always be that branch :p |
| 2024-06-12 11:32:01 +0200 | <lortabac> | yes it's always that branch |
| 2024-06-12 11:32:06 +0200 | <tomsmeding> | then yes |
| 2024-06-12 11:32:32 +0200 | <tomsmeding> | it will depend on the wrong file if switch branches then, though |
| 2024-06-12 11:32:39 +0200 | <tomsmeding> | *if you |
| 2024-06-12 11:32:55 +0200 | <lortabac> | not an ideal solution because if we change our deployment strategy we need to remember to update the dependent file as well |
| 2024-06-12 11:33:21 +0200 | <lortabac> | probably a full 'cabal clean' is a better option |
| 2024-06-12 11:33:23 +0200 | <tomsmeding> | yeah, more robust would be parsing .git/HEAD and referring to that file |
| 2024-06-12 11:33:43 +0200 | <lortabac> | or as you say, parsing .git/HEAD |
| 2024-06-12 11:33:44 +0200 | <tomsmeding> | where you should note that if you checkout a commit ("detached HEAD"), .git/HEAD just contains a commit hash |
| 2024-06-12 11:34:54 +0200 | <sclv> | people often use a cusrom |
| 2024-06-12 11:35:06 +0200 | <sclv> | a custom setup with hooks for this |
| 2024-06-12 11:35:21 +0200 | <tomsmeding> | wouldn't the Setup.hs still need to figure out exactly what files to depend on |
| 2024-06-12 11:35:27 +0200 | <sclv> | but i think its cleaner to avoid that using just th |
| 2024-06-12 11:35:28 +0200 | <tomsmeding> | or does cabal run Setup every time the user compiles? |
| 2024-06-12 11:36:26 +0200 | <sclv> | it runs some setup phases. but custom setups are fragile and don’t always work with newer features like multirepl |
| 2024-06-12 11:37:41 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-12 11:42:01 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-06-12 11:50:30 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-06-12 11:50:50 +0200 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) |
| 2024-06-12 12:05:37 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-06-12 12:06:53 +0200 | alexherbo2 | (~alexherbo@45.39.22.93.rev.sfr.net) |
| 2024-06-12 12:12:01 +0200 | alexherbo2 | (~alexherbo@45.39.22.93.rev.sfr.net) (Remote host closed the connection) |
| 2024-06-12 12:17:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 12:28:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 12:31:35 +0200 | alexherbo2 | (~alexherbo@45.39.22.93.rev.sfr.net) |
| 2024-06-12 12:36:54 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 12:45:06 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-06-12 12:45:36 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-12 12:46:06 +0200 | tt12310978 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-06-12 12:47:01 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-06-12 12:47:59 +0200 | dcoutts | (~duncan@212.23.229.86) (Ping timeout: 264 seconds) |
| 2024-06-12 12:48:54 +0200 | tt1231097 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Ping timeout: 255 seconds) |
| 2024-06-12 12:48:54 +0200 | tt12310978 | tt1231097 |
| 2024-06-12 12:53:32 +0200 | Guest|68 | (~Guest|68@222-153-150-75-adsl.sparkbb.co.nz) |
| 2024-06-12 12:56:26 +0200 | causal | (~eric@50.35.88.207) |
| 2024-06-12 13:11:00 +0200 | CiaoSen | (~Jura@2a05:5800:2b1:db00:e6b9:7aff:fe80:3d03) |
| 2024-06-12 13:12:13 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 13:19:43 +0200 | danse-nr3 | (~danse-nr3@rm-19-59-6.service.infuturo.it) (Ping timeout: 246 seconds) |
| 2024-06-12 13:20:31 +0200 | divya | (~user@202.170.201.94) (Read error: Connection reset by peer) |
| 2024-06-12 13:28:30 +0200 | acidsys | (~crameleon@openSUSE/member/crameleon) (Ping timeout: 268 seconds) |
| 2024-06-12 13:29:36 +0200 | m1dnight | (~christoph@82.146.125.185) (Quit: WeeChat 4.2.2) |
| 2024-06-12 13:31:04 +0200 | m1dnight | (~christoph@82.146.125.185) |
| 2024-06-12 13:31:43 +0200 | m1dnight | (~christoph@82.146.125.185) (Client Quit) |
| 2024-06-12 13:32:09 +0200 | m1dnight | (~christoph@82.146.125.185) |
| 2024-06-12 13:42:45 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-06-12 13:43:47 +0200 | Guest|68 | (~Guest|68@222-153-150-75-adsl.sparkbb.co.nz) (Ping timeout: 256 seconds) |
| 2024-06-12 13:44:41 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-12 13:45:56 +0200 | acidsys | (~crameleon@openSUSE/member/crameleon) |
| 2024-06-12 13:49:07 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 246 seconds) |
| 2024-06-12 13:54:11 +0200 | Guest91 | (~Guest91@ool-2f109624.dyn.optonline.net) (Quit: Client closed) |
| 2024-06-12 13:54:35 +0200 | noctux | (~noctux@user/noctux) (Ping timeout: 264 seconds) |
| 2024-06-12 13:54:56 +0200 | noctux | (~noctux@user/noctux) |
| 2024-06-12 13:56:39 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) (Ping timeout: 264 seconds) |
| 2024-06-12 13:59:36 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-12 14:06:13 +0200 | dev2 | (~dev@2405:201:c062:801d:74fb:a90f:fd55:89e8) (Quit: WeeChat 4.3.1) |
| 2024-06-12 14:12:32 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-06-12 14:17:31 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) |
| 2024-06-12 14:18:11 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) (Remote host closed the connection) |
| 2024-06-12 14:18:52 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) |
| 2024-06-12 14:34:37 +0200 | alexherbo2 | (~alexherbo@45.39.22.93.rev.sfr.net) (Remote host closed the connection) |
| 2024-06-12 14:40:31 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-12 14:41:31 +0200 | andrei_n | (~andrei_n@user/andrei-n:62396) |
| 2024-06-12 14:42:14 +0200 | califax | (~califax@user/califx) |
| 2024-06-12 14:46:59 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) (Remote host closed the connection) |
| 2024-06-12 14:47:11 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3313-51a8-f0e2-1840-0dc8-1db7.rev.sfr.net) |
| 2024-06-12 14:50:28 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) |
| 2024-06-12 14:54:41 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 14:56:19 +0200 | ames | (~amelia@offtopia/offtopian/amelia) (Ping timeout: 272 seconds) |
| 2024-06-12 15:05:55 +0200 | bontaq | (~user@ool-45779c03.dyn.optonline.net) |
| 2024-06-12 15:09:28 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-06-12 15:10:19 +0200 | <danse-nr3> | what is the name for the alternative operator <|>? |
| 2024-06-12 15:11:33 +0200 | <ncf> | <|> |
| 2024-06-12 15:11:35 +0200 | <cheater> | alternative |
| 2024-06-12 15:11:51 +0200 | <cheater> | or, alternatively, "bracket pipe" |
| 2024-06-12 15:12:12 +0200 | <danse-nr3> | cheers cheater |
| 2024-06-12 15:12:26 +0200 | <cheater> | haha, ncf gets nothing |
| 2024-06-12 15:12:37 +0200 | <cheater> | :P |
| 2024-06-12 15:12:58 +0200 | <danse-nr3> | err sorry but i don't know what to do with that answer if not ignoring it :P |
| 2024-06-12 15:13:00 +0200 | Guest8 | (~Guest91@ool-2f109624.dyn.optonline.net) |
| 2024-06-12 15:13:44 +0200 | <ncf> | https://en.wikipedia.org/wiki/Garbage_in,_garbage_out |
| 2024-06-12 15:14:07 +0200 | <cheater> | now now, ncf, no need to be self-deprecating :P |
| 2024-06-12 15:17:46 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-12 15:17:49 +0200 | <danse-nr3> | @hoogle (Foldable t, Alternative a) => t a -> a |
| 2024-06-12 15:17:51 +0200 | <lambdabot> | Test.Extrapolate.TypeBinding argTy1of1 :: con a -> a |
| 2024-06-12 15:17:51 +0200 | <lambdabot> | Prelude maximum :: forall a . (Foldable t, Ord a) => t a -> a |
| 2024-06-12 15:17:51 +0200 | <lambdabot> | Prelude minimum :: forall a . (Foldable t, Ord a) => t a -> a |
| 2024-06-12 15:18:46 +0200 | <danse-nr3> | foldr (<|>) i guess |
| 2024-06-12 15:19:07 +0200 | <ncf> | :t asum |
| 2024-06-12 15:19:09 +0200 | <lambdabot> | (Foldable t, Alternative f) => t (f a) -> f a |
| 2024-06-12 15:19:20 +0200 | <danse-nr3> | facepalm |
| 2024-06-12 15:19:22 +0200 | <ncf> | wait what |
| 2024-06-12 15:19:24 +0200 | <ncf> | Alternative a? |
| 2024-06-12 15:19:41 +0200 | <ncf> | i guess hoogle doesn't kind-check lol |
| 2024-06-12 15:20:26 +0200 | <danse-nr3> | thanks ncf |
| 2024-06-12 15:20:58 +0200 | califax | (~califax@user/califx) |
| 2024-06-12 15:28:10 +0200 | <raehik> | I call (<|>) "or" when I need a non-infix name am I weird |
| 2024-06-12 15:28:35 +0200 | <raehik> | "choice" came across the mind but I just like "or" better |
| 2024-06-12 15:29:31 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-06-12 15:30:34 +0200 | <__monty__> | @hoogle choice |
| 2024-06-12 15:30:35 +0200 | <lambdabot> | Text.ParserCombinators.ReadP choice :: [ReadP a] -> ReadP a |
| 2024-06-12 15:30:35 +0200 | <lambdabot> | Text.ParserCombinators.ReadPrec choice :: [ReadPrec a] -> ReadPrec a |
| 2024-06-12 15:30:35 +0200 | <lambdabot> | Text.Parsec choice :: Stream s m t => [ParsecT s u m a] -> ParsecT s u m a |
| 2024-06-12 15:31:04 +0200 | <__monty__> | Already commonly means `foldr1 (<|>)`, no? |
| 2024-06-12 15:33:34 +0200 | <danse-nr3> | not sure signatures do not mention alternative, seems more a different abstraction |
| 2024-06-12 15:34:26 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-06-12 15:34:36 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-06-12 15:34:54 +0200 | <danse-nr3> | "or" makes sense but i would rather not overload existing concepts |
| 2024-06-12 15:35:45 +0200 | <danse-nr3> | (also because "alt" isn't much longer) |
| 2024-06-12 15:37:45 +0200 | <ncf> | so your question is how to read it out loud? |
| 2024-06-12 15:37:50 +0200 | euleritian | (~euleritia@dynamic-176-004-153-084.176.4.pool.telefonica.de) |
| 2024-06-12 15:43:17 +0200 | Square | (~Square4@user/square) |
| 2024-06-12 15:44:08 +0200 | <danse-nr3> | well sure |
| 2024-06-12 15:49:12 +0200 | Guest8 | (~Guest91@ool-2f109624.dyn.optonline.net) (Quit: Client closed) |
| 2024-06-12 15:49:34 +0200 | dev2 | (~dev@2405:201:c062:801d:4d6f:d1e8:5a8c:26e3) |
| 2024-06-12 15:50:09 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-06-12 16:00:39 +0200 | <EvanR> | is there an esoteric programming language which doesn't work unless you read the code aloud |
| 2024-06-12 16:03:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 16:03:52 +0200 | <danse-nr3> | not sure but humans have generally benefited from being able to name things |
| 2024-06-12 16:04:57 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3313-51a8-f0e2-1840-0dc8-1db7.rev.sfr.net) (Remote host closed the connection) |
| 2024-06-12 16:05:17 +0200 | <EvanR> | in programming there turns out to be a lot of opportunities to name things, too many. See single assignment form |
| 2024-06-12 16:05:31 +0200 | <EvanR> | we skip ahead of the animals by eliding most of it and forming expressions |
| 2024-06-12 16:05:45 +0200 | <EvanR> | similarly we can read faster by not reading aloud (now) |
| 2024-06-12 16:06:47 +0200 | <EvanR> | of course it comes across as in haskell we're too good to name things! |
| 2024-06-12 16:07:00 +0200 | andrei-n | (~andrei_n@2a02:a03f:c091:a800:6208:726b:3655:52d8) |
| 2024-06-12 16:07:06 +0200 | andrei-n | (~andrei_n@2a02:a03f:c091:a800:6208:726b:3655:52d8) (Remote host closed the connection) |
| 2024-06-12 16:07:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 16:07:50 +0200 | <EvanR> | also not having real names for most of the operators in haskell explains why it avoids success so well. Giant conferences fueled by keynotes and guest speakers can't pronounce anything xD |
| 2024-06-12 16:11:03 +0200 | <danse-nr3> | yeah well makes sense not to name ephemeral entities, while more consolidated concepts have names since before getting into a language like haskell for instance. But names sometimes also remain segregated into small circles and have no chance to propagate, that's why i asked |
| 2024-06-12 16:12:06 +0200 | <EvanR> | I do appreciate how most of the "operators" in lens are hitherto unused dictionary words |
| 2024-06-12 16:12:32 +0200 | <EvanR> | words do be having power |
| 2024-06-12 16:15:07 +0200 | <haskellbridge> | <sm> array-oriented languages, apl and family, famous for their obscure glyphs, do also have a word name for each one. That's useful for docs and also for data entry |
| 2024-06-12 16:15:19 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-06-12 16:15:26 +0200 | <haskellbridge> | <sm> +standardised |
| 2024-06-12 16:16:25 +0200 | <haskellbridge> | <sm> in haskell we don't have a standard name for everything |
| 2024-06-12 16:17:04 +0200 | RedFlamingos | (~RedFlamin@user/RedFlamingos) |
| 2024-06-12 16:17:50 +0200 | rosco | (~rosco@175.136.155.137) (Quit: Lost terminal) |
| 2024-06-12 16:19:04 +0200 | <EvanR> | sometimes an operator has not a name per se but a long winded description. Like if you see xyzw in group theory, if asked, someone will say the operator (juxtaposition) is "group theoretic multiplication" or something. In category theory "composition of morphisms". Not something you would pronounce in line |
| 2024-06-12 16:19:42 +0200 | <EvanR> | and yeah how do you document that |
| 2024-06-12 16:21:11 +0200 | <haskellbridge> | <sm> is xyzw a real operator name ? |
| 2024-06-12 16:21:27 +0200 | <haskellbridge> | <sm> I see it mentioned as "quaternions" in graphics programming |
| 2024-06-12 16:21:39 +0200 | <EvanR> | that's four variables being operatored |
| 2024-06-12 16:21:44 +0200 | <EvanR> | abcd |
| 2024-06-12 16:21:45 +0200 | <haskellbridge> | <sm> ah |
| 2024-06-12 16:21:55 +0200 | <EvanR> | fgh |
| 2024-06-12 16:21:57 +0200 | <haskellbridge> | <sm> gotcha |
| 2024-06-12 16:22:49 +0200 | <EvanR> | a <|> b <|> c <|> d ... Alternative's sequential failover... or something |
| 2024-06-12 16:23:34 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-06-12 16:28:52 +0200 | ystael | (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 2024-06-12 16:29:19 +0200 | ystael | (~ystael@user/ystael) |
| 2024-06-12 16:31:29 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-12 16:39:40 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) (Ping timeout: 268 seconds) |
| 2024-06-12 16:47:58 +0200 | scav | (sid309693@user/scav) () |
| 2024-06-12 17:02:14 +0200 | greenflower | (~greenflow@103.191.25.63) |
| 2024-06-12 17:11:39 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Ping timeout: 264 seconds) |
| 2024-06-12 17:14:05 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-06-12 17:14:13 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-06-12 17:23:53 +0200 | dcoutts | (~duncan@212.23.229.86) (Remote host closed the connection) |
| 2024-06-12 17:24:16 +0200 | dcoutts | (~duncan@212.23.229.86) |
| 2024-06-12 17:30:35 +0200 | euleritian | (~euleritia@dynamic-176-004-153-084.176.4.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-06-12 17:30:51 +0200 | euleritian | (~euleritia@dynamic-176-007-201-187.176.7.pool.telefonica.de) |
| 2024-06-12 17:31:46 +0200 | dcoutts | (~duncan@212.23.229.86) (Ping timeout: 268 seconds) |
| 2024-06-12 17:32:44 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) |
| 2024-06-12 17:33:17 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 240 seconds) |
| 2024-06-12 17:36:19 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-06-12 17:37:19 +0200 | mud | (~mud@user/kadoban) (Ping timeout: 268 seconds) |
| 2024-06-12 17:43:29 +0200 | Square | (~Square4@user/square) (Ping timeout: 268 seconds) |
| 2024-06-12 17:47:39 +0200 | euleritian | (~euleritia@dynamic-176-007-201-187.176.7.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-06-12 17:51:59 +0200 | euleritian | (~euleritia@dynamic-176-001-140-054.176.1.pool.telefonica.de) |
| 2024-06-12 17:54:24 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) (Remote host closed the connection) |
| 2024-06-12 17:54:48 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) |
| 2024-06-12 17:57:58 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-06-12 18:03:41 +0200 | danse-nr3 | (~danse-nr3@151.44.179.149) (Ping timeout: 240 seconds) |
| 2024-06-12 18:04:08 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:156b:aa72:70b8:c5f5) |
| 2024-06-12 18:04:33 +0200 | danse-nr3 | (~danse-nr3@rm-19-3-15.service.infuturo.it) |
| 2024-06-12 18:12:04 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) |
| 2024-06-12 18:14:03 +0200 | euleritian | (~euleritia@dynamic-176-001-140-054.176.1.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-06-12 18:15:13 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-06-12 18:16:06 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-06-12 18:17:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 18:18:48 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-12 18:19:13 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2024-06-12 18:20:38 +0200 | danse-nr3 | (~danse-nr3@rm-19-3-15.service.infuturo.it) (Ping timeout: 252 seconds) |
| 2024-06-12 18:20:42 +0200 | euleritian | (~euleritia@dynamic-176-001-140-054.176.1.pool.telefonica.de) |
| 2024-06-12 18:20:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 18:32:36 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-06-12 18:35:01 +0200 | mei | (~mei@user/mei) |
| 2024-06-12 18:42:30 +0200 | Square | (~Square@user/square) |
| 2024-06-12 18:43:59 +0200 | greenflower | (~greenflow@103.191.25.63) (Quit: Client closed) |
| 2024-06-12 18:45:21 +0200 | <lxsameer> | hey friends, I'm overwhelmed by the number of packages that offer Expection/Error handling. Do you have any recommendation? my workload is async, And I use a simple ReaderT |
| 2024-06-12 18:46:29 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) (Ping timeout: 252 seconds) |
| 2024-06-12 18:49:56 +0200 | <Rembane> | lxsameer: Lets X/Y this. Why do you need that kind of error handling? |
| 2024-06-12 18:50:49 +0200 | <glguy> | You probably don't need any package for it |
| 2024-06-12 18:50:54 +0200 | erty | (~user@user/aeroplane) |
| 2024-06-12 18:52:20 +0200 | <Rembane> | Maybe transformers or mtl? |
| 2024-06-12 18:55:12 +0200 | <lxsameer> | Rembane: let me ask you this, how do you handle async Errors in your mtl stack? |
| 2024-06-12 18:55:54 +0200 | <glguy> | Do you mean exceptions from the async package, or asynchronous exceptions? |
| 2024-06-12 18:56:20 +0200 | danse-nr3 | (~danse-nr3@rm-19-3-15.service.infuturo.it) |
| 2024-06-12 18:56:32 +0200 | <lxsameer> | asynchronous exceptions |
| 2024-06-12 18:56:48 +0200 | <glguy> | You don't handle those in an mtl context, you handle them in an IO context |
| 2024-06-12 18:56:54 +0200 | <Rembane> | lxsameer: I'm using the async package to handle them. |
| 2024-06-12 18:56:57 +0200 | <glguy> | or ideally you aren't using them |
| 2024-06-12 18:57:54 +0200 | <lxsameer> | do you integrate them with your mtl transformer stack? |
| 2024-06-12 18:59:29 +0200 | <Rembane> | lxsameer: Like this: https://github.com/dtekcth/mat-chalmers/blob/main/app/Main.hs#L79 but it struck me that this is needed because we run things concurrently in that project. |
| 2024-06-12 18:59:39 +0200 | <Rembane> | lxsameer: No, they're not part of the stack. |
| 2024-06-12 19:00:26 +0200 | <Rembane> | lxsameer: They're just outside of the stack. |
| 2024-06-12 19:00:32 +0200 | <lxsameer> | cool cool |
| 2024-06-12 19:00:46 +0200 | <lxsameer> | that makes things simpler |
| 2024-06-12 19:00:51 +0200 | <lxsameer> | thank you |
| 2024-06-12 19:01:56 +0200 | <Rembane> | No worries. I hope this didn't make you more confused than you were before. :) |
| 2024-06-12 19:03:33 +0200 | <lxsameer> | no, it helped a lot. |
| 2024-06-12 19:04:31 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-06-12 19:05:28 +0200 | <Rembane> | Cool! |
| 2024-06-12 19:07:54 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-06-12 19:08:04 +0200 | igghibu | (~igghibu@178.249.211.102) |
| 2024-06-12 19:08:58 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-12 19:10:26 +0200 | CiaoSen | (~Jura@2a05:5800:2b1:db00:e6b9:7aff:fe80:3d03) (Ping timeout: 268 seconds) |
| 2024-06-12 19:14:41 +0200 | igghibu_ | (~igghibu@146.70.225.113) |
| 2024-06-12 19:15:05 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-12 19:15:59 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-06-12 19:17:36 +0200 | igghibu | (~igghibu@178.249.211.102) (Ping timeout: 256 seconds) |
| 2024-06-12 19:17:39 +0200 | danse-nr3 | (~danse-nr3@rm-19-3-15.service.infuturo.it) (Ping timeout: 264 seconds) |
| 2024-06-12 19:21:09 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3313-51a8-b4f8-85c4-3803-196a.rev.sfr.net) |
| 2024-06-12 19:21:41 +0200 | troydm | (~troydm@user/troydm) (Ping timeout: 252 seconds) |
| 2024-06-12 19:22:26 +0200 | <EvanR> | the point of exceptions is NOT handling them, usually xD |
| 2024-06-12 19:23:00 +0200 | <monochrom> | Wait, then what is the point? |
| 2024-06-12 19:23:09 +0200 | <EvanR> | not handling them |
| 2024-06-12 19:23:24 +0200 | <EvanR> | being freed from the burden of handling them, all |
| 2024-06-12 19:23:34 +0200 | <monochrom> | Oh heh I see how to parse that now. |
| 2024-06-12 19:24:25 +0200 | <Rembane> | Let it crash! |
| 2024-06-12 19:24:31 +0200 | uri39 | (~uri39@200.23.157.245) |
| 2024-06-12 19:25:13 +0200 | <monochrom> | You know, that really ties in with the math. Plotkin was trying to use algebra to explain effects, and he found out that handling exceptions doesn't fit, only raising does. |
| 2024-06-12 19:25:40 +0200 | <dolio> | Well, kind of. |
| 2024-06-12 19:27:15 +0200 | <glguy> | monochrom: similarly if you only have handling but not raising, that'd be pretty easy to support, too |
| 2024-06-12 19:27:16 +0200 | igghibu | (~igghibu@146.70.225.113) |
| 2024-06-12 19:28:43 +0200 | <dolio> | The type of internal catch can actually come from an algebraic effect. |
| 2024-06-12 19:29:29 +0200 | <dolio> | `m a -> (e -> m a) -> m a` is the 'model' view of the effect `pick : Maybe e` |
| 2024-06-12 19:29:51 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) |
| 2024-06-12 19:30:04 +0200 | igghibu_ | (~igghibu@146.70.225.113) (Ping timeout: 256 seconds) |
| 2024-06-12 19:30:13 +0200 | <dolio> | Like how `m a -> m a -> m a` corresponds to the effect `pick : Bool`. |
| 2024-06-12 19:31:05 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-06-12 19:33:04 +0200 | <dolio> | Of course, if you have `throw` and `pick`, the handler can do whatever it wants with both , meaning `pick` doesn't necessarily have to have anything to do with `throw`. Unless you have equations. |
| 2024-06-12 19:33:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 19:38:17 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 19:41:01 +0200 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-12 19:45:16 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:156b:aa72:70b8:c5f5) (Quit: Leaving) |
| 2024-06-12 19:49:36 +0200 | uri39 | (~uri39@200.23.157.245) (Quit: Client closed) |
| 2024-06-12 19:55:45 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-06-12 19:56:30 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3313-51a8-b4f8-85c4-3803-196a.rev.sfr.net) (Remote host closed the connection) |
| 2024-06-12 19:59:03 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.3.1) |
| 2024-06-12 19:59:44 +0200 | causal | (~eric@50.35.88.207) |
| 2024-06-12 20:04:24 +0200 | erty | (~user@user/aeroplane) (Remote host closed the connection) |
| 2024-06-12 20:05:03 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 264 seconds) |
| 2024-06-12 20:05:37 +0200 | SethTisue | (sid14912@id-14912.ilkley.irccloud.com) (Read error: Connection reset by peer) |
| 2024-06-12 20:05:57 +0200 | ProofTechnique_ | (sid79547@id-79547.ilkley.irccloud.com) (Read error: Connection reset by peer) |
| 2024-06-12 20:06:05 +0200 | SethTisue | (sid14912@id-14912.ilkley.irccloud.com) |
| 2024-06-12 20:06:08 +0200 | igghibu | (~igghibu@146.70.225.113) (Quit: igghibu) |
| 2024-06-12 20:06:19 +0200 | alanz | (sid110616@id-110616.uxbridge.irccloud.com) (Read error: Connection reset by peer) |
| 2024-06-12 20:06:20 +0200 | JSharp | (sid4580@user/JSharp) (Ping timeout: 256 seconds) |
| 2024-06-12 20:06:30 +0200 | alanz | (sid110616@id-110616.uxbridge.irccloud.com) |
| 2024-06-12 20:06:50 +0200 | JSharp | (sid4580@user/JSharp) |
| 2024-06-12 20:06:51 +0200 | ProofTechnique_ | (sid79547@id-79547.ilkley.irccloud.com) |
| 2024-06-12 20:06:54 +0200 | sa | (sid1055@id-1055.tinside.irccloud.com) (Ping timeout: 256 seconds) |
| 2024-06-12 20:06:54 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) (Ping timeout: 256 seconds) |
| 2024-06-12 20:06:54 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (Ping timeout: 256 seconds) |
| 2024-06-12 20:08:57 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2024-06-12 20:09:02 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) |
| 2024-06-12 20:10:03 +0200 | sa | (sid1055@id-1055.tinside.irccloud.com) |
| 2024-06-12 20:10:46 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) |
| 2024-06-12 20:13:08 +0200 | sclv | (sid39734@haskell/developer/sclv) (Ping timeout: 256 seconds) |
| 2024-06-12 20:13:42 +0200 | jackdk | (sid373013@cssa/jackdk) (Ping timeout: 256 seconds) |
| 2024-06-12 20:13:56 +0200 | jackdk | (sid373013@cssa/jackdk) |
| 2024-06-12 20:14:00 +0200 | sclv | (sid39734@haskell/developer/sclv) |
| 2024-06-12 20:19:28 +0200 | <tomsmeding> | I thought `vector`'s fusion framework was suppose to make things faster, but `sum (force (concat l))` is almost 4x as fast as `sum (concat l)`, undependently of `length l` (tested lengths: [0, 10, 100, 1000] with lengths of vectors so that there are 1e6 elements in total) |
| 2024-06-12 20:19:40 +0200 | <tomsmeding> | *independently |
| 2024-06-12 20:21:57 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.3.1) |
| 2024-06-12 20:22:40 +0200 | causal | (~eric@50.35.88.207) |
| 2024-06-12 20:26:40 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) (Remote host closed the connection) |
| 2024-06-12 20:26:57 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) |
| 2024-06-12 20:31:44 +0200 | <int-e> | I'd *guess* that `force` causes the code to actually materialize the intermediate vector, while without `force` the code fuses perfectly. |
| 2024-06-12 20:31:51 +0200 | <tomsmeding> | indeed |
| 2024-06-12 20:32:02 +0200 | <tomsmeding> | the intent of that 'force' there was to break fusion |
| 2024-06-12 20:32:09 +0200 | <tomsmeding> | but then why is the one without fusion _faster_? |
| 2024-06-12 20:32:33 +0200 | <tomsmeding> | and not a little bit too |
| 2024-06-12 20:32:35 +0200 | <int-e> | Aha, I misread. |
| 2024-06-12 20:32:39 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) (Ping timeout: 264 seconds) |
| 2024-06-12 20:33:59 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-06-12 20:34:10 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-06-12 20:36:14 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Quit: WeeChat 4.2.2) |
| 2024-06-12 20:37:10 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Quit: o/) |
| 2024-06-12 20:38:03 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) |
| 2024-06-12 20:38:59 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-06-12 20:40:55 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-06-12 20:41:19 +0200 | dmj` | (uid72307@id-72307.hampstead.irccloud.com) |
| 2024-06-12 20:41:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 20:42:26 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-12 20:44:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 20:44:18 +0200 | dcoutts | (~duncan@46-253-189-44.dynamic.monzoon.net) (Ping timeout: 256 seconds) |
| 2024-06-12 20:48:18 +0200 | <c_wraith> | tomsmeding: does it depend on how you generate l? |
| 2024-06-12 20:49:40 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-06-12 20:50:13 +0200 | <tomsmeding> | c_wraith: the creation of `l` is intentionally separated from the consumption in `concat`; the `sum (concat l)` is inside Test.Tasty.Bench.nf and the creation of `l` is outside of it |
| 2024-06-12 20:50:45 +0200 | <tomsmeding> | (it's `replicate n (VS.enumFromTo (1::Int) k)`, where n and k vary as above) |
| 2024-06-12 20:51:08 +0200 | <tomsmeding> | I haven't tried other ways of generating l, but I would imagine it doesn't matter much because fusion cannot connect the two |
| 2024-06-12 20:51:52 +0200 | <c_wraith> | Oh, putting it outside means it'll be reused, so definitely can't be fused. |
| 2024-06-12 20:52:03 +0200 | <int-e> | Can't replicate that in isolation. Can confirm that the `force` version allocates more. This is with https://paste.tomsmeding.com/KZhEHgUI to prevent cross-optimization with generation of the vectors |
| 2024-06-12 20:52:06 +0200 | <tomsmeding> | ah, also that |
| 2024-06-12 20:53:01 +0200 | <int-e> | (the extra argument is there so I can evaluate that multiple times without GHC seeing any sharing) |
| 2024-06-12 20:54:02 +0200 | <tomsmeding> | int-e: also not with Data.Vector.Storable? |
| 2024-06-12 20:54:30 +0200 | <tomsmeding> | (perhaps I should've specified that I'm using storable vectors) |
| 2024-06-12 20:54:51 +0200 | <int-e> | yeah, qualitatively the same with .Storable |
| 2024-06-12 20:55:27 +0200 | <int-e> | For .Storable `foo` is 5x faster in my test; without boxed vectos it's only 2x faster. |
| 2024-06-12 20:55:49 +0200 | <tomsmeding> | hm, let me see |
| 2024-06-12 20:56:44 +0200 | <int-e> | compiling with -O2, I wonder whether -O changes anything... it does! |
| 2024-06-12 20:57:12 +0200 | <int-e> | With -O the version without `force` *is* slower. |
| 2024-06-12 20:57:17 +0200 | <tomsmeding> | aha! |
| 2024-06-12 20:57:21 +0200 | <int-e> | That's... interesting. |
| 2024-06-12 20:58:04 +0200 | <int-e> | I did not expect to see code for which -O2 is almost 20x faster than -O. |
| 2024-06-12 20:58:41 +0200 | <tomsmeding> | int-e: which vector lengths are you using that you get 20x? :p |
| 2024-06-12 20:58:52 +0200 | <int-e> | I used replicate 100 (V.fromList [1..10000]) |
| 2024-06-12 20:59:09 +0200 | <int-e> | so 1e6 |
| 2024-06-12 20:59:37 +0200 | <int-e> | tomsmeding: the 20x is for `foo`, compiled with -O vs -O2 |
| 2024-06-12 20:59:44 +0200 | <tomsmeding> | I see, I get the same |
| 2024-06-12 21:00:29 +0200 | <tomsmeding> | fun! |
| 2024-06-12 21:00:44 +0200 | <int-e> | with -O, foo is ~2x slower than bar; with -O2 foo is ~5x faster than bar. Insane. |
| 2024-06-12 21:00:54 +0200 | <dolio> | vector's fusion is very complicated. I'm not exactly sure what would depend on -O2, but I guess with just -O there is some cruft left over. |
| 2024-06-12 21:01:08 +0200 | <tomsmeding> | I tried this: https://paste.tomsmeding.com/spBJbnoo |
| 2024-06-12 21:01:26 +0200 | <tomsmeding> | with -O1, foo / bar is ~4.2; with _O2, foo / bar is ~0.11 |
| 2024-06-12 21:01:32 +0200 | <tomsmeding> | *-O2 |
| 2024-06-12 21:01:41 +0200 | <tomsmeding> | dolio: evidently! |
| 2024-06-12 21:01:54 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-06-12 21:02:26 +0200 | <dolio> | Like, it does things like building multiple ways for every expression to be evaluated, then expecting the compiler to throw most of them out. |
| 2024-06-12 21:03:17 +0200 | <tomsmeding> | laziness would presumably throw them out anyway, but at an overhead cost |
| 2024-06-12 21:04:43 +0200 | <int-e> | So this shows additional rules firing: (-ddump-rule-firings) https://paste.tomsmeding.com/3kUGXgp4 |
| 2024-06-12 21:06:20 +0200 | <int-e> | I'm not sure what those rules are. |
| 2024-06-12 21:06:43 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) |
| 2024-06-12 21:07:00 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-06-12 21:07:43 +0200 | <tomsmeding> | that "Rule fired: +# (BUILTIN)" looks helpful |
| 2024-06-12 21:07:50 +0200 | <tomsmeding> | just from the name |
| 2024-06-12 21:10:13 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:156b:aa72:70b8:c5f5) |
| 2024-06-12 21:10:54 +0200 | <dolio> | I think some of those others are worker-wrapper. |
| 2024-06-12 21:11:14 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) |
| 2024-06-12 21:11:30 +0200 | <int-e> | tomsmeding: https://paste.tomsmeding.com/z6BIxayL |
| 2024-06-12 21:12:30 +0200 | <int-e> | (that's for `foo`, the version without `force`) |
| 2024-06-12 21:12:32 +0200 | ft | (~ft@p3e9bcb39.dip0.t-ipconnect.de) |
| 2024-06-12 21:12:39 +0200 | <tomsmeding> | it unpacked the Either as if it was a product type? |
| 2024-06-12 21:12:57 +0200 | <tomsmeding> | wait, no it didn't |
| 2024-06-12 21:13:22 +0200 | <int-e> | I /think/ it can split the function into two, one for Left and one for Right. |
| 2024-06-12 21:13:28 +0200 | <tomsmeding> | int-e: is this inner loop for every scalar, or for every vector? |
| 2024-06-12 21:13:47 +0200 | <tomsmeding> | s/scalar/int/ |
| 2024-06-12 21:13:49 +0200 | <int-e> | This /may/ come down to the (fragile) choice of loop breakers in recursive functions. |
| 2024-06-12 21:14:02 +0200 | <int-e> | for every scalar |
| 2024-06-12 21:14:06 +0200 | <tomsmeding> | oof okay |
| 2024-06-12 21:14:33 +0200 | <tomsmeding> | oh I see, the Right case is "currently reducing this vector at this cursor, and this is the remaining work" probably |
| 2024-06-12 21:15:31 +0200 | visilii_ | (~visilii@46.61.242.35) |
| 2024-06-12 21:15:40 +0200 | <tomsmeding> | anyway, this is apparently not a bug in vector :) |
| 2024-06-12 21:15:41 +0200 | <int-e> | yeah |
| 2024-06-12 21:16:00 +0200 | <int-e> | I'm not agreeing that this is a bug |
| 2024-06-12 21:16:00 +0200 | <tomsmeding> | luckily -- it would've been a bit embarrassing if it had been |
| 2024-06-12 21:16:20 +0200 | <tomsmeding> | I said this is _not_ a bug in vector |
| 2024-06-12 21:16:24 +0200 | <tomsmeding> | I thought originally that it might be |
| 2024-06-12 21:16:40 +0200 | <int-e> | GHC is *supposed* to eliminate that Either, but it's tricky to make it do that reliably. |
| 2024-06-12 21:16:41 +0200 | <tomsmeding> | but if the solution is "use -O2 if you want vector to be fast", that's fair |
| 2024-06-12 21:16:50 +0200 | <int-e> | Oh I still can't read. |
| 2024-06-12 21:16:51 +0200 | <int-e> | Sigh. |
| 2024-06-12 21:16:53 +0200 | <tomsmeding> | :) |
| 2024-06-12 21:17:19 +0200 | <int-e> | Anyway I hope my net contribution is still positive :) |
| 2024-06-12 21:17:26 +0200 | <tomsmeding> | definitely |
| 2024-06-12 21:17:29 +0200 | <monochrom> | yes, no worries |
| 2024-06-12 21:17:42 +0200 | <tomsmeding> | I've been told too often that -O2 typically doesn't do much |
| 2024-06-12 21:17:47 +0200 | visilii | (~visilii@213.24.125.2) (Ping timeout: 268 seconds) |
| 2024-06-12 21:17:56 +0200 | <tomsmeding> | but I forgot the part after that, which goes "then profile and check if -O2 does actually help in your case" |
| 2024-06-12 21:18:04 +0200 | <monochrom> | Right, but I think bytestring, text, vector need it. |
| 2024-06-12 21:18:30 +0200 | <tomsmeding> | text and vector have fusion frameworks which I can imagine need -O2 (given this discussion), but bytestring doesn't do anything special, right? |
| 2024-06-12 21:18:32 +0200 | <monochrom> | Basically the only exceptions because they go ham with fusion. |
| 2024-06-12 21:18:35 +0200 | <int-e> | Anyway, I can't explain why GHC does so terribly with -O here... picking the wrong loop breaker is my guess but I barely know what they are, never mind how GHC picks them. |
| 2024-06-12 21:19:25 +0200 | <tomsmeding> | it's indeed probably a single missed optimisation somewhere that makes the carefully constructed castle collapse |
| 2024-06-12 21:19:47 +0200 | <monochrom> | I think we would call that a house of cards. :) |
| 2024-06-12 21:19:52 +0200 | <tomsmeding> | ah, we do |
| 2024-06-12 21:20:31 +0200 | <monochrom> | jenga :) |
| 2024-06-12 21:20:36 +0200 | <int-e> | I'd imagine that bytestring is in the same boat in principle. Maybe a bit simpler and more battle-proven (i.e. GHC and bytestring both have been tuned a bit more to work well together.) |
| 2024-06-12 21:20:51 +0200 | <tomsmeding> | does bytestring have fusion stuff? |
| 2024-06-12 21:20:57 +0200 | <int-e> | yes |
| 2024-06-12 21:21:18 +0200 | <int-e> | it's where stream fusion was first implemented |
| 2024-06-12 21:22:08 +0200 | <tomsmeding> | oh via RULES only |
| 2024-06-12 21:22:14 +0200 | <tomsmeding> | vector does _much_ more than rules |
| 2024-06-12 21:22:28 +0200 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-06-12 21:22:47 +0200 | <tomsmeding> | which, incidentally, is profoundly annoying if you want to figure out how a particular vector operaetion is implemented :p |
| 2024-06-12 21:22:52 +0200 | Batzy | (~quassel@user/batzy) |
| 2024-06-12 21:23:55 +0200 | <tomsmeding> | but I'm not seeing any interesting RULES either, actually, just specialisation |
| 2024-06-12 21:23:57 +0200 | <tomsmeding> | s |
| 2024-06-12 21:24:07 +0200 | <tomsmeding> | am I looking in the wrong place? |
| 2024-06-12 21:24:15 +0200 | andrei_n | (~andrei_n@user/andrei-n:62396) (Ping timeout: 264 seconds) |
| 2024-06-12 21:25:39 +0200 | <tomsmeding> | according to its documentation, bytestring has been rewritten a bunch of times; perhaps you're referring to a past version |
| 2024-06-12 21:25:58 +0200 | euleritian | (~euleritia@dynamic-176-001-140-054.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-12 21:26:16 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-06-12 21:28:16 +0200 | Batzy | (~quassel@user/batzy) (Ping timeout: 268 seconds) |
| 2024-06-12 21:28:59 +0200 | zenex | (~zenex@cpc157775-rdng31-2-0-cust836.15-3.cable.virginm.net) |
| 2024-06-12 21:29:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-12 21:31:04 +0200 | <int-e> | tomsmeding: I /think/ I'm referring to 0.10 with this, but my memory is hazy; it may have been even earlier. https://hackage.haskell.org/package/bytestring-0.10.0.0/docs/src/Data-ByteString-Lazy-Builder-Inte… |
| 2024-06-12 21:32:47 +0200 | alinab | (sid468903@id-468903.helmsley.irccloud.com) (Read error: Connection reset by peer) |
| 2024-06-12 21:32:53 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) (Ping timeout: 268 seconds) |
| 2024-06-12 21:32:55 +0200 | alinab | (sid468903@id-468903.helmsley.irccloud.com) |
| 2024-06-12 21:32:55 +0200 | zenex | (~zenex@cpc157775-rdng31-2-0-cust836.15-3.cable.virginm.net) () |
| 2024-06-12 21:34:44 +0200 | rubin55 | (sid175221@id-175221.hampstead.irccloud.com) (Ping timeout: 256 seconds) |
| 2024-06-12 21:35:31 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-06-12 21:36:23 +0200 | andrei_n | (~andrei_n@user/andrei-n:62396) |
| 2024-06-12 21:37:04 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) (Ping timeout: 246 seconds) |
| 2024-06-12 21:37:59 +0200 | mei | (~mei@user/mei) |
| 2024-06-12 21:38:03 +0200 | rubin55 | (sid175221@id-175221.hampstead.irccloud.com) |
| 2024-06-12 21:38:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-12 21:39:05 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) |
| 2024-06-12 21:39:50 +0200 | bontaq | (~user@ool-45779c03.dyn.optonline.net) (Ping timeout: 256 seconds) |
| 2024-06-12 21:40:15 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) |
| 2024-06-12 21:42:37 +0200 | <tomsmeding> | int-e: I see, for Builder; here it is for current bytestring: https://hackage.haskell.org/package/bytestring-0.12.1.0/docs/src/Data.ByteString.Builder.Internal.… |
| 2024-06-12 21:43:14 +0200 | <tomsmeding> | it seems all the fusion is left to ghc, however; there are no relevant RULES |
| 2024-06-12 21:43:30 +0200 | <tomsmeding> | only ones that reassociate operations to make it easier for ghc, presumably |
| 2024-06-12 21:46:49 +0200 | ocra8 | (~ocra8@user/ocra8) (Read error: Connection reset by peer) |
| 2024-06-12 21:49:05 +0200 | <int-e> | Yeah AFAIUI the hope in all of this is that GHC will find a lot of case analyses for the ChunkedIOStream type with a known constructor and use the opportunity to elide the construction of that value. That's how fusion actuall happens here. |
| 2024-06-12 21:49:19 +0200 | <tomsmeding> | that sounds pretty robust |
| 2024-06-12 21:49:30 +0200 | <tomsmeding> | if it's just inlining and cast-of-known-constructor |
| 2024-06-12 21:49:36 +0200 | <tomsmeding> | *case |
| 2024-06-12 21:51:40 +0200 | <int-e> | Anyway it's clearly much simpler than what vector is doing these days. |
| 2024-06-12 21:52:45 +0200 | ocra8 | (~ocra8@user/ocra8) |
| 2024-06-12 21:53:28 +0200 | <int-e> | The history is confusing because there's a 2007 paper on this, but the corresponding code never made it into the published bytestring package in that form; instead we have this: https://hackage.haskell.org/package/bytestring-0.9.1.0/docs/src/Data-ByteString-Fusion.html |
| 2024-06-12 21:53:39 +0200 | <tomsmeding> | /urlselect |
| 2024-06-12 21:53:54 +0200 | <tomsmeding> | (I'm good at typing precisely today, it seems) |
| 2024-06-12 21:54:00 +0200 | <tomsmeding> | lol that file |
| 2024-06-12 21:55:38 +0200 | Square | (~Square@user/square) (Remote host closed the connection) |
| 2024-06-12 22:02:52 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-06-12 22:04:15 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2024-06-12 22:12:53 +0200 | son0p | (~ff@186.121.8.17) (Ping timeout: 240 seconds) |
| 2024-06-12 22:24:22 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-06-12 22:30:05 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds) |
| 2024-06-12 22:31:27 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-06-12 22:31:42 +0200 | Batzy | (~quassel@user/batzy) |
| 2024-06-12 22:33:29 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Quit: quit) |
| 2024-06-12 22:40:06 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-06-12 22:53:25 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-06-12 22:59:07 +0200 | andrei_n | (~andrei_n@user/andrei-n:62396) (Quit: Leaving) |
| 2024-06-12 23:04:47 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:7b2b:151c:4735:737f) (Ping timeout: 256 seconds) |
| 2024-06-12 23:07:34 +0200 | Square | (~Square@user/square) |
| 2024-06-12 23:09:10 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-06-12 23:10:06 +0200 | dmj` | (uid72307@id-72307.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-12 23:11:08 +0200 | dcoutts | (~duncan@212.140.138.201) |
| 2024-06-12 23:14:10 +0200 | cpressey | (~weechat@33b62f0c.skybroadband.com) (Quit: WeeChat 4.3.0) |
| 2024-06-12 23:15:13 +0200 | michalz | (~michalz@185.246.207.201) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-06-12 23:19:00 +0200 | dcoutts | (~duncan@212.140.138.201) (Ping timeout: 256 seconds) |
| 2024-06-12 23:20:58 +0200 | dcoutts | (~duncan@212.140.138.201) |
| 2024-06-12 23:23:26 +0200 | EvanR | (~EvanR@user/evanr) (Quit: Leaving) |
| 2024-06-12 23:25:24 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-06-12 23:25:27 +0200 | dcoutts | (~duncan@212.140.138.201) (Ping timeout: 264 seconds) |
| 2024-06-12 23:25:44 +0200 | EvanR | (~EvanR@user/evanr) |
| 2024-06-12 23:26:05 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 240 seconds) |
| 2024-06-12 23:41:53 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:156b:aa72:70b8:c5f5) (Quit: Leaving) |
| 2024-06-12 23:44:49 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-06-12 23:44:49 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-06-12 23:44:49 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-06-12 23:44:49 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-06-12 23:44:49 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Read error: Connection reset by peer) |
| 2024-06-12 23:44:49 +0200 | califax | (~califax@user/califx) (Read error: Connection reset by peer) |
| 2024-06-12 23:44:49 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Read error: Connection reset by peer) |
| 2024-06-12 23:45:25 +0200 | califax | (~califax@user/califx) |
| 2024-06-12 23:45:26 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-06-12 23:45:28 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-06-12 23:45:43 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-06-12 23:45:54 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-06-12 23:46:06 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-12 23:46:52 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2024-06-12 23:47:15 +0200 | Square2 | (~Square4@user/square) |
| 2024-06-12 23:49:36 +0200 | Square | (~Square@user/square) (Ping timeout: 256 seconds) |
| 2024-06-12 23:53:03 +0200 | acidjnk | (~acidjnk@p200300d6e714dc68856d8905203ea039.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-06-12 23:59:10 +0200 | pavonia | (~user@user/siracusa) |