2025/12/11

Newest at the top

2025-12-11 18:33:31 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh
2025-12-11 18:25:13 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 264 seconds)
2025-12-11 18:21:59 +0100chele(~chele@user/chele) (Remote host closed the connection)
2025-12-11 18:20:30 +0100merijn(~merijn@77.242.116.146) merijn
2025-12-11 18:18:27 +0100Googulator87Googulator
2025-12-11 18:17:13 +0100tv(~tv@user/tv) tv
2025-12-11 18:15:58 +0100trickard_(~trickard@cpe-83-98-47-163.wireline.com.au)
2025-12-11 18:15:45 +0100trickard_(~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-12-11 18:15:42 +0100Googulator87(~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu)
2025-12-11 18:13:09 +0100spew(~spew@user/spew) spew
2025-12-11 18:12:55 +0100Tuplanolla(~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla
2025-12-11 18:10:47 +0100spew(~spew@user/spew) (Read error: Connection reset by peer)
2025-12-11 18:09:49 +0100 <milan> Guyz Am I out of luck if I want to use Data.Text in application build with -XSafe?
2025-12-11 18:08:35 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 240 seconds)
2025-12-11 18:08:27 +0100milan(~milan@88.212.61.169)
2025-12-11 18:08:13 +0100skum(~skum@user/skum) (Quit: WeeChat 4.8.1)
2025-12-11 18:02:14 +0100merijn(~merijn@77.242.116.146) merijn
2025-12-11 17:53:17 +0100Guest87(~Guest87@2405:201:d006:986f:5c73:3a20:69d:7d07)
2025-12-11 17:49:55 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 240 seconds)
2025-12-11 17:46:40 +0100zeroyin
2025-12-11 17:46:36 +0100yinzero
2025-12-11 17:45:17 +0100merijn(~merijn@77.242.116.146) merijn
2025-12-11 17:45:02 +0100 <dolio> Even if you know the provenance of type variables, I don't know that the further idea makes sense.
2025-12-11 17:43:45 +0100tv(~tv@user/tv) (Read error: Connection reset by peer)
2025-12-11 17:42:20 +0100karenw(~karenw@user/karenw) (Ping timeout: 244 seconds)
2025-12-11 17:41:38 +0100 <haskellbridge> interesting problem for sure
2025-12-11 17:41:35 +0100 <haskellbridge> <matti palli> Right. At the moment there is no distinction, and thinking about it might be that typechecking levels could be an issue, i.e. when do you unify with a hole type variable in the new schema
2025-12-11 17:41:16 +0100spew_spew
2025-12-11 17:41:15 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 240 seconds)
2025-12-11 17:40:43 +0100spew(~spew@user/spew) (Ping timeout: 255 seconds)
2025-12-11 17:40:12 +0100spew_(~spew@user/spew) spew
2025-12-11 17:35:22 +0100bggd_(~bgg@2a01:e0a:fd5:f510:fb9e:194f:f1d5:eb88) (Remote host closed the connection)
2025-12-11 17:32:47 +0100 <kuribas> Yes "fromJust :: Maybe a -> a", then "?hole ~ Maybe ?sub_hole", and "Show ?sub_hole" is deferred.
2025-12-11 17:32:30 +0100spew(~spew@user/spew) spew
2025-12-11 17:32:06 +0100 <haskellbridge> SPJ bugged me about this, saying we should add provenance to type variables for improved errors. If you had that you could improve holes as well
2025-12-11 17:32:06 +0100 <haskellbridge> <matti palli> tomsmeding: hmm yes interesting
2025-12-11 17:31:46 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-12-11 17:30:58 +0100lucabtz(~lucabtz@user/lucabtz) (Remote host closed the connection)
2025-12-11 17:30:36 +0100 <tomsmeding> good luck :p
2025-12-11 17:30:29 +0100 <kuribas> tomsmeding: right
2025-12-11 17:30:28 +0100 <tomsmeding> ok I have to go, sorry
2025-12-11 17:30:21 +0100 <tomsmeding> I think
2025-12-11 17:30:19 +0100 <tomsmeding> matti: kuribas is arguing that a type variable "arising from" a hole originally should have a little tag saying so, and when unifying two type variables, you take the union of the tags
2025-12-11 17:29:49 +0100 <haskellbridge> <matti palli> kuribas: but it doesn’t, it belongs to the undefined or the read
2025-12-11 17:29:45 +0100 <tomsmeding> does the `a` in the `Maybe a` that is the type of `_`, arise from the hole?
2025-12-11 17:29:30 +0100 <tomsmeding> what about `show (fromJust _)`?
2025-12-11 17:29:18 +0100 <kuribas> tomsmeding: they are now, but like I said, I would tag it as belonging to a hole.
2025-12-11 17:28:54 +0100 <tomsmeding> so they're rewritten in some direction, and one of the two disappears
2025-12-11 17:28:43 +0100 <tomsmeding> but the unification variable resulting from `read ""` and the one resulting from `_` are the same to GHC
2025-12-11 17:28:29 +0100 <kuribas> yes