Newest at the top
| 2025-01-11 17:58:54 +0100 | <int-e> | https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Mostly_Harmless |
| 2025-01-11 17:58:06 +0100 | <hellwolf> | So, works still needed to clarify this. But we are repeating here... each time this topic brought up, it is the same dicussion :) |
| 2025-01-11 17:57:27 +0100 | <hellwolf> | As this discussion usually lead to, that assessment of "harmless" is very inaccessible to all walks of Haskellers. I don't think it would be surprising that many are deterred by such an extension, and some might still think it's dangerous. |
| 2025-01-11 17:56:32 +0100 | rynite | (~bwkam@user/rynite) rynite |
| 2025-01-11 17:55:19 +0100 | <int-e> | It certainly could be a per class thing but I don't think the demand for that is high. The extension is mostly harmless. |
| 2025-01-11 17:52:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 17:51:15 +0100 | <hellwolf> | I could be irrational though, as people pointing out that it should not be feared as much. |
| 2025-01-11 17:50:57 +0100 | <hellwolf> | that's why I would hope there is per instance declaration for them, that makes it more tamed. |
| 2025-01-11 17:50:12 +0100 | <hellwolf> | Though, at numerous times I could eventually eliminate the usage of UndecidableInstances; if it were used more freely, like what I do with ambiguous types, I might not pay the necessary attention to simplify things when there is opportunity of doing so. |
| 2025-01-11 17:49:06 +0100 | <geekosaur> | that's anything that can lead to looping, from type level to Core-Core passes |
| 2025-01-11 17:48:56 +0100 | <kaol> | I mainly just write Haskell and add extensions when GHC tells me to. It seems weird but it works. |
| 2025-01-11 17:48:17 +0100 | <hellwolf> | that's UndecidableSuperClasses ? |
| 2025-01-11 17:48:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 17:47:27 +0100 | <geekosaur> | I think there are other limits to prevent things getting too out of hand? "let it loop" vs. "too many loops" |
| 2025-01-11 17:47:19 +0100 | <int-e> | So the finer granularity bears fruits. |
| 2025-01-11 17:47:18 +0100 | <kaol> | Sorry, I may not be adding anything to the discussion and it was very likely some other extension. |
| 2025-01-11 17:47:04 +0100 | <int-e> | Which makes sense, since that actually affects type-checking for users of those instances. |
| 2025-01-11 17:46:42 +0100 | <geekosaur> | UndecidableInstances just says "don't exclude entirely valid programs because they can't be proven to terminate at type level" |
| 2025-01-11 17:46:37 +0100 | <int-e> | We have dedicated per-instance pragmas for overlapping instances. |
| 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) |