That is why we must provide tools to allow smooth transition from C to better languages, and reuse of old code. Particularly, lots of device drivers for many different kind of hardware are written in C, and may be reused if such a project succeeds.
Such tools should enable to compile "C" code to other languages.
"other languages" may mean some low-level language to be compiled or
interpreted by a compiler-backend, run-time or cpu, and thus the C translator
would be used just as yet another C compiler.
but to allow full reuse of existing "C" sources, more must be possible:
these tools should be able to understand the semantics of C routines inside
their context, and to generate (with human help and selection)
human-understandable programs in a higher-level language, that would
express the same algorithm and include the C specificities only as
annotations to achieve the translation reversible and allow translated
programs to interact at least as well as the original.
that is, to isolate and render back the very subtance of the C program,
stripped of its lame C dependencies, limitations and bogus "optimizations".
The C translator could even be used as a C-to-C translator, that'd allow
easier manipulation, debugging and maintenance of C programs ! Or it may
be used to generate interfaces between code produced by a C compiler and
code written in other languages. Applications of such a translator are
infinite !
That's only lame C dependencies. The C translator should be able to handle that into using exceptions, structured return values, and object arguments.
#define's should be translated into constant
(and higher-level if using parameters or concatenation) constructs,
and lists of #define's as well as enum's should be
translated into high-level case constructs.
#if's may be expanded at translation time to achieve actual
compilation, or kept as higher-level constructs to achieve separate translation
of trickier modules.
Back to the Tunes meta-translator project.
Subproject maintainer: