Newest at the top
| 2025-01-11 17:46:04 +0100 | <int-e> | But I guess you can inadvertently make type checking expensive and UndecidableInstances makes that more likely. |
| 2025-01-11 17:46:03 +0100 | <hellwolf> | Per instance declaration of undecidable/ambiguous instances seem a recurring question, and it has open issues tracking it I believe |
| 2025-01-11 17:45:45 +0100 | <kaol> | It was a while ago, may have been some other IncomprehensibleExtension. |
| 2025-01-11 17:45:12 +0100 | <int-e> | The scary extensions start with OverlappingInstances (which is a slippery slope leading towards IncoherentInstances which is the actually scary one) |
| 2025-01-11 17:44:24 +0100 | <int-e> | odd |
| 2025-01-11 17:44:01 +0100 | <kaol> | Or rather, try to add more instances of whatever you make one first. |
| 2025-01-11 17:43:24 +0100 | <kaol> | My experience with UndecidableInstances is that it can make code compile but it may paper over a design issue that will explode when you try to generalise the code more. |
| 2025-01-11 17:43:00 +0100 | <monochrom> | no fireworks? wait til your computer overheats :) |
| 2025-01-11 17:41:56 +0100 | <monochrom> | how I stopped worrying and love strange loops |
| 2025-01-11 17:41:48 +0100 | <int-e> | There are no fireworks. |
| 2025-01-11 17:41:39 +0100 | <int-e> | It's really not so bad... the compiler can fail to terminate (in reasonable time!) for all sorts of reasons. |
| 2025-01-11 17:41:31 +0100 | Digitteknohippie | Digit |
| 2025-01-11 17:40:23 +0100 | <kaol> | Dr. Strangelove and |
| 2025-01-11 17:39:59 +0100 | <int-e> | I personally never worry about enabling UndecidableInstances. |
| 2025-01-11 17:37:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 17:36:31 +0100 | <haskellbridge> | <loonycyborg> seems I can't fool it by attaching TypeError to Proxy or using it in Tagged |
| 2025-01-11 17:35:58 +0100 | <int-e> | I don't think so. (It's essentially a syntactic check... there's no change to how type checking operates outside of checking instance heads.) |
| 2025-01-11 17:35:56 +0100 | <geekosaur> | no, and I suspect it would be problematic |
| 2025-01-11 17:33:39 +0100 | <haskellbridge> | <loonycyborg> Are there more granular ways of enabling Undecidable instances than module-wide? |
| 2025-01-11 17:32:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:30:35 +0100 | Digit | (~user@user/digit) (Ping timeout: 265 seconds) |
| 2025-01-11 17:30:14 +0100 | <geekosaur> | one could argue that the loop checker that gets disabled with `UndecidableInstances` should recognize `TypeError` but I wonder how much extra work that would be |
| 2025-01-11 17:29:14 +0100 | michalz | (~michalz@185.246.207.218) |
| 2025-01-11 17:29:09 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-01-11 17:27:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 17:26:00 +0100 | <geekosaur> | that's not wrong, it follows normal rules and kinda by definition doesn't actually solve any types, so by said normal rules would normally lead to an infinite loop in the typechecker (except that it catches that specifically and aborts) |
| 2025-01-11 17:23:04 +0100 | <haskellbridge> | <loonycyborg> What is the proper way to trigger TypeError from a type family? If I just try to return TypeError as a type ghc says that undecidable instances would be required. |
| 2025-01-11 17:22:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 17:21:00 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-11 17:17:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:14:13 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Read error: Connection reset by peer) |
| 2025-01-11 17:02:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 16:59:58 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 16:58:18 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2025-01-11 16:52:55 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-11 16:52:17 +0100 | <mreh> | e.g. https://github.com/tobbebex/GPipe-Core/blob/4f512f1ea6e6c32bbefaae1be38a68508337b1fa/GPipe-Core/sr… |
| 2025-01-11 16:51:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:50:05 +0100 | <mreh> | these arrows aren't functions |
| 2025-01-11 16:49:50 +0100 | <mreh> | I'm still not entirely clear how it applies to the arrow syntax though |
| 2025-01-11 16:46:34 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-01-11 16:45:21 +0100 | <mreh> | This page was pretty clear https://wiki.haskell.org/Lazy_pattern_match |
| 2025-01-11 16:45:18 +0100 | <geekosaur> | there are other ways to do it (they're syntax sugar for an irrefutable match and a later lambda) but the lazy pattern match syntax is so much cleaner |
| 2025-01-11 16:44:31 +0100 | <geekosaur> | yeh, that's just a lazy pattern match, and indeed they're not used often. but when you need them, you really need them |
| 2025-01-11 16:40:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-11 16:39:25 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-01-11 16:37:27 +0100 | <juri_> | I don't have any questions yet, just looking for general opinions, as i wade in. |
| 2025-01-11 16:37:09 +0100 | <juri_> | is anyone else here a user of the 'repa' library? |
| 2025-01-11 16:37:03 +0100 | Katarushisu | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) Katarushisu |
| 2025-01-11 16:36:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 16:33:37 +0100 | <mreh> | don't see them very often |