Newest at the top
| 2025-01-11 18:04:25 +0100 | <int-e> | Also accidental compile-time non-termination is far less scary than accidental runtime non-termination. |
| 2025-01-11 18:03:36 +0100 | <int-e> | Which is a check that I guess will save some beginners from doing certain stupid things. But in practice the implemented termination check is woefully naive and excludes a lot of instances where type checking terminates just fine. |
| 2025-01-11 18:03:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:03:17 +0100 | <hellwolf> | I think maybe we could even move it to a GHC warning, and GHC warning can be turned off per definition iirc. |
| 2025-01-11 18:03:06 +0100 | <c_wraith> | There are a lot of shapes of recursive data type that just need UndecidableInstances to write *any* instance for. |
| 2025-01-11 18:01:56 +0100 | <monochrom> | Whereas if you have the correct understanding, then you will find that, e.g., Data Types a la Carte needs UndecidableInstances and it is a correct use. |
| 2025-01-11 18:01:28 +0100 | <hellwolf> | I sorta understand. But not everyone is off type theory background to understand its implication... |
| 2025-01-11 18:00:54 +0100 | <int-e> | hellwolf: Literally the only thing that UndecidableInstances does is turn off the "The constraint ... is no smaller than the instance head ..." error. |
| 2025-01-11 18:00:53 +0100 | <monochrom> | IMO the conflicting experiences are due to conflicting understandings of, for example, what "instance Ord a => Eq a" means. One of the two understandings, the more popular one, is wrong, and it also leads you to misuse UndecidableInstances, and it still won't do what you think. |
| 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 |