Newest at the top
| 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. |
| 2024-11-16 21:55:51 +0100 | <geekosaur> | especially in Haskell, because that is strict by default and therefore drives evaluation |
| 2024-11-16 21:54:11 +0100 | <geekosaur> | but yes, the base assumption is pattern matching on constructors |
| 2024-11-16 21:53:26 +0100 | <geekosaur> | this is alos why MukltiWayIf has the syntax it does, since the conversion to such a case with multiple guards is trivial |
| 2024-11-16 21:52:51 +0100 | <geekosaur> | `if` normally becomes a guard in a dummy `case` (`case () of () | …`) |
| 2024-11-16 21:52:20 +0100 | <hellwolf> | Without, you may emulate with if isConstructorA a then .. else if isCOnstructorB .. and so on. |
| 2024-11-16 21:51:33 +0100 | <hellwolf> | Maybe a bad formulation of the question. I guess ADT by definition needs pattern-matching/case analysis. |
| 2024-11-16 21:50:31 +0100 | _xor5 | _xor |
| 2024-11-16 21:50:30 +0100 | _xor | (~xor@ip-66-42-132-175.dynamic.fuse.net) (Ping timeout: 252 seconds) |
| 2024-11-16 21:50:04 +0100 | <hellwolf> | Is the advantage of case/pattern matching, over the if-then-else chains, in its ability to do exhaustiveness checking? |