Hello everyone!
After a year of work, I am finally presenting the result of my Master's thesis!๐๐
I developed and studied a live programming environment that can provide meaningful information about the runtime behaviour of a program in practically every edit state, while retaining the intuitive and flexible interface of text editors.
To provide meaningful runtime behaviour information in edit states containing incomplete programs with syntax, type or logic errors, the programming environment has to isolate errors and continue functioning for unaffected parts of the program.
I call this error tolerance.
Tolerance of syntax errors is realized with an integrated structure editor that incorporates a notion of incompleteness I call construction sites.
Essentially, these are abstract syntax tree nodes that can contain arbitrary characters and other AST nodes.
Evaluation of the program continues "around errors" instead of aborting with an exception or resulting in some "undefined" value.
Because the results this produces are much more informative than an exception or undefined value, they can help the programmer find the sources of issues and resolve them much better.
Because the programming environment is often evaluating unfinished code, evaluation diverges much more often.
The programming environment handles this smoothly by only evaluating parts of the runtime information that are displayed and providing a mode of evaluation where the number of reductions is limited by a configurable number.
This enables partial results in cases of non-termination.
You can try out the editor for yourself at https://cdfa.github.io/frugel/ ๐ or by downloading a much better performing native executable from GitHub.
I also created a demo video ๐บ (WebArchive version (still uploading), Google Drive version) and attached a draft version of the thesis.
I hope to follow up this week with a version that fixes some bugs.
This Wednesday, I will be giving an online presentation about it.
If you are interested in attending, I can PM you a link to watch it.
Please let me know what you think!
I just uploaded the presentation! https://archive.org/details/presentation_202201
Sorry if the volume is a bit low. If it's too quiet, I can upload a louder version later.
The last 20 minutes is questions.
Nice work!
In section โ7.3 Lamduโ:
For example, if we attempt to insert a number where a function is expected, the expression is transformed to an application term with a hole for the argument. This term can then be typed as a free type variable. However, the number is inserted in the function position of the application term, which still results in a type error.
The last sentence is incorrect. The number is actually inserted in the argument of the application term in the underlying language, and there is no type error.
Perhaps the confusion stems from the sugared surface language showing it as a number with a question mark next to it (which we call a โfragmentโ with a number in it).
I would like to hear about your ideas for more advanced solutions ๐
One idea we have in mind is that you should be able to โrecordโ results of IO interactions and then re-evaluate from recorded runs. Then you could modify the program up to a point where the IO actions that it invoked changed.