main 9.0
No Matches
alc compiler

Create source-code from structured-data


The alc is the abbreviation for "all languages compiler" where languages stands for programming languages as well as any form of structured data.

  • languages: C C++ C# VB.NET Java Python Ruby Perl PHP Tcl or GO
  • configuration: doxygen, texi, vim, shell etc

The alc-compiler is the central tool in the NHI1-project and is used to take over error-prone and monotonous tasks that otherwise take a lot of time. The guiding principle in the alc-compiler is simply explained:

‍a code is only correct and valid if the alc-compiler has written it

That sounds a bit aloof at first, but it's the truth. because if you take programming seriously, you have to admit to yourself that people are far too imperfect to write really error-free code.


The alc-compiler does not create an executable but source-code which in turn is further processed by a third tool such as gcc, java or tcl ...

‍I call generating source-code meta-compilation, which is an in-between between source-code-programming and binaray-code-compiling.

And because the alc-compiler generates source-code, the source-code is also written directly into the source-code-file, such as "*.c/h" for "C" or "*.java" for "java".

‍The alc-compiler thus forms a team with the programmer that ultimately works in such a way that the alc-compiler does the monotonous work and the programmer does the creative work.


The goal for the alc-compiler is explicitly not the 100% solution, but the goal of the alc-compiler is the 80/20 solution.

‍80% of the code is generated by the alc-compiler and 20% of the code by the human programmer.

The 80/20 rule is also the reason why the alc-compiler writes its source code directly where the programmer writes, for example in the "*.c" or the "*.h" file, because the alc-compiler and the programmer work together together.

‍But now it has been shown that the alc-compiler is getting smarter over time, so that it sometimes tends towards 90/10 or maybe even towards 100/0.


The central tool within the alc-compiler is the atomic-code-block (block for short), which is the term for a piece of source code that is so fundamental it can no longer be divided and thus forms a unit.

‍The alc-compiler takes these blocks and puts the application together from them.

Since the atomic-code-block is not application-specific, one and the same block is used in a wide variety of applications in a wide variety of places. This permanent reuse ensures that the following conditions are self-fulfilling.

  1. The block is tested to the maximum because it has worked in very different places with very different requirements.
  2. Should this block be wrong (which rarely happens) then the corrected block will of course be corrected everywhere, i.e. in all applications.


The basic workflow of the alc-compiler is defined as:


The meta-code is an importand part of the alc-compiler because this is the glue between the input files (e.g. api-definition} and the output files (e.g. the code)

‍The best definition of the meta-code is like a machine-readable header-file with the api-definition and the api-attribute combined.


The kernel-developer has control over the alc-compiler and the source-code and can thus implement an effective round-trip of development.
Each needed feature is then added directly into the source-code using the __parser__ attribute to be used in the meta-backend.
Ultimately, the round-trip results in new source-code, which is ultimately stored in the source-code-file.