Newest at the top
| 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 |
| 2026-03-09 18:41:01 +0100 | <mauke> | State emulates a single mutable value (by secretly taking an extra argument and returning an extra value, the "updated" value) |
| 2026-03-09 18:40:32 +0100 | <mauke> | Reader is roughly equivalent to function arguments: it takes care of passing a "context value" around |
| 2026-03-09 18:40:23 +0100 | <[exa]> | tccq: the point is that the type `s` there only serves the ordering of operations. Your array is indexed by the `s` for (among other) the purpose that it's hard to get it out of the execution of runST that uses some concrete `s` (that you don't know) |
| 2026-03-09 18:40:13 +0100 | <EvanR> | accessed using get and put |
| 2026-03-09 18:40:07 +0100 | <EvanR> | State only has 1 "mutable" variable |
| 2026-03-09 18:39:56 +0100 | <EvanR> | an ST program can create mutable variables and arrays for use within its scope |
| 2026-03-09 18:39:29 +0100 | <mauke> | or maybe Reader |
| 2026-03-09 18:39:27 +0100 | <tccq> | possibly, not sure I understand the difference |
| 2026-03-09 18:39:27 +0100 | <[exa]> | yes, State or Reader (ok for mutables) over the ST |