[<<][meta][>>][..]
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[1] 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[2] 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
system.

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.

[1] http://www.metaocaml.org/
[2] http://www.mathworks.com/products/rtw/ 







[Reply][About]
[<<][meta][>>][..]