Newest at the top
| 2024-11-15 00:41:13 +0100 | acidjnk | (~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-11-15 00:34:10 +0100 | ljdarj1 | ljdarj |
| 2024-11-15 00:34:10 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-11-15 00:31:05 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-15 00:30:32 +0100 | <carbolymer> | ah |
| 2024-11-15 00:30:01 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Remote host closed the connection) |
| 2024-11-15 00:29:03 +0100 | <jackdk> | The problem is I didn't know `a` at the time. (I was trying to write some servant-flavoured stuff, and wanted to provide an analogue to `ToServantApi` that extracted a single field). So I don't actually know the final type (because there are other TFs involved) but I know GHC does |
| 2024-11-15 00:26:44 +0100 | <carbolymer> | jackdk: maybe something in this direction https://paste.tomsmeding.com/Og2LnIpN ? |
| 2024-11-15 00:24:54 +0100 | nek0 | (~nek0@user/nek0) (Quit: The Lounge - https://thelounge.chat) |
| 2024-11-15 00:20:06 +0100 | <carbolymer> | s/though/tough |
| 2024-11-15 00:19:05 +0100 | <carbolymer> | jackdk: ah, you can't modify the original class - that' s though |
| 2024-11-15 00:10:34 +0100 | rvalue- | rvalue |
| 2024-11-15 00:07:19 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 260 seconds) |
| 2024-11-15 00:06:26 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2024-11-15 00:03:51 +0100 | <jackdk> | carbolymer: I don't understand your suggestion. The typeclass I want to type-family-ify exists and I cannot change it (concrete example: `GHC.Records.HasField`), but I want a type family that can select the field type. This example fails with "The RHS of an associated type declaration mentions out-of-scope variable ‘z’ All such variables must be bound on the LHS" https://www.irccloud.com/pastebin/4aygJmq9/MakeATypeFamily.hs |
| 2024-11-14 23:54:44 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4913:54f9:72cb:8a89) |
| 2024-11-14 23:50:18 +0100 | <carbolymer> | or `class (F x y ~ z) => Foo x y z where F x y :: Type` |
| 2024-11-14 23:49:53 +0100 | <carbolymer> | F x y :: Type |
| 2024-11-14 23:49:53 +0100 | <carbolymer> | class Foo' x y where |
| 2024-11-14 23:49:53 +0100 | <carbolymer> | jackdk: well why not: |
| 2024-11-14 23:48:37 +0100 | <carbolymer> | https://wiki.haskell.org/Functional_dependencies_vs._type_families |
| 2024-11-14 23:48:37 +0100 | <carbolymer> | https://gitlab.haskell.org/ghc/ghc/-/wikis/tf-vs-fd |
| 2024-11-14 23:48:37 +0100 | <carbolymer> | thanks geekosaur. I've found some resources on tf vs fd: |
| 2024-11-14 23:48:22 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-14 23:45:53 +0100 | <geekosaur> | (aside from the big one, that ghc isn't going to get actual type lambdas that way possibly ever) |
| 2024-11-14 23:45:32 +0100 | <jackdk> | I had hoped that there was a decent idiom for writing a type family that could compute z from `class Foo x y z | x y -> z` but nobody could tell me one |
| 2024-11-14 23:45:26 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-14 23:45:19 +0100 | <geekosaur> | does this mean there are still some issues with tyfams? |
| 2024-11-14 23:45:01 +0100 | <geekosaur> | huh |
| 2024-11-14 23:44:44 +0100 | <geekosaur> | I mean, we've already ditched backward compatibility in so many other ways, anyone who wants to stay with mtl+fundeps can keep using mtl2 |
| 2024-11-14 23:44:30 +0100 | <jackdk> | Just yesterday I wanted to turn a relation expressed in fundeps into a type-family-shaped thing and the best suggestion I got was "don't, pick over the type using generics instead" |
| 2024-11-14 23:44:19 +0100 | <shapr> | The Revenge of, uh, something |
| 2024-11-14 23:44:02 +0100 | Everything | (~Everythin@178-133-104-20.mobile.vf-ua.net) Everything |
| 2024-11-14 23:43:48 +0100 | <geekosaur> | …but that was over a decade ago. maybe it's time for mtl3: the type families edition |
| 2024-11-14 23:43:10 +0100 | <geekosaur> | (and maybe a performance issue) |
| 2024-11-14 23:42:52 +0100 | <geekosaur> | (IIRC there were a few problems with type families back then that meant the mtl folks went with monads-fd, including a bug in older ghcs) |
| 2024-11-14 23:42:29 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2024-11-14 23:42:21 +0100 | Everything | (~Everythin@178-133-104-20.mobile.vf-ua.net) (Ping timeout: 252 seconds) |
| 2024-11-14 23:41:52 +0100 | <geekosaur> | I do sometimes wonder what the Haskell ecosystem would look like now if monads-tf had won out over monads-fd as the successor to mtl1 |
| 2024-11-14 23:41:50 +0100 | xff0x | (~xff0x@ai080132.d.east.v6connect.net) (Ping timeout: 255 seconds) |
| 2024-11-14 23:40:56 +0100 | <shapr> | yeah, just curious what you thought |
| 2024-11-14 23:40:45 +0100 | <geekosaur> | I'm not sure they're more principled, since I'm not really a type theory or type level wonk |
| 2024-11-14 23:40:32 +0100 | shapr | thinks about that |
| 2024-11-14 23:40:22 +0100 | <geekosaur> | I think in some sense they fit Haskell better, because fundeps are a chunk of Prolog imported into the type system |
| 2024-11-14 23:39:47 +0100 | <shapr> | geekosaur: do you think type families are more principled? |
| 2024-11-14 23:38:08 +0100 | <geekosaur> | many people consider the latter mroe principled, but functional dependencies have been around longer and most standard libraries still use them |
| 2024-11-14 23:37:39 +0100 | <geekosaur> | they are, and yes, they're essentially identical. one uses a functional dependency to establish a relationship between types, the other a type family that is associated with the typeclass ("associated type family") |
| 2024-11-14 23:24:36 +0100 | emfrom | (~emfrom@78.243.183.111) (Remote host closed the connection) |
| 2024-11-14 23:23:09 +0100 | CoolMa7_ | (~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-11-14 23:22:02 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |