Newest at the top
| 2024-11-12 20:56:26 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-11-12 20:56:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 20:55:54 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 20:55:30 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 20:55:05 +0100 | <tomsmeding> | bwe: indeed, you put the haddocks on the function where it's defined, and with the not-home haddock option you ensure that the documentation gets generated in the right place |
| 2024-11-12 20:54:59 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 20:52:30 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-12 20:51:37 +0100 | sprotte24 | (~sprotte24@p200300d16f2cc30041d9df5443f92151.dip0.t-ipconnect.de) |
| 2024-11-12 20:46:51 +0100 | <bailsman> | This kind of thing should start and end with profiling probably |
| 2024-11-12 20:46:45 +0100 | <bailsman> | Does code like this `for_ [0 .. MV.length v - 1)] (MV.modify v f)` have any performance gotchas? I somehow got it into my head that I want to mutate data in place for performance reasons, but I'm slowly starting to have more and more doubts. |
| 2024-11-12 20:42:26 +0100 | <int-e> | oh, one more: unsuccessfullyDupablePerformIO :: IO a -> a; unsuccessfullyDupablePerformIO = error (error "I'm afraid I cannot do that, Dave") |
| 2024-11-12 20:39:45 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-12 20:39:26 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-12 20:39:22 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-11-12 20:37:25 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) (Ping timeout: 265 seconds) |
| 2024-11-12 20:36:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 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 |