We've built up similarly *dependency-injected* interfaces to the keyboard,
mouse, disk and network.
1. Support for testing side-effects like performance, deadlock-freedom,
race-freeness, memory usage, etc. Mu's *white-box tests* can check not just
the results of a function call, but also the presence or absence of
specific events in the log of its progress. For example, here's a test that
our string-comparison function doesn't scan individual characters unless it
has to:
Another example: if a sort function logs each swap, a performance test can
check that the number of swaps doesn't quadruple when the size of the input
doubles.
Besides expanding the scope of tests, this ability also allows more
radical refactoring without needing to modify tests. All Mu's tests call a
top-level function rather than individual sub-systems directly. As a result
the way the subsystems are invoked can be radically changed (interface
changes, making synchronous functions asynchronous, etc.). As long as the
new versions emit the same implementation-independent events in the logs,
the tests will continue to pass. ([More information.](http://akkartik.name/post/tracing-tests))
1. Organizing code and tests in layers of functionality, so that outsiders can
build simple and successively more complex versions of a project, gradually
enabling more peripheral features. Think of it as a cleaned-up `git log`
for the project. ([More information.](http://akkartik.name/post/wart-layers))
These mechanisms exist in the context of a low-level statement-oriented
language (like Basic, or Assembly). The language is as powerful as C for
low-level pointer operations and manual memory management, but much safer,
paying some run-time overhead to validate pointers. It also provides a number
of features usually associated with higher-level languages: strong
type-safety, function overloading, lexical scope, generic functions,
higher-order functions, and [delimited continuations](http://akkartik.name/coroutines-in-mu).
*Taking Mu for a spin*
Mu is currently implemented in C++ and requires a Unix-like environment. It's
been tested on Ubuntu, Mac OS X and OpenBSD; on x86, x86\_64 and ARMv7; and on
recent versions of GCC and Clang. Since it uses no bleeding-edge language
features and has no exotic dependencies, it should work with most reasonable
versions, compilers or processors.
Running Mu will always (re)compile it if necessary:
```shell
$ cd mu/archives/2.vm
$ ./mu
```
As a simple example, here's a program with some arithmetic:
Mu functions are lists of instruc//: A few literal constants.
:(before "End Mu Types Initialization")
put(Type_ordinal, "literal-boolean", 0);
//: 'true'
:(code)
void test_true() {
load(
"def main [\n"
" 1:boolean <- copy true\n"
"]\n"
);
CHECK_TRACE_CONTENTS(
"parse: ingredient: {true: \"literal-boolean\"}\n"
);
}
:(before "End Parsing reagent")
if (name == "true") {
if (type != NULL) {
raise << "'true' is a literal and can't take a type\n" << end();
return;
}
type = new type_tree("literal-boolean");
set_value(1);
}
//: 'false'
:(code)
void test_false() {
load(
"def main [\n"
" 1:boolean <- copy false\n"
"]\n"
);
CHECK_TRACE_CONTENTS(
"parse: ingredient: {false: \"literal-boolean\"}\n"
);
}
:(before "End Parsing reagent")
if (name == "false") {
if (type != NULL) {
raise << "'false' is a literal and can't take a type\n" << end();
return;
}
type = new type_tree("literal-boolean");
set_value(0);
}
//: 'null'
:(before "End Mu Types Initialization")
put(Type_ordinal, "literal-address", 0);
:(code)
void test_null() {
load(
"def main [\n"
" 1:address:number <- copy null\n"
"]\n"
);