This is really cool! My question is: how much of the managed time philosophy could be bolted on to a functional reactive programming environment like Elm?
If Elm really does get an analogue of `IO`[0], it could work just like that but with the special replay sauce described in the paper. The type could have operations that read and write from "cells" and "accumulators", and the command interpreter would replay code as usual.
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.
No problem. I included the essay + videos in the title because the paper previously submitted to HN has the same title, so I didn't want to look like I was submitting the same thing again.
"Come on, no feedback at all? Lambda the Ultimate
By Sean McDirmid at Mon, 2014-08-25 10:15"
“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.
How to package it? What should it do? It is one thing to build a research prototype, it is quite another to build something that is useful to others! I would also have to get my bosses to agree, but that is quite secondary.
Believe me, I want to release, but I have to figure out how!
IMHO, releasing it with a couple of working examples would be sufficient to get the ball rolling for most of the hacker types who would be interested in working with the prototype.
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.
Lambda the Ultimate
Programming with Managed Time
To appear in Onward! 2014; abstract:
>>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.
My Motivation:
I'm one of those guys "trying to develop better" safety critical Avionics Software "tested via simulation".
