Sun Jul 19 11:23:21 CEST 2009
Standard way for Metaprogramming C?
One thing that I find ironic: electrical engineers (EE) are obsessed
with macros. In fact, all the electronic design tools I know are
essentially template programming systems, where static (physical!)
structures are generated from high-level descriptions, and a lot of
effort is put into making sure that what is generated is actually
correct by "executing" the descriptions on different levels of
abstraction (simulation / verification).
Why is it then that in current practice, the world of embedded
programming, which is so close to the world of electronics design,
doesn't really have a streamlined way to do metaprogramming of C? Why
do people just take C for granted?
Yes, there are macros in a macro assembler, and there is the C
preprocessor, there is M5 in the autotools and there are plenty of
cases where EEs "discover perl" or any other dynamic language and
start generating input to the assembler or C compiler. But there are
no _serious_ open tools I know of that attempt to take control of the
metacompiling process itself, abstracting away some of the red tape
that peeple keep solving over and over again - the main one being:
parsing and generating C code to and from abstract representations.
Not to say that there is no research in metaprogramming C. Start with
papers about MetaOcaml and follow references. Not to say either
that there are not systems that "compile to C" as a platform. I.e. the
MathWorks' Real-Time Workshop seems to attract a lot of investment
from industry as a standard platform to escape from C and VHDL /
Verilog, but the templating system is not really that much different
from the C preprocessor or M5. If the highlevel tools don't work for
you, you're still forced to dive into the internals of an ad-hoc
Most of commercial effort simply focusses on providing _languages_ to
the end user. Most tools hide the metaprogramming behind the scenes,
but nobody seems to be building open tools generic enough so they can
be picked up as a standard, so it can prevent the waste of time
created by ad-hoc metaprogramming systems where these specific tools
cannot be applied.
What I'm talking about is to give people the ability to _design
languages_ and get them off of the fear that this in some sense is
"magic". There should be a way to put these technologies in the hands
of the "small guy". This would involve:
* A simple metaprogramming tool chain that takes care of the nitty
gritty to save programmer's time and avoid ad-hoc choices. This
in the form of a library that can be included in C programs and
any other higher level language through a FFI.
* A way to "trick" embedded engineers out of their focus on C and
educate them about how high level programming languages and type
systems are implemented, so they can make educated decisions when
rolling their own.