Newest at the top
| 2025-01-11 18:57:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-11 18:52:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:50:14 +0100 | <bailsman> | an insane thing to want? (I'm discouraged by the fact that it does not seem to already exist) |
| 2025-01-11 18:50:13 +0100 | <bailsman> | I have a record full of IORefs and IOVectors. I would like to make a function that can make a frozen copy of it - having essentially the same type but all the IORefs replaced by the underlying and all the IOVectors replaced by frozen vectors. Is this something I can do with generics? Write "deriving freezable" or something like this and get a freeze that works on any such mutable record? Is this |
| 2025-01-11 18:46:16 +0100 | <haskellbridge> | <Jade> hellwolf @irc_libera.chat_hellwolf:kf8nh.com: we don't have scoped warning enable/disable yet, there's a ticket which has been open for quite some time |
| 2025-01-11 18:41:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 18:38:14 +0100 | rynite | (~bwkam@user/rynite) (Quit: WeeChat 4.4.1) |
| 2025-01-11 18:34:59 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-11 18:34:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:32:06 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-01-11 18:30:40 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-01-11 18:30:12 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-01-11 18:26:46 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 18:25:52 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) acidjnk |
| 2025-01-11 18:24:00 +0100 | sim590 | (~simon@24-122-69-233.resi.cgocable.ca) (Ping timeout: 276 seconds) |
| 2025-01-11 18:23:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-11 18:18:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 18:17:34 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-11 18:10:33 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2025-01-11 18:08:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 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 |