| 2025-02-02 00:01:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 00:05:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-02-02 00:12:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 00:13:39 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 276 seconds) |
| 2025-02-02 00:17:33 +0100 | harveypwca | (~harveypwc@2601:246:d080:f6e0:34b5:bbb2:c6c:1ef6) (Quit: Leaving) |
| 2025-02-02 00:19:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 00:22:10 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-02-02 00:22:55 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-02-02 00:24:00 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 246 seconds) |
| 2025-02-02 00:24:00 +0100 | monochrm | monochrom |
| 2025-02-02 00:27:02 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 00:30:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 00:31:38 +0100 | dispater | (~dispater@mail.brprice.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-02-02 00:31:51 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 276 seconds) |
| 2025-02-02 00:32:23 +0100 | dispater | (~dispater@mail.brprice.uk) |
| 2025-02-02 00:35:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-02-02 00:41:03 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2025-02-02 00:41:18 +0100 | <sim590> | geekosaur: it doesn't seem like it's possible to block access to a TVar while doing an IO action. All I can do is STM action and STM is not MonadIO. Am I correct? |
| 2025-02-02 00:42:05 +0100 | <geekosaur> | correct and deliberately so. how do you retry an IO action? |
| 2025-02-02 00:48:33 +0100 | yushyin | (CinQEuz8mT@mail.karif.server-speed.net) (Ping timeout: 248 seconds) |
| 2025-02-02 00:48:34 +0100 | s4msung | (wBrkYH9KHh@user/s4msung) (Ping timeout: 248 seconds) |
| 2025-02-02 00:50:06 +0100 | <sim590> | geekosaur: Yeah, I understand. But, then, if I'm not mistaken, that is something I could be doing with MVars though? |
| 2025-02-02 00:50:52 +0100 | s4msung | (DQyKc40dMf@user/s4msung) s4msung |
| 2025-02-02 00:51:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 00:51:07 +0100 | tabemann | (~tabemann@8.9.45.41) tabemann |
| 2025-02-02 00:52:28 +0100 | <EvanR> | anything you can do with an MVar you can do with a TVar (Maybe a) |
| 2025-02-02 00:52:34 +0100 | <geekosaur> | oh yes, it'll happily let you make a mess |
| 2025-02-02 00:52:35 +0100 | <Leary> | sim590: You can't ever block access to a `TVar`. You instead hide inconsistent states within atomic transactions, so you don't need to. |
| 2025-02-02 00:52:49 +0100 | alp | (~alp@2001:861:8ca0:4940:e7c0:2b3f:562a:38cb) (Ping timeout: 248 seconds) |
| 2025-02-02 00:53:01 +0100 | <geekosaur> | but if that's really what you want to do, just use an IORef |
| 2025-02-02 00:53:46 +0100 | <EvanR> | it's just that you generally can't do IO in the middle of a transaction |
| 2025-02-02 00:54:20 +0100 | <EvanR> | but there's a "trust me" trap door for that in which all bets are off if your I/O matters |
| 2025-02-02 00:55:24 +0100 | <sim590> | OK. I'll try to inflate my brain so I can do what I need only using TVars. Up to now, I think I can do it. |
| 2025-02-02 00:55:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 00:55:41 +0100 | <geekosaur> | that, or you have a very wrong model of concurrent access which you will need to figure out before this will work with either |
| 2025-02-02 01:00:31 +0100 | <sim590> | Yeah. Well. I can't say for now. I guess, I'll see! :D |
| 2025-02-02 01:01:37 +0100 | yushyin | (qjh7DQNxXf@mail.karif.server-speed.net) yushyin |
| 2025-02-02 01:02:40 +0100 | <Leary> | sim590: For pretend-interleaved STM and IO I like to use `newtype Atom a = Atom (WriterT (IO ()) STM a); io :: IO () -> Atom (); stm :: STM a -> Atom a; atom :: Atom a -> IO a`---might at least help you structure things. |
| 2025-02-02 01:06:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:08:09 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) |
| 2025-02-02 01:12:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 01:15:06 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 01:17:43 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 265 seconds) |
| 2025-02-02 01:19:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-02 01:23:30 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-02-02 01:23:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:24:19 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Client Quit) |
| 2025-02-02 01:24:39 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-02-02 01:28:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 01:29:17 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Client Quit) |
| 2025-02-02 01:31:14 +0100 | <monochrom> | I suspect that "block access" means something that has nothing to do with "block" or "access" because supposedly everyone already knows that if you don't want a certain function to use a certain argument then just don't have that argument in the first place, so why the question. |
| 2025-02-02 01:32:16 +0100 | <monochrom> | Like even in C if I don't want sin() to mess with my array then just don't give it [the address of] my array, done. |
| 2025-02-02 01:39:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:43:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 01:45:03 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-02 01:48:08 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) (Remote host closed the connection) |
| 2025-02-02 01:52:40 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-02-02 01:53:11 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2025-02-02 01:53:15 +0100 | monochrm | monochrom |
| 2025-02-02 01:54:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:58:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-02-02 02:00:29 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-02-02 02:01:12 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-02 02:03:12 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 02:06:16 +0100 | olivial | (~benjaminl@user/benjaminl) (Remote host closed the connection) |
| 2025-02-02 02:07:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-02 02:07:46 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-02-02 02:09:33 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f12b860008857e92372.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-02-02 02:09:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:12:08 +0100 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb2+b2 - https://znc.in) |
| 2025-02-02 02:15:46 +0100 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2025-02-02 02:16:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 02:17:09 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-02-02 02:18:19 +0100 | otto_s | (~user@p5b0448ee.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-02-02 02:19:55 +0100 | otto_s | (~user@p5b0441a3.dip0.t-ipconnect.de) |
| 2025-02-02 02:20:42 +0100 | olivial_ | (~benjaminl@2601:1c0:847f:9c70:223:24ff:fe66:4370) |
| 2025-02-02 02:22:24 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 260 seconds) |
| 2025-02-02 02:27:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:32:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-02 02:33:18 +0100 | <Leary> | Mmmm. Getting to write meaningful rewrite RULES is a rare and special joy, isn't it? Even better, to give a typeclass laws and declare /these laws are **enforced** by rewrite @RULES@/ in the haddocks! |
| 2025-02-02 02:33:34 +0100 | <Leary> | Break the law and GHC will punish you. >:) |
| 2025-02-02 02:33:41 +0100 | <Leary> | `Functor` should have gotten this treatment. |
| 2025-02-02 02:33:54 +0100 | sprotte24 | (~sprotte24@p200300d16f174a005425e35c82ecf678.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-02-02 02:36:21 +0100 | <int-e> | hmm but assuming properties doesn't enforce them, you're just shifting blame away from the compiler ;-) |
| 2025-02-02 02:37:25 +0100 | <int-e> | You're introducing undefined behavior. |
| 2025-02-02 02:39:41 +0100 | <int-e> | I'm not really opposed btw, except that it's hard to do this kind of thing after the fact. |
| 2025-02-02 02:39:46 +0100 | <Leary> | I'm placing the blame solidly on the unlawful instances, and claiming only /they/ introduce undefined behaviour. :) |
| 2025-02-02 02:40:27 +0100 | <Leary> | But yeah, sadly too late for `Functor`. |
| 2025-02-02 02:40:45 +0100 | <int-e> | Yeah C also blames the programmers for introducing undefined behavior into their code. |
| 2025-02-02 02:42:00 +0100 | <int-e> | I still remember when GCC broke Linux with agressive exploitation of signed overflows. |
| 2025-02-02 02:42:14 +0100 | <monochrom> | :) |