Newest at the top
| 2024-09-21 05:12:00 +0200 | <Inst> | i'm blathering at all times, go to bed, geekosaur, it's friday :) |
| 2024-09-21 05:09:51 +0200 | <geekosaur> | that said, I'm operating on 3h of sleep and it's getting late here so I may be blathering at this point 😞 |
| 2024-09-21 05:09:11 +0200 | <geekosaur> | which is a subset of monads |
| 2024-09-21 05:09:04 +0200 | <geekosaur> | mmm, I'd say that's more about "free monad"? |
| 2024-09-21 05:09:02 +0200 | <Inst> | hence the old canard about "computation in a context" |
| 2024-09-21 05:08:24 +0200 | <Inst> | i know, but what I mean is that using monadic / applicative polymorphism to write actions such that it's the type that forces the actual codepath |
| 2024-09-21 05:07:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 05:07:45 +0200 | <geekosaur> | what if the constraint is Functor? |
| 2024-09-21 05:07:14 +0200 | <geekosaur> | not all constraints are monads |
| 2024-09-21 05:06:56 +0200 | <Inst> | as in, Constraint m => m a type actions |
| 2024-09-21 05:06:51 +0200 | <geekosaur> | actually, no, you can't. that;s not what unsafePerformIO is. unsafePerformIO is "hey compiler, I promise you that this is actually pure ". at which point it is evaluated on demand instead of forcing evaluation |
| 2024-09-21 05:06:33 +0200 | <Inst> | also, by the way, do I finally get monads now that I'm thinking in terms of monadic typeclasses? |
| 2024-09-21 05:06:11 +0200 | <Inst> | probably, sigh |
| 2024-09-21 05:05:17 +0200 | <geekosaur> | if you get a performance improvement from an IORef, I would first suspect you had thunk buildup that the IORef was causing to be forced |
| 2024-09-21 05:04:44 +0200 | <Inst> | since you can now run IO anywhere |
| 2024-09-21 05:04:40 +0200 | <Inst> | ehhh, unsafePerformIO sort of breaks the entire haskell programming model, doesn't it? |
| 2024-09-21 05:03:47 +0200 | <geekosaur> | con template Debug.Trace, which uses unsafePerformIO under the hood |
| 2024-09-21 05:03:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 05:02:32 +0200 | <geekosaur> | at least, not any more than multithreaded access to the same resource will |
| 2024-09-21 05:02:06 +0200 | <geekosaur> | unsafePerformIO will reveal to you when things are evaluated (on demand aka "lazily") but won't in general cause evaluation order issues otherwise |
| 2024-09-21 05:00:00 +0200 | <geekosaur> | not really. if you want that level of unsafety, you want accursedUnutterablePerformIO (that is, inlining runRW#) |
| 2024-09-21 04:59:36 +0200 | <Inst> | weird because it was boxed, and I was using monomorphic IORef and got a performance improvement |
| 2024-09-21 04:59:08 +0200 | <geekosaur> | if they're unboxed, you need to rethink your design |
| 2024-09-21 04:58:56 +0200 | <geekosaur> | and re "large parameters", if they are boxed, you're passing a pointer |
| 2024-09-21 04:58:44 +0200 | <Inst> | i thought the main reason unsafePerformIO was considered unsafe was because Haskell gives very weak guarantees on evaluation order of pure functions? |
| 2024-09-21 04:58:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:58:09 +0200 | <geekosaur> | it's the unsafeCoerce part, however you got it, that is problematic |
| 2024-09-21 04:57:56 +0200 | <Inst> | iirc i used unsafePerformIO as an optimization pass |
| 2024-09-21 04:57:34 +0200 | <geekosaur> | unsafePerformIO only matters insofar as it can give you a polymorphic IORef, which implicitly unsafeCoerces anything taken out of it |
| 2024-09-21 04:56:51 +0200 | <Inst> | i mean without coercion in unsafePerformIO, i.e, a way to avoid passing large parameters around |
| 2024-09-21 04:56:50 +0200 | <geekosaur> | if (a) all types are boxed (b) all types have at least as many constructors as the starting type does, you can generally get away with it |
| 2024-09-21 04:55:50 +0200 | <lambdabot> | monochrom says: isTrue = (unsafeCoerce :: Either a b -> Bool) . (unsafeCoerce :: Maybe c -> Either a b) . (unsafeCoerce :: Bool -> Maybe c) |
| 2024-09-21 04:55:50 +0200 | <geekosaur> | @quote monochrom unsafeCoerce.*Either |
| 2024-09-21 04:55:24 +0200 | <geekosaur> | because reading it will follow what it thinks is a pointer |
| 2024-09-21 04:54:54 +0200 | <geekosaur> | even read-only is unsafe if you coerced an unboxed value into a boxed one |
| 2024-09-21 04:54:26 +0200 | <Inst> | i'm more trying to figure out when it's safe to use unsafeCoerce |
| 2024-09-21 04:54:05 +0200 | <Inst> | iirc it should be safe to use unsafePerformIO for read-only operations, right? as long as you ensure the write is done beforehand |
| 2024-09-21 04:53:33 +0200 | <geekosaur> | that's more or less what you're inviting with unsafeCoerce in any form |
| 2024-09-21 04:53:12 +0200 | <geekosaur> | that's not too surprising, it very likely depends on the internal GMP representation |
| 2024-09-21 04:49:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 04:47:36 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) |
| 2024-09-21 04:47:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 04:46:01 +0200 | <Inst> | okay, Integers (mostly) seem to produce the desired crash on unsafeCoerce to System.IO.Handle (using unsafePerformIO) |
| 2024-09-21 04:45:20 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 04:45:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 04:44:43 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-21 04:44:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-21 04:43:50 +0200 | <Inst> | but other integers don't produce the same effects |
| 2024-09-21 04:43:43 +0200 | <Inst> | 234288 unsafeCoerce-ed to System.IO.Handle gets you the crash I'm looking for |
| 2024-09-21 04:43:13 +0200 | <Inst> | this is weird |