2025/01/30

Newest at the top

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 +0100merijn(~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 +0100sprotte24(~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 +0100alfiee(~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 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-01-30 22:37:03 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2025-01-30 22:35:10 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-30 22:34:39 +0100jespada(~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb) (Ping timeout: 246 seconds)
2025-01-30 22:34:29 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-01-30 22:23:30 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-01-30 22:19:27 +0100alexherbo2(~alexherbo@2a02-8440-3504-afc6-514f-10cf-f60a-1cf5.rev.sfr.net) (Remote host closed the connection)
2025-01-30 22:15:51 +0100alexherbo2(~alexherbo@2a02-8440-3504-afc6-514f-10cf-f60a-1cf5.rev.sfr.net) alexherbo2
2025-01-30 22:15:04 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-01-30 22:14:40 +0100alexherbo2(~alexherbo@2a02-8440-3504-afc6-21c9-80c8-175a-acbd.rev.sfr.net) (Remote host closed the connection)
2025-01-30 22:14:27 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-01-30 22:09:19 +0100Googulator(~Googulato@2a01-036d-0106-1666-e945-fd21-b920-9aa7.pool6.digikabel.hu)
2025-01-30 22:09:03 +0100Googulator(~Googulato@2a01-036d-0106-1666-e945-fd21-b920-9aa7.pool6.digikabel.hu) (Quit: Client closed)
2025-01-30 22:08:45 +0100nullie(~nullie@nuremberg.nullie.name) nullie
2025-01-30 22:06:23 +0100danza(~danza@user/danza) danza
2025-01-30 22:04:51 +0100alx741(~alx741@186.33.188.229) (Quit: alx741)
2025-01-30 22:03:51 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-01-30 22:01:34 +0100tomboy64(~tomboy64@user/tomboy64) tomboy64
2025-01-30 21:59:23 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-01-30 21:58:50 +0100danza(~danza@user/danza) (Remote host closed the connection)
2025-01-30 21:56:33 +0100takuan(~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection)
2025-01-30 21:55:29 +0100CiaoSen(~Jura@2a05:5800:241:f200:ca4b:d6ff:fec1:99da) (Ping timeout: 260 seconds)
2025-01-30 21:52:40 +0100danza(~danza@user/danza) danza
2025-01-30 21:52:24 +0100danz96699(~danza@user/danza) (Remote host closed the connection)
2025-01-30 21:50:04 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 260 seconds)
2025-01-30 21:48:11 +0100Midjak(~MarciZ@82.66.147.146) (Quit: Leaving)
2025-01-30 21:47:19 +0100tomboy64(~tomboy64@user/tomboy64) (Ping timeout: 260 seconds)
2025-01-30 21:45:27 +0100alfiee(~alfiee@user/alfiee) alfiee