Hello all, This is a conversation I had with Jay earlier earlier this month. I asked if I could forward it and Jay said that's fine, so I'm doing so in case it's of use to anyone else.
For those not in the know, Jay's DOS package stands for "Delimited-continuation-based Operating-system Simulator" and the docs can be found here: https://docs.racket-lang.org/dos/ I presume some inspiration has been taken from "Delimited Continuations in Operating Systems" though I have not confirmed with Jay: http://okmij.org/ftp/continuations/ZFS/context-OS.pdf Anyway, for the most part what it's currently used for is defining a functional way to do game behavior using prompts in one of several layers... I was trying to figure out how I might do some more complex game behavior and so hence this email exchange. I'm still processing it, admittedly ;) Anyway, maybe you'll find it interesting or useful! Jay McCarthy writes: > Your understanding at last isn't correct :) > > The environment after one round of `win-boot` (and the state after one > round of `os2-boot` or `dos-boot`) is always the result of the monoid > operation. In the case of `win`, that means that the various > environment updates that each process writes are merged. If there is a > key `k1` in the old environment that is not written in the current > round, then it is not included at all in the next one. > > ``` > #lang racket/base > (require dos/win) > > (module+ test > (define w > (win-boot > (win-env-replace > (win-mbr > (λ (old-env) > (win-write 'new-key > (add1 (env-read1 old-env 'old-key 0))))) > 'old-key (list 41)))) > > (require chk) > (chk (win-env-read w 'old-key) '() > (win-env-read w 'new-key) '(42))) > ``` > > As far as your conversation... > > First, the `win` environment is strictly for global things. If you > want local things, then you can use the closed-over state of the > continuation for that. For example, in the win test, the > `mouse-tracking-ball` function is using the `r` parameter to have its > own internal state. It calls itself with `env-write`, which returns > the environment after synchronization with all the other entities > (i.e. at the next frame.) This means that the `r` part and the > control-state of what the ball is doing is embedded in the captured > continuation. > > So, in your example, there's two ways I look at it. > > In one case, the player state is global, so there are two effects > posted a (was-damaged amount) and (was-upgraded amount) and the monoid > operation has to determine what the effect is. You could reproduce the > race condition by saying that that the monoid plus is (lambda (x y) x) > or (lambda (x y) y) and just ignore one of them. (The idea, btw, of > the the win environment being a set is that most consumers will > `foldr` the result and have a monoid per key.) Or, you could actually > inspect the values and have a rule like "teleport always goes first, > otherwise sum effects." Etc. > > In the other case, the player state is local and the collision > information is global, so the player update process should consult > that information and you need to decide how to deal with multiple > collisions at the same time inside that function. > > Basically, the first case is where the objects (missiles) read the > player state and try to update it but the changes must be merged. In > the second case, the player reads about the missiles and decides how > it will update its state. > > The dos model allows all behaviors that race conditions/etc provide, > but you have to be a little more particular about what you want. > > On Sun, Nov 11, 2018 at 11:58 AM Christopher Lemmer Webber > <cweb...@dustycloud.org> wrote: >> >> Aha! It's clear to me at last. >> >> If any process writes to the registry on that turn, they participate >> in overwriting the value... if multiple processes write, multiple values >> are written, but if it's just one it's just a list of one value. If >> nobody writes to that key, it doesn't change that turn! >> >> Christopher Lemmer Webber writes: >> >> > Hello Jay, >> > >> > I've read through all of the DOS code and docs now. It's beautiful >> > stuff! I love that the main kernel is 50 readable lines and the layers >> > on top of it aren't much larger. >> > >> > The only thing I think I don't understand at this point is the code in >> > the big-bang usage of the Win example. From my reading, on each "turn" >> > a process takes for both mouse-tracking-ball and decaying-ball it's >> > performing win-write to gfx, adding a new thing to render. >> > >> > The problem is, between "runs" of the big-bang, how does gfx get reset >> > in any way so that the old values in gfx just don't sit around? I don't >> > see anything that looks like it should reset gfx, and yet every round >> > the "canvas" does seem to be like it's running fresh. >> > >> > Unless, I guess, if each process is allowed to write a single value to >> > the "set" of values in the environment, and when that process dies, its >> > values in the environment die somehow as well... >> > >> > But it didn't look to me like that was happening when I read the win >> > code. I must be missing something. Any insights? >> > >> > - Chris >> > >> > PS: you may find this conversation interesting: >> > https://octodon.social/@cwebber/101053180888631607 >> -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
