Newest at the top
| 2026-02-05 17:16:14 +0100 | <tomsmeding> | nice |
| 2026-02-05 17:16:09 +0100 | <tomsmeding> | (that observation is not a reason to not go through with this though; the same can be said for fromInteger, and linear-base has a linear fromInteger just fine) |
| 2026-02-05 17:16:09 +0100 | <machinedgod> | tomsmeding: Aye, that's the plan, when coercions are involved, I prefer to be as specific as I can, too |
| 2026-02-05 17:15:19 +0100 | <machinedgod> | (*an int) |
| 2026-02-05 17:15:18 +0100 | <tomsmeding> | it's probably a good idea to define `unsafeToLinear :: (a -> b) -> (a %1-> b); unsafeToLinear = unsafeCoerce` so that you don't end up accidentally unsafeCoercing too much |
| 2026-02-05 17:15:09 +0100 | <machinedgod> | tomsmeding: That's a wise observation! I was only focused on my newtype which holds and int anyway, so I think I'll be good. Thank you for your help, I appreciate it! |
| 2026-02-05 17:14:48 +0100 | <tomsmeding> | I think so |
| 2026-02-05 17:14:31 +0100 | <tomsmeding> | most will, however |
| 2026-02-05 17:14:22 +0100 | <tomsmeding> | not every type that admits a nonlinear toInteger necessarily admits a linear toInteger |
| 2026-02-05 17:14:21 +0100 | <machinedgod> | Would this be considered, how should I call it - acceptable quality production code for current iteration of linear-base and linear types? |
| 2026-02-05 17:13:40 +0100 | <machinedgod> | I considered massaging the value forcefully with Ur, but - I wanted to verify that I am not just blind or missing something (like, toInteger cannot be logically linear) |
| 2026-02-05 17:13:28 +0100 | <tomsmeding> | morally, of course, they are, so it seems it's up to you to declare that (by using unsafeCoerce) |
| 2026-02-05 17:13:08 +0100 | <tomsmeding> | yeah, and those primops are simply not linear |
| 2026-02-05 17:12:58 +0100 | <machinedgod> | tomsmeding: Aye, that's where I looked at, and hoped to find something like int2Float that's linear, but no luck. |
| 2026-02-05 17:12:37 +0100 | <tomsmeding> | machinedgod: eventually, these conversions boil down to calls to functions from GHC.Exts, like int2Float# |
| 2026-02-05 17:11:34 +0100 | <tomsmeding> | even if you go the thorough route, you'll have to do that for the specific conversions anyway |
| 2026-02-05 17:11:17 +0100 | <tomsmeding> | or you can skip all that and unsafeCoerce the specific conversion that you need |
| 2026-02-05 17:11:04 +0100 | <tomsmeding> | if you want to be thorough, you could define your own linear Integral class with a linear toInteger method, define fromIntegral as fromInteger . toInteger as a linear function, and then write RULEs like in base |
| 2026-02-05 17:09:27 +0100 | tomsmeding | doesn't see any fromIntegral in linear-base at all |
| 2026-02-05 17:09:10 +0100 | <machinedgod> | Oh it might be, I wouldn't know in all honesty. I checked the code in linear-base and it seems like fromIntegral is just copied over from 'base' |
| 2026-02-05 17:08:34 +0100 | <tomsmeding> | it seems this is simply an omission in linear-base |
| 2026-02-05 17:08:12 +0100 | <tomsmeding> | wouldn't that be because you're not copying the 1, you're dropping it and then creating a new one? |
| 2026-02-05 17:07:35 +0100 | <machinedgod> | (also curiously, trying to pattern match on a specific value and copying it "conv (MyWrap 1) = AnotherWrap 1" also gets compiler to complain. |
| 2026-02-05 17:06:37 +0100 | <machinedgod> | Good morning everyone. Question re: linear types, again - is it possible to somehow convert between numeric types linearly? I realized 'fromIntegral' is non-linear, while fromInteger is - but even if I wanted to implement manually my specific case (Int -> Float wrapped with a newtype), I cannot seem to find any function that'd let me do the raw conversion linearly. |
| 2026-02-05 16:55:58 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4842:24c6:bd5c:fe37) |
| 2026-02-05 16:55:40 +0100 | RSBach | RMSBach |
| 2026-02-05 16:55:16 +0100 | RSBach | (~RMSBach@24.210.9.182) RMSBach |
| 2026-02-05 16:55:16 +0100 | RMSBach | (~RMSBach@24.210.9.182) (Ping timeout: 265 seconds) |
| 2026-02-05 16:46:02 +0100 | rekahsoft | (~rekahsoft@70.51.99.245) rekahsoft |
| 2026-02-05 16:39:16 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-02-05 16:33:21 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4842:24c6:bd5c:fe37) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-02-05 16:33:15 +0100 | <RMSBach> | I've not tried eglot. |
| 2026-02-05 16:32:09 +0100 | <mesaoptimizer> | if you don't have an idea, that's fine, I'll try lsp myself eventually then |
| 2026-02-05 16:31:54 +0100 | <mesaoptimizer> | RMSBach: how does lsp mode compare to the use of eglot? Because I see someone else recommended the use of eglot to me in response to my question |
| 2026-02-05 16:21:12 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2026-02-05 16:16:22 +0100 | <RMSBach> | Also, lsp mode makes working with Haskell projects much nicer. |
| 2026-02-05 16:16:03 +0100 | <RMSBach> | mesaoptimizer: I strongly recommend projectile. Also consul-projectile. The QoL is amazing. |
| 2026-02-05 16:14:13 +0100 | trickard_ | trickard |
| 2026-02-05 16:11:57 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2026-02-05 16:09:45 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-02-05 16:07:48 +0100 | <mesaoptimizer> | thanks for the heads up |
| 2026-02-05 16:07:39 +0100 | <mesaoptimizer> | RMSBach: I'm using vanilla emacs, so no projectile. I might consider trying projectile if that's necessary. |
| 2026-02-05 15:59:18 +0100 | fp | (~Thunderbi@wireless-86-50-141-35.open.aalto.fi) (Ping timeout: 244 seconds) |
| 2026-02-05 15:58:43 +0100 | AlexZenon_2 | AlexZenon |
| 2026-02-05 15:53:55 +0100 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
| 2026-02-05 15:53:42 +0100 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2026-02-05 15:44:08 +0100 | <gentauro> | ahhh, got it |
| 2026-02-05 15:43:30 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-02-05 15:23:45 +0100 | <RMSBach> | mesaoptimizer: Are you using projectile? I haven't used haskell-ts-mode, but regular haskell-mode works with cabal projects when projectile is aware of the project root for me. |
| 2026-02-05 15:23:09 +0100 | <dutchie> | for a mode foo-mode, foo-ts-mode is the same mode but based on tree-sitter |