Newest at the top
| 2026-03-09 19:08:17 +0100 | <EvanR> | or it always was |
| 2026-03-09 19:08:06 +0100 | <EvanR> | Data.Array is its own package now and not included in base? |
| 2026-03-09 19:04:54 +0100 | wickedjargon | (~user@S0106f89e28d5699a.vc.shawcable.net) wickedjargon |
| 2026-03-09 19:03:23 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-03-09 19:02:40 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2026-03-09 19:00:27 +0100 | <mauke> | State: mutable state (emulated). STM: software transactional memory (for safe state in multi-threaded code). ST: state threads (not related to State or threads) |
| 2026-03-09 19:00:26 +0100 | Square | (~Square@user/square) Square |
| 2026-03-09 18:59:29 +0100 | <mauke> | yeah, love those names |
| 2026-03-09 18:58:34 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 18:56:19 +0100 | <EvanR> | lol TVar. Here I was thinking it would be bad form to bring up STM in a discussion about the confusion between ST and State |
| 2026-03-09 18:55:01 +0100 | <tccq> | s/any/and |
| 2026-03-09 18:54:58 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-09 18:54:55 +0100 | <tccq> | any the vague restriction of it would be cool to have it work with microhs too :) |
| 2026-03-09 18:54:32 +0100 | <tccq> | builtin meaning standard library, not necessarily VoidTM### or whatever goes on internally |
| 2026-03-09 18:54:02 +0100 | <tccq> | I'll take a look through vector |
| 2026-03-09 18:53:57 +0100 | <mauke> | [exa]: does that even make sense? how would you get a multi-threaded ST? |
| 2026-03-09 18:53:42 +0100 | <[exa]> | *a very friendly choice |
| 2026-03-09 18:53:24 +0100 | <[exa]> | tbh I'd really recommend going with a mutable vector, it's a very friendly for first tries |
| 2026-03-09 18:53:05 +0100 | <[exa]> | tccq: builtin primitives might be tough :) |
| 2026-03-09 18:52:39 +0100 | <tccq> | though that line is never quite clear to me in haskell |
| 2026-03-09 18:52:32 +0100 | <tccq> | I was only looking into STArrays because they seem relatively builtin |
| 2026-03-09 18:52:18 +0100 | <[exa]> | ..is there a TVar that can be easily run in `ST s` ? |
| 2026-03-09 18:51:56 +0100 | <mauke> | so if you're dealing with array updates, State is not a good fit |
| 2026-03-09 18:51:36 +0100 | <mauke> | stateful immutable arrays kind of suck because there are no partial updates. you can only rewrite the whole array |
| 2026-03-09 18:50:44 +0100 | <EvanR> | I find vector is a good default when reaching for arrays |
| 2026-03-09 18:50:27 +0100 | <[exa]> | tccq: so then you have a bit of a choice of whether store stateful stuff in actual State, or have it "allocated aside" as a side effect, using e.g. the mutable vectors or STArrays, or e.g. TVar |
| 2026-03-09 18:50:23 +0100 | <tccq> | but practice makes perfect I suppose |
| 2026-03-09 18:50:12 +0100 | <tccq> | the worst part is the the category theory isn't even that bad, it's the applications that are the hardest to parse ime |
| 2026-03-09 18:49:48 +0100 | <tccq> | alright, think I've got it by the right end now, thank you |
| 2026-03-09 18:48:57 +0100 | <[exa]> | tccq: and with that single `s`, you can allocate and deallocate (and read&write) as many vectors/arrays as you like. The only thing they have in common is that their operations depend on each other (to assert order) via something that the `s` becomes. |
| 2026-03-09 18:48:51 +0100 | <EvanR> | so you want to update a mutable array, let me first introduce you to some category theory |
| 2026-03-09 18:47:57 +0100 | <[exa]> | s/state/imperative computations/ |
| 2026-03-09 18:47:47 +0100 | <[exa]> | tccq: but the 's' doesn't hold anything and actually cannot, because it's used internally for the state serialization (see the PrimMonad m constraints) |
| 2026-03-09 18:47:12 +0100 | <[exa]> | tccq: see https://hackage-content.haskell.org/package/vector-0.13.2.0/docs/Data-Vector-Mutable.html -- they are also parametrized by the `s` |
| 2026-03-09 18:46:28 +0100 | <tccq> | nope. I've done stuff w/ StateT and ReaderT (a while ago), but never really touched vectors or arrays in haskell |
| 2026-03-09 18:45:56 +0100 | <[exa]> | tccq: for comparison, did you work with mutable vectors? |
| 2026-03-09 18:44:49 +0100 | <EvanR> | having an STArray in a State doesn't sound right at all |
| 2026-03-09 18:44:31 +0100 | <[exa]> | the above keeps references in Reader, where you only use the references for mutation, and don't modify the state |
| 2026-03-09 18:44:19 +0100 | <EvanR> | no STArray does not |
| 2026-03-09 18:43:54 +0100 | <tccq> | cause the STArray also takes a monad to sequence with right? and that could be my State RegInfo |
| 2026-03-09 18:43:51 +0100 | <[exa]> | yeah if you want the _values_ in State, you don't need `ST` btw |
| 2026-03-09 18:43:17 +0100 | <tccq> | so maybe it doesn't matter? |
| 2026-03-09 18:43:13 +0100 | <tccq> | I think normally I want to update both most of the time |
| 2026-03-09 18:43:07 +0100 | <[exa]> | might be faster as ReaderT if you can store RegInfo behind some kind of ST reference (TVar ?) |
| 2026-03-09 18:43:07 +0100 | <tccq> | yea ok so the other question is which order to layer them in |
| 2026-03-09 18:42:46 +0100 | <[exa]> | tccq: ...so I guess: type MemM s a = StateT (RegInfo, STArray s Int Slot) (St s) a |
| 2026-03-09 18:42:19 +0100 | <mauke> | ST is meant for situations where you want to use imperative features internally, but your public interface is still pure |
| 2026-03-09 18:42:04 +0100 | <EvanR> | just give me a tall State and a do notation to steer her by |
| 2026-03-09 18:41:58 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-03-09 18:41:47 +0100 | <mauke> | ST is an execution environment that provides genuine mutable variables (and arrays), which you can allocate/read/write within the ST context. the catch is that all variables are "local": you must return a pure result |