But I will indeed carefully document how to use the interfaces in normal usage, which includes embedding the Mithril engine within other apps, and includes dynamicly extending the set of objects and methods supported by C runtime primitives. But the Mithril docs will assume a rather high level of competence in comparative language knowledge. For example, Mithril will have closures, and the docs will make very little attempt to explain what closures are beyond documenting interfaces and exact behavior involved when using them. In particular, garbage collection and good basic collection classes are important, as well as high many order operations with functions and collections that are common to many lisp implementations. Mithril will try to do a reasonably good job at many tasks that a developer should not have to do more than once in a lifetime, like write a good memory manager.
Life is too short to keep doing the same basic things over and over again.
Mithril will try to make it just as easy to write and link C code with Mithril as to write new code in a high level Mithril syntax that gets interpreted or compiled. In practice, the combination of components is often enormously harder than one might expect, because of rather insidious differences in understandings regarding inter-system code contracts that are important but might be mostly unstated. So a very flexible and forgiving environment is needed to assemble software that might have pernicious impedance mismatches. A strong and flexible dynamic language can provide the initial first cut composition of system elements for very little cost. Then after this starts working well, a developer can focus on making improvements, or moving on to whatever task has higher priority than shaving performance percentage points from glue code.