Newest at the top
| 2026-02-05 17:38:54 +0100 | <haskellbridge> | <Morj> Aand git commt |
| 2026-02-05 17:38:46 +0100 | <haskellbridge> | <Morj> Thanks! |
| 2026-02-05 17:38:19 +0100 | <darkling> | Morj: Yes, I see it. |
| 2026-02-05 17:31:54 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-02-05 17:27:04 +0100 | srazkvt | (~sarah@user/srazkvt) srazkvt |
| 2026-02-05 17:26:15 +0100 | wickedjargon | (~user@24.83.46.194) wickedjargon |
| 2026-02-05 17:21:44 +0100 | <haskellbridge> | <Morj> I see a lot of people trying to open it in the browser. Not yet implemented, sorry |
| 2026-02-05 17:19:49 +0100 | <haskellbridge> | <Morj> Testing my impl |
| 2026-02-05 17:19:46 +0100 | <haskellbridge> | <Morj> Those of you who have mastodon (or another activitypub profile): can you search for this profile and tell me if you see the message in it? https://random.test.morj.men/u/morj |
| 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 |