Newest at the top
2024-05-16 10:16:46 +0200 | <ski> | kuribas` : aiui, no parametric polymorphism, types only depend on values, not types; iirc, in original implementation, they had that, but they didn't include it in the reworked implementation (yet at least), because the theory for it was unclear |
2024-05-16 10:15:27 +0200 | danza | (~francesco@an-19-164-164.service.infuturo.it) (Remote host closed the connection) |
2024-05-16 10:03:14 +0200 | danza | (~francesco@an-19-164-164.service.infuturo.it) |
2024-05-16 10:02:54 +0200 | titibandit | (~user@user/titibandit) |
2024-05-16 10:02:03 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2024-05-16 09:56:54 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
2024-05-16 09:49:30 +0200 | <kuribas`> | https://twelf.org/wiki/equality/ |
2024-05-16 09:46:51 +0200 | <kuribas`> | perhaps offtopic, but I looked at twelf, and I am surprised you need to reinvent equality (refl, cong, ...) for each datatype. |
2024-05-16 09:44:11 +0200 | cfricke | (~cfricke@user/cfricke) |
2024-05-16 09:42:21 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
2024-05-16 09:36:41 +0200 | bilegeek | (~bilegeek@2600:1008:b010:1cfe:3776:17b8:1dc2:3fdf) (Quit: Leaving) |
2024-05-16 09:33:31 +0200 | <tomsmeding> | but true |
2024-05-16 09:33:02 +0200 | <tomsmeding> | with slightly more overhead |
2024-05-16 09:32:35 +0200 | <c_wraith> | and a TVar-based approach lets you write much more obviously-correct code that works under the write-light conditions. |
2024-05-16 09:30:55 +0200 | bo_ | (~bo@198.red-83-56-252.dynamicip.rima-tde.net) (Ping timeout: 256 seconds) |
2024-05-16 09:30:46 +0200 | <tomsmeding> | hence the "write-light" observed above |
2024-05-16 09:30:38 +0200 | <tomsmeding> | of course |
2024-05-16 09:30:31 +0200 | <c_wraith> | in practice, an MVar-based implementation will perform way better with heavy writes. |
2024-05-16 09:29:30 +0200 | <tomsmeding> | and observing that this cleverer implementation does not have stronger preconditions than the MVar-based one |
2024-05-16 09:29:28 +0200 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) |
2024-05-16 09:29:12 +0200 | <tomsmeding> | I'm looking at an idealised implementation in terms of `MVar (Map Key Value)` |
2024-05-16 09:28:37 +0200 | <c_wraith> | You're adding extra semantics. I'm looking at the type. :P |
2024-05-16 09:28:09 +0200 | <tomsmeding> | I that would be a requirement from the interface of getRefForKey anyway, regardless of the implementation |
2024-05-16 09:27:45 +0200 | _bo | (~bo@198.red-83-56-252.dynamicip.rima-tde.net) |
2024-05-16 09:27:07 +0200 | <c_wraith> | Ok, it works on the assumption that the value you want to insert doesn't depend on whether there was already a key there or not (or depends trivially, with some sort of commutative operation) |
2024-05-16 09:23:57 +0200 | frumon | (~Frumon@user/Frumon) |
2024-05-16 09:22:25 +0200 | <tomsmeding> | write-light, then |
2024-05-16 09:22:17 +0200 | <tomsmeding> | :D |
2024-05-16 09:21:41 +0200 | <Axman6> | actually that's not true, since things were only read when a uses used the webservice, which no one ever did =) |
2024-05-16 09:21:39 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
2024-05-16 09:21:05 +0200 | <Axman6> | yeah - which my one use case for this particular design was =) |
2024-05-16 09:20:44 +0200 | <tomsmeding> | also needs a read-heavy workload |
2024-05-16 09:20:31 +0200 | <tomsmeding> | but if that's enough, it's nice |
2024-05-16 09:20:27 +0200 | <tomsmeding> | gets you a limited interface though, to the map |
2024-05-16 09:20:20 +0200 | <tomsmeding> | neat |
2024-05-16 09:20:00 +0200 | <Axman6> | but in the case where the key exists no synchronisation is needed |
2024-05-16 09:19:49 +0200 | <Axman6> | of the threads* |
2024-05-16 09:19:46 +0200 | <tomsmeding> | interesting |
2024-05-16 09:19:21 +0200 | <Axman6> | the code above should handle that fine, since it uses atomicModifyIORef in the update case, only one of the can put their key in |
2024-05-16 09:18:42 +0200 | <tomsmeding> | time-of-check to time-of-use race condition |
2024-05-16 09:18:30 +0200 | <tomsmeding> | oh hm fair |
2024-05-16 09:18:10 +0200 | <c_wraith> | so do I |
2024-05-16 09:18:08 +0200 | <Axman6> | yes |
2024-05-16 09:18:03 +0200 | <tomsmeding> | judging from the getRefForKey code |
2024-05-16 09:17:53 +0200 | <tomsmeding> | c_wraith: I think Axman6 meant `IORef (Map Key (IORef Value))` |
2024-05-16 09:17:43 +0200 | <c_wraith> | It also assumes you never have two threads trying to insert the same key at the same time. |
2024-05-16 09:17:14 +0200 | <Axman6> | this also assumes you never delete keys (use Maybe (IORef Value)) then) |
2024-05-16 09:16:46 +0200 | <Axman6> | oh and the Just case for the first case uses the value returned |
2024-05-16 09:16:28 +0200 | <Axman6> | (missing `old` in the Map.insert but that should work) |
2024-05-16 09:15:37 +0200 | <c_wraith> | I'm not even sure it can be used safely. If you look at the Map and determine you need to insert a new key/value pair, you can't do that from within an atomicModifyIORef |