HigherOrderCO
Add more eval API options
Right now, the only option in api.rs is an evaluation function that takes and outputs hvm code as text.
I think an option of having the input and output be a language::syntax::File would be good for using HVM inside other projects where we might be generating HVM code dinamically.
Also, the way the "extra functions" are passed is a bit strange. If interpreted functions are passed as part of the input code and precompiled functions are pulled from the precomp.rs file, what is the use of having another way of giving the API custom functions?
Having an option to disable / not load any precompiled functions could also be interesting for writing tests.
I see that some internal HVM tests keep failing every time a new default precompiled function is added since some of them rely on the number of terms in the rulebook.
Too, my feeling is the API would need some love, I would be pleased to see an API as done for Gluon https://github.com/gluon-lang/gluon/blob/master/book/src/embedding-api.md
@frehberg Good point, gluon is doing a log of things right as a host-extension/scripting language. I think there are many use cases where HVM can be useful as an embedded scripting language for (Rust) hosts. In fact, I hope it can replace Lua for many host-extension/scripting use cases. This would require marshalling of Rust symbols like gluon has (being able to call into HVM and allowing HVM to call host functions), and ideally the host can also specify exactly which symbols should pre-exist in the "prelude" so that it's not "opinionated" about the prelude like gluon is (starting from a blank slate). And it would also be nice being able to query/inspect the HVM runtime which symbols are defined and read out their definition from the host (not just as text) and to have a way to sandbox user scripts and only allow certain effects (e.g. allowing or forbidding file-system/internet access or calling native libs from HVM).
With a strongly typed language on top of HVM (such as Kind), it also has the potential to become very useful as a replacement for Python/JS/Matlab when it comes to interactive computation / interactively exploring/visualizing data / tying native libs together with higher-level glue code. (There's no reason to leave this domain to dynamically/weakly typed languages.)
