Newest at the top
| 2025-10-25 18:16:44 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-10-25 17:27:22 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 2025-10-25 16:51:13 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-10-25 16:46:23 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-10-25 14:29:32 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-10-25 13:59:25 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-25 13:54:56 +0200 | ft | (~ft@mue-88-130-106-235.dsl.tropolys.de) ft |
| 2025-10-25 13:34:07 +0200 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2025-10-25 13:23:39 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2025-10-25 13:10:23 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-10-25 08:24:18 +0200 | Enrico63 | (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-25 08:18:11 +0200 | ft | (~ft@p4fc2aaeb.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-10-25 07:27:17 +0200 | mathstuf | (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 256 seconds) |
| 2025-10-25 07:01:53 +0200 | Enrico63 | (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) Enrico63 |
| 2025-10-25 06:02:40 +0200 | td_ | (~td@i53870908.versanet.de) td_ |
| 2025-10-25 06:01:13 +0200 | td_ | (~td@i5387091A.versanet.de) (Ping timeout: 264 seconds) |
| 2025-10-25 05:57:28 +0200 | <Leary> | Err, `representational`*. |
| 2025-10-25 05:52:57 +0200 | <Leary> | If GHC would look under the newtypes itself, it could re-infer `representable` after `f` is specialised to `IO`, alas ... |
| 2025-10-25 05:52:04 +0200 | <Leary> | The issue is that GHC has to give conservative roles to things like `ReaderT r f a` since `a` is under an unknown `f`, and `X` inherits the bad role from it. |
| 2025-10-25 05:50:46 +0200 | <Leary> | No, even if you tried to declare a less restrictive role, GHC would reject it. |
| 2025-10-25 05:50:23 +0200 | <geekosaur> | xmonad's core predates them by something like a decade, which is why we don't declare any type roles and therefore ghc takes the safe default of "nominal" |
| 2025-10-25 05:49:48 +0200 | <geekosaur> | and I don't think type roles existed back then |
| 2025-10-25 05:49:27 +0200 | <mathstuf> | though i admit i was not mucking with typeclasses that much there |
| 2025-10-25 05:49:18 +0200 | <mathstuf> | oh i did lots more haskell years ago (i contributed X.H.DynamicBars and X.H.ToggleHooks) |
| 2025-10-25 05:47:57 +0200 | <geekosaur> | (one could in fact argue that type roles are a hack around Haskell's type system not being strong enough… but I don't think anyone gets this simultaneously right and practicably usable, except SML/NJ and OCaml in some situations) |
| 2025-10-25 05:46:48 +0200 | <geekosaur> | also, different FP languages have different solutions to the problem type roles solve here |
| 2025-10-25 05:46:30 +0200 | redgloboli | (~redglobol@user/redgloboli) redgloboli |
| 2025-10-25 05:46:28 +0200 | <geekosaur> | it does take some getting used to |
| 2025-10-25 05:44:51 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2025-10-25 05:31:20 +0200 | <mathstuf> | too much Rust :) |
| 2025-10-25 05:30:20 +0200 | <mathstuf> | ah |
| 2025-10-25 05:29:16 +0200 | <Leary> | mathstuf: Check the logs in the topic for a line you missed. |
| 2025-10-25 05:28:24 +0200 | <mathstuf> | is `instance (PureLayout l a) => LayoutClass l a where …` not suitable? |
| 2025-10-25 05:28:02 +0200 | <mathstuf> | oh, not sure i was looking at `deriving` at all |
| 2025-10-25 05:15:15 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-25 04:59:15 +0200 | <geekosaur> | even if you would write the exact same instance yourself; you're assumed to know what you're doing, the compiler doesn't assume it knows what you're doing |
| 2025-10-25 04:58:03 +0200 | <geekosaur> | ghc won't allow automatic deriving if a type variable involved has a `nominal` type role |
| 2025-10-25 04:56:34 +0200 | <geekosaur> | that's not the question. the question is whether the type roles on X would pass muster with deriving-via |
| 2025-10-25 04:56:09 +0200 | <mathstuf> | the default `doLayout` wouldnt suffice? |
| 2025-10-25 04:55:50 +0200 | <geekosaur> | right, but you're deriving LayoutClass |
| 2025-10-25 04:55:35 +0200 | <mathstuf> | doLayout would stay in LayoutClass |
| 2025-10-25 04:51:06 +0200 | <geekosaur> | which is why it would interfere with "deriving LayoutClass via" |
| 2025-10-25 04:50:09 +0200 | <geekosaur> | but LayoutClass does, since doLayout is in X |
| 2025-10-25 04:35:06 +0200 | td_ | (~td@i5387091A.versanet.de) |
| 2025-10-25 04:33:12 +0200 | td_ | (~td@i53870931.versanet.de) (Ping timeout: 252 seconds) |
| 2025-10-25 04:33:07 +0200 | <mathstuf> | but maybe compiler errors will guide me htere |
| 2025-10-25 04:32:51 +0200 | <mathstuf> | note that i am not sure that X is involved as PureLayout instances should not need to communicate with X |
| 2025-10-25 03:27:10 +0200 | <mathstuf> | thanks! ill take a look at that approach |
| 2025-10-25 03:25:00 +0200 | <Leary> | To fix the type role, the newtypes over which `X` is written should be inlined into the `X` constructor, then the `deriving` clause for `(Functor, ..., MonadReader XConf)` done `via ReaderT XConf (StateT XState IO)`. |
| 2025-10-25 03:24:43 +0200 | <Leary> | mathstuf: Ordinarily, you should write `newtype Pure l a = MkPure (l a); instance PureLayout l a => LayoutClass (Pure l) a` instead, then following the data declaration for a pure layout L: `deriving LayoutClass via Pure L`. However, I fear the bad type role of `X` will stymie this approach. |