Marv the Tinker
However, the dynamism that makes all of this possible also makes development of large applications somewhat nightmarish. Errors generally pop up long after application has started - or been deployed
- and often in parts of the code distant from their sources.
So, what can we do to improve the situation?
- immediate detection of errors during compilation;
- early detection of errors during execution;
- detect some vulnerabilities;
- generate code otherwise too unreadable/error-prone to be written manually;
- take the opportunity to optimize the code for size, speed, etc.
We call that compiler Marv the Tinker.
What does it do?
For the moment, very little:
- Marv checks your syntax;
- Marv resolves your variable definitions;
- Marv informs you if your variable definitions collide;
- Marv informs you if you are using undefined identifiers.
How do I use it?
For the moment, Marv is not considered usable. If you want to try it, though, execute
It will produce the following files:
out.log(warnings and errors detected);
What is next?
Marv is far from complete. The next features that we intend to add are:
- Instrumenting code for early type-error detection;
Once this is done, we will proceed with
- Instrumenting code for pre/post conditions error detection;
- Instrumenting code for detection of broken invariants;
- Elements of static type-checking with inference.