Logs on 2025-10-25 (liberachat/#xmonad)
| 01:24:23 | → | mathstuf joins (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) |
| 01:24:43 | <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. |
| 01:25:00 | <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)`. |
| 01:27:10 | <mathstuf> | thanks! ill take a look at that approach |
| 02:32:51 | <mathstuf> | note that i am not sure that X is involved as PureLayout instances should not need to communicate with X |
| 02:33:07 | <mathstuf> | but maybe compiler errors will guide me htere |
| 02:33:12 | × | td_ quits (~td@i53870931.versanet.de) (Ping timeout: 252 seconds) |
| 02:35:06 | → | td_ joins (~td@i5387091A.versanet.de) |
| 02:50:09 | <geekosaur> | but LayoutClass does, since doLayout is in X |
| 02:51:06 | <geekosaur> | which is why it would interfere with "deriving LayoutClass via" |
| 02:55:35 | <mathstuf> | doLayout would stay in LayoutClass |
| 02:55:50 | <geekosaur> | right, but you're deriving LayoutClass |
| 02:56:09 | <mathstuf> | the default `doLayout` wouldnt suffice? |
| 02:56:34 | <geekosaur> | that's not the question. the question is whether the type roles on X would pass muster with deriving-via |
| 02:58:03 | <geekosaur> | ghc won't allow automatic deriving if a type variable involved has a `nominal` type role |
| 02:59:15 | <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 |
| 03:15:15 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 03:28:02 | <mathstuf> | oh, not sure i was looking at `deriving` at all |
| 03:28:24 | <mathstuf> | is `instance (PureLayout l a) => LayoutClass l a where …` not suitable? |
| 03:29:16 | <Leary> | mathstuf: Check the logs in the topic for a line you missed. |
| 03:30:20 | <mathstuf> | ah |
| 03:31:20 | <mathstuf> | too much Rust :) |
| 03:44:51 | × | redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 03:46:28 | <geekosaur> | it does take some getting used to |
| 03:46:30 | → | redgloboli joins (~redglobol@user/redgloboli) |
| 03:46:48 | <geekosaur> | also, different FP languages have different solutions to the problem type roles solve here |
| 03:47:57 | <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) |
| 03:49:18 | <mathstuf> | oh i did lots more haskell years ago (i contributed X.H.DynamicBars and X.H.ToggleHooks) |
| 03:49:27 | <mathstuf> | though i admit i was not mucking with typeclasses that much there |
| 03:49:48 | <geekosaur> | and I don't think type roles existed back then |
| 03:50:23 | <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" |
| 03:50:46 | <Leary> | No, even if you tried to declare a less restrictive role, GHC would reject it. |
| 03:52:04 | <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. |
| 03:52:57 | <Leary> | If GHC would look under the newtypes itself, it could re-infer `representable` after `f` is specialised to `IO`, alas ... |
| 03:57:28 | <Leary> | Err, `representational`*. |
| 04:01:13 | × | td_ quits (~td@i5387091A.versanet.de) (Ping timeout: 264 seconds) |
| 04:02:40 | → | td_ joins (~td@i53870908.versanet.de) |
| 05:01:53 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 05:27:17 | × | mathstuf quits (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 256 seconds) |
| 06:18:11 | × | ft quits (~ft@p4fc2aaeb.dip0.t-ipconnect.de) (Quit: leaving) |
| 06:24:18 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 11:10:23 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 11:23:39 | × | Leary quits (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 11:34:07 | → | Leary joins (~Leary@user/Leary/x-0910699) |
| 11:54:56 | → | ft joins (~ft@mue-88-130-106-235.dsl.tropolys.de) |
| 11:59:25 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 12:29:32 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 14:46:23 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 14:51:13 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 15:27:22 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 16:16:44 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 16:28:00 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 21:00:21 | × | _qw quits (~eqw@user/eqw) (Ping timeout: 252 seconds) |
| 21:25:26 | → | _qw joins (~eqw@user/eqw) |
| 23:13:46 | × | td_ quits (~td@i53870908.versanet.de) (Ping timeout: 256 seconds) |
| 23:15:41 | → | td_ joins (~td@i5387090B.versanet.de) |
All times are in UTC on 2025-10-25.