2025/12/30

Newest at the top

2025-12-30 19:30:33 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds)
2025-12-30 19:28:45 +0100StrayB1ts(~straybits@d205-206-102-121.abhsia.telus.net) (Ping timeout: 244 seconds)
2025-12-30 19:28:26 +0100ttybitnik(~ttybitnik@user/wolper) ttybitnik
2025-12-30 19:25:33 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection)
2025-12-30 19:25:25 +0100DetourNetworkUK(~DetourNet@user/DetourNetworkUK) DetourNetworkUK
2025-12-30 19:25:01 +0100DetourNetworkUK(DetourNetw@user/DetourNetworkUK) (Read error: Connection reset by peer)
2025-12-30 19:19:58 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-12-30 19:13:20 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-30 19:03:50 +0100Everything(~Everythin@172-232-54-192.ip.linodeusercontent.com) Everything
2025-12-30 19:03:45 +0100 <[exa]> janus: btw btw, for some definition of your "parts of type inference that relate to quantifications", THIH might actually qualify there as two-step.
2025-12-30 19:00:49 +0100 <[exa]> janus: for the former, I think there are even languages in the wild that do it that way -- after the type inference&checking is complete you can specialize ("monomorphize") stuff as you like (w.r.t. to the constraints), and you'll never hit issues.
2025-12-30 18:58:39 +0100 <[exa]> janus: if you only have single-parameter typeclasses as in THIH, the two-step approach should AFAIK work. On the other hand, with more advanced stuff (type families, MPTCs) you can essentially simulate functions on types, and you have to mix the checking with the typelevel computation. (E.g., type unification may depend on the "result" of a type family application.)
2025-12-30 18:42:59 +0100 <c_wraith> (also, I think it would be literally impossible to have a compiler fully solve types without the open world assumption. I think you run into the halting problem.)
2025-12-30 18:40:59 +0100Brumaire(~no@94.140.114.73) Brumaire
2025-12-30 18:40:28 +0100 <c_wraith> As opposed to saying that the open world assumption only applies in some cases, and then needing to learn rules about when it does and when it doesn't.
2025-12-30 18:37:37 +0100weary-traveler(~user@user/user363627) user363627
2025-12-30 18:36:54 +0100Buliarous(~gypsydang@46.232.210.139) Buliarous
2025-12-30 18:36:13 +0100 <ncf> as opposed to what?
2025-12-30 18:34:22 +0100 <c_wraith> There are some some important technical simplifications enabled by that, but the real value is just having a single set of rules.
2025-12-30 18:32:38 +0100 <c_wraith> Even when that's not actually possible, like when using DataKinds
2025-12-30 18:32:19 +0100 <c_wraith> Broadly, Haskell types assume that a type variable might be instantiated at a type that you know nothing about when writing the code that uses it.
2025-12-30 18:31:34 +0100jreicher(~user@user/jreicher) jreicher
2025-12-30 18:29:49 +0100jreicher(~user@user/jreicher) (Ping timeout: 246 seconds)
2025-12-30 18:27:37 +0100 <ncf> what "parts of type inference that relate to quantifications" do you have in mind?
2025-12-30 18:26:43 +0100 <ncf> well, of course not. Bool isn't the only type in the universe with an Eq instance
2025-12-30 18:24:24 +0100 <janus> for example, if I have _only_ Eq Bool (and not Eq Int), and i see `a == b` I can't deduce that a and b must be Bool, IIRC
2025-12-30 18:23:43 +0100 <janus> intuitively, it seems that they could run last, since you can't e.g. use the knowledge that you have a certain set of instances to deduce what a type variable in a quantifier is
2025-12-30 18:22:41 +0100Buliarous(~gypsydang@46.232.210.139) (Remote host closed the connection)
2025-12-30 18:20:48 +0100 <janus> now, what i don't understand, is whether the parts of type inference that relate to quantifications can run last, or whether they must be interleaved with other type checking steps
2025-12-30 18:20:03 +0100 <janus> then, if it uses type class methods, to execute the program, i need to know which instace to pick
2025-12-30 18:19:26 +0100 <janus> like, if i have a program, and i want to run type inference on it
2025-12-30 18:19:06 +0100 <janus> is it correct that equality constraints can not be affected by quantified types?
2025-12-30 18:18:25 +0100janus(janus@user/janus) janus
2025-12-30 18:16:56 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-12-30 18:13:40 +0100wennefer0(~wennefer0@user/wennefer0) (Ping timeout: 245 seconds)
2025-12-30 18:12:20 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-30 18:11:30 +0100aetepe(~aetepe@188.119.22.20) aetepe
2025-12-30 18:09:19 +0100wennefer0(~wennefer0@user/wennefer0) wennefer0
2025-12-30 18:03:37 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-12-30 18:02:31 +0100Inline(~User@cgn-195-14-221-74.nc.de) (Ping timeout: 246 seconds)
2025-12-30 17:58:47 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-30 17:56:09 +0100shaeto(~Shaeto@user/shaeto) (Ping timeout: 252 seconds)
2025-12-30 17:54:10 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2025-12-30 17:51:21 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection)
2025-12-30 17:46:38 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-12-30 17:41:53 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-30 17:31:13 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-12-30 17:26:13 +0100Pozyomka(~pyon@user/pyon) pyon
2025-12-30 17:25:48 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2025-12-30 17:17:24 +0100jmcantrell_jmcantrell