Newest at the top
| 2026-01-27 10:35:07 +0100 | <jreicher> | Ta |
| 2026-01-27 10:34:02 +0100 | <tomsmeding> | (that first paper describes the algorithm in GHC before the newest LYG algorithm; the LYG paper ( https://dl.acm.org/doi/pdf/10.1145/3408989 ) claims it has the same complexity as that) |
| 2026-01-27 10:33:41 +0100 | housemate | (~housemate@202.7.248.67) (Quit: https://ineedsomeacidtocalmmedown.space/) |
| 2026-01-27 10:33:12 +0100 | <int-e> | Something like this should do the trick: https://paste.debian.net/hidden/81e97dc6 |
| 2026-01-27 10:33:00 +0100 | <tomsmeding> | it's pattern match exhaustivity checking |
| 2026-01-27 10:32:48 +0100 | <jreicher> | tomsmeding: but why is that pattern matching? |
| 2026-01-27 10:32:27 +0100 | <tomsmeding> | (citation: section 3.4 of https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/icfp2015.pdf ; cited work: https://epubs.siam.org/doi/abs/10.1137/S0097539793246252 ) |
| 2026-01-27 10:32:15 +0100 | <tomsmeding> | jreicher: > Sekar et al. [25] show that the problem of finding redundant clauses is NP-complete, by encoding the boolean satisfiability (SAT) problem into it. |
| 2026-01-27 10:31:41 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-01-27 10:29:18 +0100 | <int-e> | jreicher: I wasn't answering you anyway, just clarifying what I wrote. |
| 2026-01-27 10:29:04 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2026-01-27 10:28:15 +0100 | <jreicher> | That's still vague. |
| 2026-01-27 10:28:04 +0100 | <jreicher> | tomsmeding: what's the parameter then? What's "n", if you know what I mean? |
| 2026-01-27 10:28:02 +0100 | <int-e> | exponential in the number of cases in the source code |
| 2026-01-27 10:27:33 +0100 | <tomsmeding> | jreicher: exhaustivity checking, I think |
| 2026-01-27 10:27:30 +0100 | <int-e> | gentauro: Doesn't ring a bell but I imagine that if you implement Haskell's pattern matching while avoiding matching the same scrutinee twice, you'll end up with cases that have to keep track of exponentially many cases of what has been matched and what hasn't, and correspondingly, exponentially many code paths. |
| 2026-01-27 10:27:22 +0100 | <jreicher> | Linear is inefficient. I just don't understand why it would be worse than linear. |
| 2026-01-27 10:27:10 +0100 | <probie> | The `case` in core is linear, but Haskell itself is a bit more lenient |
| 2026-01-27 10:26:49 +0100 | <lortabac> | efficient compilation of pattern matching is a little more involved |
| 2026-01-27 10:26:27 +0100 | <lortabac> | jreicher: trying all the equations one by one would be inefficient |
| 2026-01-27 10:25:52 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2026-01-27 10:25:31 +0100 | <jreicher> | I still don't get this. I thought pattern matching would be linear. I'm sure I'm misunderstanding the measure. |
| 2026-01-27 10:22:43 +0100 | <tomsmeding> | yes |
| 2026-01-27 10:22:30 +0100 | <int-e> | that seems unrelated to these particular warnings though (and the fact that they can't be overridden in a good way that would indicate call sites that are vetted to be fine) |
| 2026-01-27 10:22:29 +0100 | <tomsmeding> | no sub-exponential algorithm known, perhaps? (I don't know) |
| 2026-01-27 10:21:56 +0100 | <jreicher> | What is an "exponential problem"? |
| 2026-01-27 10:20:37 +0100 | <gentauro> | I recall a talk from SPJ were he stated that PM is and exponential problem |
| 2026-01-27 10:20:15 +0100 | <gentauro> | int-e: pattern matching in Haskell aren't exhaustive by default right? |
| 2026-01-27 10:15:45 +0100 | hakutaku | (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2026-01-27 10:14:26 +0100 | int-e | runs |
| 2026-01-27 10:14:14 +0100 | <int-e> | import Prelude hiding (head); head (x:xs) = x |
| 2026-01-27 10:13:31 +0100 | <f-a> | thanks int-e |
| 2026-01-27 10:13:16 +0100 | <int-e> | {-# OPTIONS_GHC -Wno-x-partial #-} |
| 2026-01-27 10:12:48 +0100 | <probie> | don't use `head` |
| 2026-01-27 10:12:22 +0100 | trickard_ | trickard |
| 2026-01-27 10:12:02 +0100 | <f-a> | What is the proper way to shut `head` deprecation warnings in ghci? |
| 2026-01-27 10:07:39 +0100 | f-a | (ff2a@joined.irc.for-some.fun) f-a |
| 2026-01-27 10:06:34 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-01-27 10:03:28 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:8882:d44f:ddaa:9d2) |
| 2026-01-27 09:53:59 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-01-27 09:49:22 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-01-27 09:39:38 +0100 | prdak | (~Thunderbi@user/prdak) (Quit: prdak) |
| 2026-01-27 09:33:24 +0100 | werneta | (~werneta@71.83.160.242) (Quit: Lost terminal) |
| 2026-01-27 09:31:28 +0100 | chele | (~chele@user/chele) chele |
| 2026-01-27 09:30:39 +0100 | trickard_ | (~trickard@cpe-80-98-47-163.wireline.com.au) |
| 2026-01-27 09:30:26 +0100 | trickard | (~trickard@cpe-80-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2026-01-27 09:28:31 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-01-27 09:21:12 +0100 | acidjnk | (~acidjnk@p200300d6e71719605c0a3441a338f285.dip0.t-ipconnect.de) acidjnk |
| 2026-01-27 09:18:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-01-27 09:13:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |