bryanedds
commented
2 months ago perhaps as an intermediate step, we can investigate what parts of the current MMCC runtime might benefit from bespoke F# compiler extensions. perhaps we can get 80% of the benefit with 20% of the work.
tho again, this all presume that the current optimized MMCC runtime isn't sufficient - which we have yet to be demonstrated in our current testing scenarios. still, our clients may well have use cases that go beyond what we've tested for.
ok, so something i'm thinking about...
i think the only potentially viable alternative for implementing MMCC to the way that Nu does it - (where Nu uses runtime descriptor diffing) - would be to do something like Svelte does and compile change propagation paths. the advantage there would be that less runtime allocation would be required and there would be less overhead. the downside there is that of having an additional compilation step, plus defining a syntax and semantics ourselves. usually this requires building an entire programming language from scratch, type checkers, debuggers, tooling and all.
however, maybe that's a reasonably workable solution if we can host the Svelte-like semantics in F# directly. by hacking up F#, we might not need to build all of this other stuff from scratch.
that leaves open two questions - 1) is it really needed when our current implementation of MMCC seems adequate as-is? 2) will F# be hackable enough to actually host this extended semantics in a way that is clean and practicable?
the reason i bring this up in here is -
if our clients aren't happy enough with our existing optimized runtime implementation of MMCC, maybe we can follow up with a proposal to implement Svelte-like semantics for MMCC in F# directly. we should be able to use Svelte's implementation and algorithms as a guide to potentially implementing such a thing in F#. this is the only other potentially viable path I see to implementing MMCC if our current solution pattern is considered to have too much overhead.
additionally, it looks like Svelte's semantics even allows this type of efficient change propagation with imperative mutation - thus freeing developers from the obligation to code in a functional style just to get the desired declarativity. finally, presuming the answer to 1) and 2) are both yes, another open question is if Svelte's MVU pattern is generally applicable enough to cover the same use cases that Nu's MVU pattern is. I suspect that Svelte's change propagation semantics are more limited than what they might first appear.
going down this route would be a potentially large pivot for us, but if it is the only way we can deliver our value proposition, then we should consider it. that said, we may still want to keep the functional semantics since that's what gives us the ability to undo / redo gameplay. so i think there would be a limit to how large the pivot would be in practice.