I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.
However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.
For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.
This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.
Long and boring explanation with way too much detail:
Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.
For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.
So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s get()/put() functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.
I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.
However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.
For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.
This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.
Long and boring explanation with way too much detail:
Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.
For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement
Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s
get()/put()functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.