Reducer: Return the locations of runtime errors

[OAGr]

• _ Is refactor
• x Is new feature
• _ Concerns documentation

[umuro]

@OAGr

Run time errors will not be on the current small piece of code running. Most of the time they will happen inside sth passed by bindings.

Therefore it is impossible to report correct location with bindings based running.

Positions in the parse tree has to be (file, line, column) for correct reporting.

I am suggesting creating a virtual filespace.

• So that we can parse, compile, run and error report like in all ordinary languages.
• When a file reference comes in an error, we are sure that we are talking about the same thing.

Virtual file space brings other future advantages because instead of code snipped the whole project is visible to the language.

• Static type analysis. Like in al file based functional languages. Because we are no more running unbindings.
• It will still be able to view the variables per file.
• Complete optimization based on forward usage and detecting unused variables.
• Making imported source available and yet not evaluating recursively. Because they are simply attached to the virtual filespace.
• debug and production runtimes. Compiled library objects per file.
• Pruning unused code and variables.

Then those building commands can be made available easily
parse(fileSpace, filename)
compile(fileSpace, filename)
touch(fileSpace, filename) // resets compilation and variables on filename and all dependents
run(fileSpace, filename) // Also resets variables on all dependents
runFileSpace(fileSpace) // Runs the whole thing.

fileSpace

• Makes the import mechanism consistent and yet evaluation is the internal business of the language.
• Errors has fileSpace references without a place for mistake.
• Stiching a project from different source cells and viewing variables still possible yet running is the internal business of the language.

Cheap workaround without doing is that I add filename parameter to everything and its your business to make sure that we are talking about and displaying the right "filename" on an error or while debugging. Or even the filenames are unique.

But because of optimized runtime, precompilation, filename uniqueness, static type analysis, non-hack imports, etc. I prefer a virtual fileSpace.

A fileSpace will also be the closed boundary project that is compiled, analizedd and run .

For many things to happen we need the files and the dependency graph of the files, to do all things that are possible in all the other languages.

Also having the project which the fileSpace, enables a consistent definition of external tools for the language.
My main motivation for project fileSpace is enabling a static type analysis in the future. 99% of runtime errors will be typing errors.
External bindings are preventing even the simplest type analysis. Moreover running on bindings will become a performance problem. I will keep external data export for viewing only, not for runtime continuation.

On the current Reducer interface errors will not have locations because they are happening somewhere else.

My proposal is that first doing project fileSpace collaboratively. Then we can switch over in 2 steps.

• Life goes on as it is but we start to evaluate fileSpace references instead of code snippets.
• Reducer2 with no bindings. We switch to running files and they know their dependencies.
  (We will be able to add dependencies to files. Dependencies and in source fileImports will act the same. Kind of hidden file import for the storybook)

[umuro]

On creating the simplest project data type, evaluate2(<project>, <sourceId>) and spice it with function call error location.
Wrap existing code with error location modifiers corresponding to their parse nodes.

[berekuk]

@umuro can you also make evaluate2 async? Even if you don't make runs interruptible yet, it'd be better not to change call signature again when that feature arrives.