Newest at the top
| 2024-11-16 23:21:06 +0100 | <hellwolf> | say no more, let me write a test case |
| 2024-11-16 23:20:11 +0100 | Square | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2024-11-16 23:18:55 +0100 | <geekosaur> | actually (b) is wrong, instance dictionaries are value level but bypass the limit unless they're compiled internally to magic named records (I know they are at Core level, but not sure about before that) |
| 2024-11-16 23:11:28 +0100 | <hellwolf> | okay, made the classes less trivial, with one function only. still okay, but notice a tiny little delay when loading through ghci |
| 2024-11-16 23:11:11 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2024-11-16 23:10:02 +0100 | <hellwolf> | 1000s is fine too, I hope the empty class did not mattered. |
| 2024-11-16 23:08:31 +0100 | <hellwolf> | 100 constraints was fine |
| 2024-11-16 23:07:31 +0100 | sdrfan123 | (~sdrfan123@2607:fb91:db5:49ea:b971:f45f:2d53:96d1) |
| 2024-11-16 23:06:35 +0100 | <hellwolf> | say no more, let me try |
| 2024-11-16 23:02:12 +0100 | Jeff94 | (~Jeff@2603:8000:0:d7:bc06:28cf:84d9:61b8) (Client Quit) |
| 2024-11-16 23:01:56 +0100 | <geekosaur> | (at least, I think that becomes a tuple) |
| 2024-11-16 23:01:11 +0100 | <geekosaur> | (b) type level tuples already exceed the value level limit (consider the size of the Foldable instance dictionary) |
| 2024-11-16 23:01:10 +0100 | Jeff94 | (~Jeff@2603:8000:0:d7:bc06:28cf:84d9:61b8) |
| 2024-11-16 23:00:36 +0100 | <geekosaur> | (a) it is actually neither a value level tuple nor a normal type level tuple |
| 2024-11-16 22:57:21 +0100 | <hellwolf> | GHC stress test |
| 2024-11-16 22:54:17 +0100 | <geekosaur> | I would not be surprised if the typechecker falls over before hitting it though 🙂 |
| 2024-11-16 22:53:41 +0100 | <geekosaur> | I don't know |
| 2024-11-16 22:53:29 +0100 | <hellwolf> | or it is unlimited. |
| 2024-11-16 22:53:22 +0100 | <hellwolf> | is there also a 64 constraint limit :D |
| 2024-11-16 22:53:16 +0100 | <hellwolf> | let me go back to the tuplite constraint approach... |
| 2024-11-16 22:52:48 +0100 | <geekosaur> | check the Report |
| 2024-11-16 22:52:37 +0100 | <hellwolf> | oh wow, that's stronger statement than I anticipated. I thought it was just a normal day flame-wars in geeks town. |
| 2024-11-16 22:52:35 +0100 | <geekosaur> | or a worse one if ghc hq decides to e.g. make it mean something related to RequiredTypeArguments |
| 2024-11-16 22:51:33 +0100 | <geekosaur> | so if bluefin is doing so they may be in for a surprise in a future ghc version |
| 2024-11-16 22:51:17 +0100 | <geekosaur> | anyway, strictly speaking it's a parser bug, and as such relying on it is a bad idea |
| 2024-11-16 22:48:17 +0100 | eax | zenmov |
| 2024-11-16 22:46:58 +0100 | <geekosaur> | I don't do videos for the most part (sensory issues) |
| 2024-11-16 22:46:40 +0100 | <hellwolf> | (if you haven't watched, check it out) |
| 2024-11-16 22:46:15 +0100 | <hellwolf> | well, I saw a recent video from bluefin, it was used there exclusively |
| 2024-11-16 22:46:13 +0100 | <geekosaur> | in patsyns it distinguishes required contexts from provided contexts |
| 2024-11-16 22:45:48 +0100 | <hellwolf> | I did not know that. Actually, I rarely used the second one, and didn't realize it was correct. |
| 2024-11-16 22:45:41 +0100 | <geekosaur> | so I wouldn't want to rely on it working because it might suddenly start to mean something different in the future |
| 2024-11-16 22:45:22 +0100 | <hellwolf> | oh? |
| 2024-11-16 22:45:08 +0100 | <hellwolf> | *flavors war |
| 2024-11-16 22:45:07 +0100 | <geekosaur> | strictly speaking the latter is wrong, and it means something different in some contexts (notably pattern synonyms) |
| 2024-11-16 22:44:22 +0100 | <hellwolf> | I just found that my emacs default formatter coping with the latter better. |
| 2024-11-16 22:43:55 +0100 | <hellwolf> | rapid file mode... is this a Haskellite flame war: (a, b) => ... vs. a => b => ... |
| 2024-11-16 22:40:08 +0100 | <hellwolf> | right. makes sense. |
| 2024-11-16 22:37:26 +0100 | <int-e> | you'll either have to hide the import or use qualified names if you want to use such a function though |
| 2024-11-16 22:36:11 +0100 | <geekosaur> | correct, because they're not defined within the same module/scope. |
| 2024-11-16 22:34:59 +0100 | <hellwolf> | Overlapping function names from Prelude does not generate warnings, it seems acceptable? |
| 2024-11-16 22:34:23 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.50) (Quit: Leaving) |
| 2024-11-16 22:31:07 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-11-16 22:21:42 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2024-11-16 22:20:27 +0100 | Guest28 | (~Guest63@2800:a4:10c5:4200:c0d2:e4ff:567a:64d8) |
| 2024-11-16 22:20:00 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 272 seconds) |
| 2024-11-16 22:15:23 +0100 | eax | (~eax@user/zenmov) zenmov |
| 2024-11-16 22:03:37 +0100 | troojg | (~troojg@user/troojg) troojg |
| 2024-11-16 22:02:07 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-16 22:01:06 +0100 | <hellwolf> | I think I found a solution, maybe it is common for eDSLs: say I have a keyword "match", I just need to do (BlockArguments alert) `match a \case -> Maybe a' -> a'; Nothing -> some_def`, where by a just needs to be constrained by an imaginary "EnumerablePatternMatchingCases", such that the codegen can just enumerate through the cases and generate code for all branches accordingly. |