Newest at the top
| 2025-01-30 23:02:59 +0100 | connrs | (~connrs@user/connrs) connrs |
| 2025-01-30 22:59:46 +0100 | monochrm | monochrom |
| 2025-01-30 22:59:46 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-30 22:58:27 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-30 22:58:07 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-30 22:56:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-30 22:55:01 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-01-30 22:52:49 +0100 | connrs | (~connrs@user/connrs) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-30 22:52:11 +0100 | <haskellbridge> | <sm> troubleshooting complex problems over irc is pretty hard sometimes |
| 2025-01-30 22:51:36 +0100 | <dminuoso> | Fair. |
| 2025-01-30 22:51:31 +0100 | <euouae> | well my point is that /you/ could do it and I couldn't :P |
| 2025-01-30 22:51:29 +0100 | <dminuoso> | C++ template instantiation errors are.. something else. |
| 2025-01-30 22:51:10 +0100 | <dminuoso> | euouae: I think the error was not that complicated. The main reason it took me a moment, was because I had no mental picture of the types involved. |
| 2025-01-30 22:50:39 +0100 | <euouae> | dminuoso: experienced haskellers obviously see it differently from novices ;) if you know a lot of C++ you can figure out what the template errors are as well... |
| 2025-01-30 22:49:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-30 22:49:42 +0100 | <haskellbridge> | <sm> euouae: would adding more type signatures have helped ? It's very good advice |
| 2025-01-30 22:49:41 +0100 | <dminuoso> | euouae: In hindsight, it was quite related. |
| 2025-01-30 22:48:52 +0100 | <euouae> | it was some type inference issue where the error was unrelated to the actual issue |
| 2025-01-30 22:48:40 +0100 | <euouae> | That's exactly the situation that happened some days ago when I asked a megaparsec question here and you answered it |
| 2025-01-30 22:48:10 +0100 | <dminuoso> | But alas, there is not even a WIP for this in GHC. |
| 2025-01-30 22:47:53 +0100 | <dminuoso> | It still would not necessarily pin point to the cause, but you could at least identify all the moving parts that dont fit for some reason. |
| 2025-01-30 22:47:29 +0100 | <dminuoso> | euouae: There's some potential to improve GHC errors that we bring up every now and then. Some ML languages have whats called a type error slicer, which essentially marks all the spots in your program that somehow contributed to a given type error. |
| 2025-01-30 22:45:01 +0100 | <euouae> | interesting, will do |
| 2025-01-30 22:42:56 +0100 | <dminuoso> | Plus, the type annotations help document your code, so twice the reason to annotate everything with a type. |
| 2025-01-30 22:42:20 +0100 | <dminuoso> | But by annotating as much as you can, you greatly limit how far these unification errors can propagate. |
| 2025-01-30 22:41:56 +0100 | <dminuoso> | It's an unfortunate consequence of advanced type systems, that you get type unification errors in seemingly random places unrelated to the mistake. |
| 2025-01-30 22:41:20 +0100 | sprotte24 | (~sprotte24@p200300d16f0f520069bfd2b9cee1df34.dip0.t-ipconnect.de) |
| 2025-01-30 22:40:46 +0100 | <dminuoso> | Maybe it helps to think of generalization not as something that lets you avoid writing type signatures, but a feature that lets you write quantified types very liberally. |
| 2025-01-30 22:39:40 +0100 | <dminuoso> | The more the type checker is constrained, the less it can infer and generalize. |
| 2025-01-30 22:39:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-30 22:39:31 +0100 | <dminuoso> | euouae: The general technique to avoid or deal with typing errors generally, is to annotate as much as you can. |
| 2025-01-30 22:39:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-30 22:37:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-01-30 22:35:10 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-30 22:34:39 +0100 | jespada | (~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb) (Ping timeout: 246 seconds) |
| 2025-01-30 22:34:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-30 22:23:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-01-30 22:19:27 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-afc6-514f-10cf-f60a-1cf5.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-30 22:15:51 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-afc6-514f-10cf-f60a-1cf5.rev.sfr.net) alexherbo2 |
| 2025-01-30 22:15:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-30 22:14:40 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-afc6-21c9-80c8-175a-acbd.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-30 22:14:27 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-30 22:09:19 +0100 | Googulator | (~Googulato@2a01-036d-0106-1666-e945-fd21-b920-9aa7.pool6.digikabel.hu) |
| 2025-01-30 22:09:03 +0100 | Googulator | (~Googulato@2a01-036d-0106-1666-e945-fd21-b920-9aa7.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-01-30 22:08:45 +0100 | nullie | (~nullie@nuremberg.nullie.name) nullie |
| 2025-01-30 22:06:23 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-30 22:04:51 +0100 | alx741 | (~alx741@186.33.188.229) (Quit: alx741) |
| 2025-01-30 22:03:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-01-30 22:01:34 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2025-01-30 21:59:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |