Elm is already considering things like `Signal (Command a) -> Signal a` to blend imperative programming with FRP; in this case, you'd have functions like `Signal (Glitch a) -> Signal a`
However, I was disappointed because I couldn't use signal abstractions in the implementation of this system; instead I invented something that was the beginning of the work presented here.
Once you have effects (implicit or explicit), something like Glitch will work for that system. However, it is very important to make sure effects are de-serialized syntactically (they basically need to be wrapped up in commutative monads), otherwise replay isn't well defined and you'd need to go with more of a self-adjusting computation approach that preserves partial orders.
One optimization we perform now is to have a slow-path replay that does book keeping: logging updates, tracing dependencies, and performing dynamic type checks. But during this slow-path, a fast-path replay is generated that just re-executes the code while keeping book keeping constant (so no book keeping overhead), which is applicable if values just change slightly (e.g. in a physics simulation). See the paper for more details.
The previous HN discussion on this topic is here: https://news.ycombinator.com/item?id=7702796
“If you love something, set it free. If it comes back, it was, and always will be yours. If it never returns, it was never yours to begin with.”
― Sherrilyn Kenyon, Unleash the Night
Excellent expansion of the material Sean, especially the reference to the influence of your thesis on SuperGlue and self adjusting computation!
The time has now come to set your prototype free, as you promised to. It is one thing to evaluate videos and papers, and quite another to work with a prototype and submit changes/proposals/code.
Managed Time threatens to be stillborn by continuing delay in the release of your prototype. Your registration to this work is cemented, as is Chris Hancock's, whom you continually reference throughout your work.
Set it free.
Believe me, I want to release, but I have to figure out how!
As the code is C# based, Visual Studio Express would provide the perfect vehicle for experimentation, requiring little in the way of formal packaging.
Release it under Github and let the organic evolutionary forking work.
I would expect there to be a flurry of prototyping activity, which should be culled into a stable release once this phase settles.
I would recommend to get the ball rolling now before the conference in October so that it can be released then.
>>Live coding vs. live programming
But if instead you were trying to develop better nuclear plant software tested via simulation, a live programming environment might make more sense.
I'm one of those guys "trying to develop better" safety critical Avionics Software "tested via simulation".
I'll see what I can do; it would be nice to have this project up at least on Github.