Newest at the top
| 2025-12-30 20:19:28 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-30 20:16:24 +0100 | Brumaire | (~no@94.140.114.73) (Ping timeout: 252 seconds) |
| 2025-12-30 20:14:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-30 20:11:59 +0100 | Brumaire | (~no@94.140.114.73) Brumaire |
| 2025-12-30 20:11:13 +0100 | Brumaire | (~no@94.140.114.73) (Ping timeout: 244 seconds) |
| 2025-12-30 20:06:42 +0100 | mmohammadi9812 | (~mohammad@141.148.231.175) mmohammadi9812 |
| 2025-12-30 20:04:21 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-30 20:04:00 +0100 | xstill_ | (xstill@fimu/xstill) xstill |
| 2025-12-30 20:00:58 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-30 19:30:33 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2025-12-30 19:28:45 +0100 | StrayB1ts | (~straybits@d205-206-102-121.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2025-12-30 19:28:26 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-30 19:25:33 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-30 19:25:25 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2025-12-30 19:25:01 +0100 | DetourNetworkUK | (DetourNetw@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2025-12-30 19:19:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-30 19:13:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-30 19:03:50 +0100 | Everything | (~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 +0100 | Brumaire | (~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 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-12-30 18:36:54 +0100 | Buliarous | (~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 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-12-30 18:29:49 +0100 | jreicher | (~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 +0100 | Buliarous | (~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 +0100 | janus | (janus@user/janus) janus |
| 2025-12-30 18:16:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-30 18:13:40 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Ping timeout: 245 seconds) |
| 2025-12-30 18:12:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-30 18:11:30 +0100 | aetepe | (~aetepe@188.119.22.20) aetepe |
| 2025-12-30 18:09:19 +0100 | wennefer0 | (~wennefer0@user/wennefer0) wennefer0 |
| 2025-12-30 18:03:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-30 18:02:31 +0100 | Inline | (~User@cgn-195-14-221-74.nc.de) (Ping timeout: 246 seconds) |
| 2025-12-30 17:58:47 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |