state_machine1_dynamic_model's model_creator could receive access to input.

[askvortsov1]

I ran into this while working on the snake_game tutorial.

Elements (snakes, apples) should not be spawned on top of each other. Because elements spawn at random positions, the only way to avoid collisions is to read the positions of already spawned elements. This makes it difficult to initialize the game, because default_model is static, and cannot take the positions of those elements as input.

One way to solve this would be for default_model on state machines with input to be a function of 'input -> 'model instead of just 'model, but that doesn't really work statically. However, this could be a useful addition to the model argument of dynamically-valued state helpers in bonsai_extra.ml.

I don't think this would be a clean solution for snake_game, as I mentioned here. It solves initial spawning / respawning, but doesn't give elements an incrementally updated worldview of all other elements, just those spawned before it. I also don't want to use anything from bonsai_extra in the tutorial.

That being said, it would simplify the general case of composing sequentially dependent components with non-deterministic initial state.

[TyOverby]

Not sure I'm fully understanding this, but because he default model has this type [< Computed of ('model option -> 'model) Value.t | Given of 'model Value.t ] and because the "computed" function is inside of a Value.t, you can technically have it depend on anything you like.

[askvortsov1]

That... is absolutely true, and I'm kinda frustrated I didn't think of it. Thanks!