Newest at the top
| 2024-11-12 20:35:02 +0100 | <EvanR> | and be willing to find the counterexamples which prove yourself wrong |
| 2024-11-12 20:34:27 +0100 | <EvanR> | and then proving what you did worked |
| 2024-11-12 20:33:58 +0100 | <EvanR> | but this mindset requires respecting abstractions in play, once the game starts |
| 2024-11-12 20:33:20 +0100 | <EvanR> | instead of breaking the system, maybe study ways of constructing a new system which is safe and does the optimizations |
| 2024-11-12 20:32:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 20:31:23 +0100 | <int-e> | . o O ( unsuccessfullyPerformIO :: IO a -> a; unsuccessfullyPerformIO = error "I'm afraid I cannot do that, Dave" ) |
| 2024-11-12 20:30:31 +0100 | <Rembane> | int-e: ...while studying the dark arts? |
| 2024-11-12 20:29:32 +0100 | <int-e> | avoid success at all cost? |
| 2024-11-12 20:29:13 +0100 | <EvanR> | it's just not that kind of language |
| 2024-11-12 20:29:04 +0100 | <EvanR> | I've never really had any success violating haskell's semantics |
| 2024-11-12 20:28:42 +0100 | <EvanR> | exactly |
| 2024-11-12 20:28:27 +0100 | <bailsman> | I don't though. |
| 2024-11-12 20:28:04 +0100 | <EvanR> | but someone noted the existence of unsafeThaw which is your trap door into "I know what I'm doing" |
| 2024-11-12 20:27:09 +0100 | <EvanR> | since it is |
| 2024-11-12 20:27:06 +0100 | <EvanR> | it certainly would still be treated like a mutable array |
| 2024-11-12 20:26:17 +0100 | <bailsman> | I would like most of the code to be regular normal pure code |
| 2024-11-12 20:25:57 +0100 | <bailsman> | I wonder if that still causes the compiler to think the data is "actually mutable" and disables a ton of optimizations |
| 2024-11-12 20:25:54 +0100 | <EvanR> | which is a different subject from increasing the performance of working with an array |
| 2024-11-12 20:25:33 +0100 | <EvanR> | what I just suggested as in response to "compiler stops me from writing to it when I don't want to, because... I might accidentally write code to write to it for some reason" |
| 2024-11-12 20:24:48 +0100 | <bailsman> | If that's easy to do, why isn't it how freeze/thaw already works? |
| 2024-11-12 20:24:37 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-11-12 20:24:08 +0100 | <bailsman> | Interesting. Can you make an example? |
| 2024-11-12 20:23:38 +0100 | <EvanR> | you can wrap your ST array in a newtype which won't allow you to write through it |
| 2024-11-12 20:23:07 +0100 | <bailsman> | but I would like the compiler to ensure that I'm not writing to the data where I don't want to be writing to it. |
| 2024-11-12 20:22:48 +0100 | <bailsman> | I'm totally happy to annotate all the rest of the code however the type system needs me |
| 2024-11-12 20:22:28 +0100 | <EvanR> | you can access the array however you want, and the whole operation will be considered pure in the end |
| 2024-11-12 20:22:16 +0100 | <EvanR> | the whole thing being an ST action sounds like what ST is meant for |
| 2024-11-12 20:21:50 +0100 | <bailsman> | So what I should do instead is design it to pass mutable references around and just not write to them where I'm not supposed to? |
| 2024-11-12 20:21:20 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-11-12 20:21:14 +0100 | <EvanR> | but I expect the total cost to defeat the purpose of all this optimization talk |
| 2024-11-12 20:20:52 +0100 | <EvanR> | since it's temporary maybe it won't be so bad |
| 2024-11-12 20:20:29 +0100 | <EvanR> | see if it fits into the gc first generation |
| 2024-11-12 20:20:20 +0100 | <bailsman> | I mean that was pretty much my worry, and why I was looking for whether "immutable references to mutable data" are a thing |
| 2024-11-12 20:19:58 +0100 | <EvanR> | fine then |
| 2024-11-12 20:19:47 +0100 | <bailsman> | it's just memcopy can't you do that at terrabytes per second or something |
| 2024-11-12 20:19:45 +0100 | <EvanR> | especially if you do it once per loop and discard it all |
| 2024-11-12 20:19:28 +0100 | <EvanR> | not cheap |
| 2024-11-12 20:19:21 +0100 | <EvanR> | copying 100k elements? |
| 2024-11-12 20:19:18 +0100 | <bailsman> | geekosaur: yes |
| 2024-11-12 20:19:07 +0100 | <bailsman> | Is it? I wonder if it's going to be the fastest part, so fast that I'll be embarrased to have enough wondered about the issue. |
| 2024-11-12 20:19:06 +0100 | <EvanR> | gc |
| 2024-11-12 20:19:05 +0100 | <EvanR> | accessing a mutable array involves more book keeping than an immutable array, in the gd |
| 2024-11-12 20:18:59 +0100 | <geekosaur> | am I understanding correctly that updateSingleElement only reads, and ultimately produces a value that the impure code will actually use to mutate? |
| 2024-11-12 20:18:20 +0100 | <EvanR> | well, the frozenCopy is going to be expensive, and there's no real way around it |
| 2024-11-12 20:17:41 +0100 | <bailsman> | updateSingleElement and everything it calls |
| 2024-11-12 20:17:33 +0100 | <EvanR> | what pure part |
| 2024-11-12 20:17:28 +0100 | <bailsman> | No, because the "pure part" of the code should not write anywhere |
| 2024-11-12 20:17:18 +0100 | <EvanR> | mutable array it is |
| 2024-11-12 20:17:08 +0100 | <bailsman> | Every iteration of the loop, every element is going to get updated again. I want to keep modifying them over and over (in place) |
| 2024-11-12 20:16:50 +0100 | <EvanR> | but not the other way around |