Meta-languages introduced in this white paper are languages used to describe and/or operate on other languages. More specifically, they are about code generation system which can be specified by a DSL belonging to meta-languages. The kinds of meta-language referred to by this white paper are hierarchic meta-languages, from more general ones starting from initial design of the system to more specific ones in which further user specification are encoded, in the pipeline of software production. The more general meta-languages act at least in part to generate the next level of more specific ones. In the duality point of view mentioned above, each level of meta-language inherits the knowledge or specifications of their parent one, resulting in an unlimited variation for the end products at each level.
Using meta-language driven code generation system in software production process has many benefits, including but not limited to: 1) quality assurance and increased code reusability; 2) consistent requirement interpretation and implementation, which now are encoded as a meta-language at certain level; 3) repeatability in a iterative production process and post production maintenance process; 4) reduction in cost of production; 5) much more increased information content, inherited from levels of meta-languages producing them, which provide bases for an increased intelligence, in the end products; 6) easier end user participation in the customization of the end products; etc.. The potentials are endless.
But good things do come with costs in the sense that meta-language building and usage is an area that is not easy to get into, at least for majority of developers. Developing hierarchical meta-languages needs computer assistant tools (i.e. code generators), especially for non-top level ones, because it is hard to accomplish manually in real production cases. Currently there is very little published information about meta-language driven code generations. Obvious this is an area that is quite advanced and also very technical, many software producers may use them one way or another in their automation pipeline, although most of which use them only as supplementary parts or steps, not something that “drives” the process.