meta pre-processor

[Guest]

I'm starting to design a meta pre-processor for the C language. It could
also be used for other languages, by C is my focus. The purpose of this
pre-processor is to select sections of code from files to be included in
other files. The goal is the ability to code related items such as structs,
and functions or macros that use those structs, in a single file, while the
actual code needs to be split up into separate .c and .h files, and combined
the parts from other code, for compiling. This is to allow my code to be
organized more like modules. That way a module can be added in without the
need to change existing code. The meta pre-processor would extract code from
these modules and construct the code to be compiled as well as the header to
be exported.

What I am looking for suggestions on is how to define a control statement
for the meta pre-processor to look for. This control statement will be
removed from the code, so it does not have to be something that would be
ignored or bypassed in the C pre-processor and C compiler. But it does
need to be something that no one would ever need to code in C that the meta
pre-processor would mistakenly think is its control statement when it is
not. The control decisions will be on a line-by-line basis and will not be
embedded in code within a line, much like the C pre-processor.

My first inclination is to use ## as a prefix, possibly with the added
requirement that it must be in positions 0 and 1 (0 based) on the line,
and/or must be followed with a unique keyword. There would be additional
control words and arguments to these meta pre-processor statements.

Any suggestions?

 

[ld]

I'm starting to design a meta pre-processor for the C language.  It could
also be used for other languages, by C is my focus.  The purpose of this
pre-processor is to select sections of code from files to be included in
other files.  The goal is the ability to code related items such as structs,
and functions or macros that use those structs, in a single file, while the
actual code needs to be split up into separate .c and .h files, and combined
the parts from other code, for compiling.  This is to allow my code to be
organized more like modules.  That way a module can be added in without the
need to change existing code.  The meta pre-processor would extract code from
these modules and construct the code to be compiled as well as the header to
be exported.

What I am looking for suggestions on is how to define a control statement
for the meta pre-processor to look for.  This control statement will be
removed from the code, so it does not have to be something that would be
ignored or bypassed in the C pre-processor and C compiler.  But it does
need to be something that no one would ever need to code in C that the meta
pre-processor would mistakenly think is its control statement when it is
not.  The control decisions will be on a line-by-line basis and will not be
embedded in code within a line, much like the C pre-processor.

My first inclination is to use ## as a prefix, possibly with the added
requirement that it must be in positions 0 and 1 (0 based) on the line,
and/or must be followed with a unique keyword.  There would be additional
control words and arguments to these meta pre-processor statements.

Any suggestions?

looking at GPP preprocessor?

a+, ld.

 

[Keith Thompson]

I'm starting to design a meta pre-processor for the C language. It could
also be used for other languages, by C is my focus. The purpose of this
pre-processor is to select sections of code from files to be included in
other files. The goal is the ability to code related items such as structs,
and functions or macros that use those structs, in a single file, while the
actual code needs to be split up into separate .c and .h files, and combined
the parts from other code, for compiling. This is to allow my code to be
organized more like modules. That way a module can be added in without the
need to change existing code. The meta pre-processor would extract code from
these modules and construct the code to be compiled as well as the header to
be exported.

What I am looking for suggestions on is how to define a control statement
for the meta pre-processor to look for. This control statement will be
removed from the code, so it does not have to be something that would be
ignored or bypassed in the C pre-processor and C compiler. But it does
need to be something that no one would ever need to code in C that the meta
pre-processor would mistakenly think is its control statement when it is
not. The control decisions will be on a line-by-line basis and will not be
embedded in code within a line, much like the C pre-processor.

My first inclination is to use ## as a prefix, possibly with the added
requirement that it must be in positions 0 and 1 (0 based) on the line,
and/or must be followed with a unique keyword. There would be additional
control words and arguments to these meta pre-processor statements.

Any suggestions?

There is a minor potential problem with using ##. ## is already an
operator recognized by the preprocessor; it can occur only in a macro
definition, but it could appear at the beginning of a line.

If you want to ignore that issue, I wouldn't require it to be at the
very beginning of the line. The # prefix used for C preprocessor
directives can be preceded and/or followed by arbitrary whitespace;
for consistency, I suggest that ## should behave the same way.

You might consider using some character or invented token that can't
appear in portable C at all. I think the only printable characters
that aren't part of the C character set are '@' (used by Objective-C),
'$' (permitted in an identifier by some implementations), and '`' (no
use that I know of, but difficult to distinguish visually from ''').

If you want to stick more closely to standard C, you could use
#pragma.

 

[Guest]

| There is a minor potential problem with using ##. ## is already an
| operator recognized by the preprocessor; it can occur only in a macro
| definition, but it could appear at the beginning of a line.

The only case where I can see a ## appearing in a macro definition and
at the beginning of a line is a multi-line macro definition, where the
preceeding line ends with a backslash. The use I have for my meta
statements would not need to be in the middle of a macro definition.
So if I group all the lines together in a macro definition, or just not
test any line that follows a "backslash newline" combination for the ##
at the beginning, then I think that might work.


| If you want to ignore that issue, I wouldn't require it to be at the
| very beginning of the line. The # prefix used for C preprocessor
| directives can be preceded and/or followed by arbitrary whitespace;
| for consistency, I suggest that ## should behave the same way.

I'm not stuck on the idea that it be at the beginning of the line. But
I would not have a problem doing that limitation as a means to avoid a
comflict of that would do it.


| You might consider using some character or invented token that can't
| appear in portable C at all. I think the only printable characters
| that aren't part of the C character set are '@' (used by Objective-C),
| '$' (permitted in an identifier by some implementations), and '`' (no
| use that I know of, but difficult to distinguish visually from ''').

Maybe ### ?

| If you want to stick more closely to standard C, you could use
| #pragma.

My understanding of #pragma is that it is for implementation use by the
compiler suite. That leaves it rather wide open to many possible uses,
of which my meta-pre-processor could potentially interfere. I do not
conside my meta-pre-processor to be part of the compiler suite, but more
a case of a code generator with an input that is intended to be close
enough to C that editors can assume it to be C for assisted editing.

My intention is to run the meta-pre-processor from within a configure
script, although potentially someone might find it useful within a
Makefile. The approach I take with development now is to always run the
configure script from within an empty directory, using the full path to
the configure script (with an option to pass the path where the script
is found by another means where $0 fails to provide it). That script
would then populate the empty directory, including running the meta
pre-processor to generate the code to be compiled (along with Makefile
and whatever else might be needed). I do it this way now. The idea is
to create the meta pre-processor to expand on what I can do.

 

[Guest]

| On 20 juil, 23:27, (e-mail address removed) wrote:
|> I'm starting to design a meta pre-processor for the C language.  It could
|> also be used for other languages, by C is my focus.  The purpose of this
|> pre-processor is to select sections of code from files to be included in
|> other files.  The goal is the ability to code related items such as structs,
|> and functions or macros that use those structs, in a single file, while the
|> actual code needs to be split up into separate .c and .h files, and combined
|> the parts from other code, for compiling.  This is to allow my code to be
|> organized more like modules.  That way a module can be added in without the
|> need to change existing code.  The meta pre-processor would extract code from
|> these modules and construct the code to be compiled as well as the header to
|> be exported.
|>
|> What I am looking for suggestions on is how to define a control statement
|> for the meta pre-processor to look for.  This control statement will be
|> removed from the code, so it does not have to be something that would be
|> ignored or bypassed in the C pre-processor and C compiler.  But it does
|> need to be something that no one would ever need to code in C that the meta
|> pre-processor would mistakenly think is its control statement when it is
|> not.  The control decisions will be on a line-by-line basis and will not be
|> embedded in code within a line, much like the C pre-processor.
|>
|> My first inclination is to use ## as a prefix, possibly with the added
|> requirement that it must be in positions 0 and 1 (0 based) on the line,
|> and/or must be followed with a unique keyword.  There would be additional
|> control words and arguments to these meta pre-processor statements.
|>
|> Any suggestions?
|
| looking at GPP preprocessor?

I don't follow. Looking up "GPP" finds "General Purpose Preprocessor",
which makes your statment have "preprocessor" twice. So I don't get a
usable meaning from what you ask.

What I am designing is specific to C programs. Using it for other languages
could potentially make the meta pre-processor fail if what that language
allows could appear to the meta pre-processor as one of its own statements.

 

[Guest]

|>I'm starting to design a meta pre-processor for the C language. It could
|>also be used for other languages, by C is my focus. The purpose of this
|>pre-processor is to select sections of code from files to be included in
|>other files. The goal is the ability to code related items such as structs,
|>and functions or macros that use those structs, in a single file, while the
|>actual code needs to be split up into separate .c and .h files, and combined
|>the parts from other code, for compiling. This is to allow my code to be
|>organized more like modules. That way a module can be added in without the
|>need to change existing code. The meta pre-processor would extract code from
|>these modules and construct the code to be compiled as well as the header to
|>be exported.
|>
|>What I am looking for suggestions on is how to define a control statement
|>for the meta pre-processor to look for. This control statement will be
|>removed from the code, so it does not have to be something that would be
|>ignored or bypassed in the C pre-processor and C compiler. But it does
|>need to be something that no one would ever need to code in C that the meta
|>pre-processor would mistakenly think is its control statement when it is
|>not. The control decisions will be on a line-by-line basis and will not be
|>embedded in code within a line, much like the C pre-processor.
|
| Consider using the macro processor m4, or taking some ideas from it,
| such as changing the spelling of some of the keywords to not match
| ones used in C (e.g. define and include).

BTDT wrt m4. Won't go back. Had enough of it in sendmail days (I don't do
sendmail anymore). A very annoying syntax. And besides, m4 is more about
making macro definitions that produce computed output. My meta pre-processor
is more of a "slice and dice" processor. It will be more a case of defining
when to start and stop output to selected files. One input file could have
its contents split up and different parts output to a few different files.
Then another file similarly split, but some of the output files will be the
same as the previous, with appending going on. The output can be specified
to a particular exact file in which case it will be written as is. Or it can
be specified to a template reference in which case the output files contents
order will be controlled by a template for that output file. For the most
part the copied data is unchanged. There is no macro substitution in this
scheme. It will do things like insert a line with ";" on it for function
prototypes going to headers, as an example of the few changes that might be
made. A function prototype will be output to both the compile file as well
as the header file in the respective forms.

This is not and will not be an attempt to parse C code at all. But it may
have some decision code based on things like environment variables or file
existance.

### target code "my_function.c"
### target funproto "header.h"
### begin code
### begin funproto
double my_function( int foo, double bar )
### end funproto
{
bar += (double) foo;
return bar;
}
### end code

Note that the begin and end are not nestable enclosures, but just controls
for flags. It could have the 2 "begin" statements in the other order and
be valid. Certain targets like "funproto" will have special definitions
that do things like output a ";" each time they are ended. All the details
are yet to be determined as this is just beginning the design.

I need to be sure that editors don't get confused by these meta pre-processor
statements so they handle the C syntax as before. Maybe I'll have to use
something that looks like a comment such as //## or such.

Well, maybe I will consider environment variable substitution:

### target code "${FUNCTION_NAME}.c"
### target funproto "header.h"
### begin code
### begin funproto
double ${FUNCTION_NAME}( int foo, double bar )
### end funproto
{
bar += (double) foo;
return bar;
}
### end code

This is nothing as extensive as m4 and is intended to be simpler. I want to
keep it simple. So m4 is out.

 

[ld]

| On 20 juil, 23:27, (e-mail address removed) wrote:
|> I'm starting to design a meta pre-processor for the C language.  It could
|> also be used for other languages, by C is my focus.  The purpose of this
|> pre-processor is to select sections of code from files to be included in
|> other files.  The goal is the ability to code related items such as structs,
|> and functions or macros that use those structs, in a single file, while the
|> actual code needs to be split up into separate .c and .h files, and combined
|> the parts from other code, for compiling.  This is to allow my code to be
|> organized more like modules.  That way a module can be added in without the
|> need to change existing code.  The meta pre-processor would extract code from
|> these modules and construct the code to be compiled as well as the header to
|> be exported.
|>
|> What I am looking for suggestions on is how to define a control statement
|> for the meta pre-processor to look for.  This control statement will be
|> removed from the code, so it does not have to be something that would be
|> ignored or bypassed in the C pre-processor and C compiler.  But it does
|> need to be something that no one would ever need to code in C that the meta
|> pre-processor would mistakenly think is its control statement when it is
|> not.  The control decisions will be on a line-by-line basis and will not be
|> embedded in code within a line, much like the C pre-processor.
|>
|> My first inclination is to use ## as a prefix, possibly with the added
|> requirement that it must be in positions 0 and 1 (0 based) on the line,
|> and/or must be followed with a unique keyword.  There would be additional
|> control words and arguments to these meta pre-processor statements.
|>
|> Any suggestions?
|
| looking at GPP preprocessor?

I don't follow.  Looking up "GPP" finds "General Purpose Preprocessor",
which makes your statment have "preprocessor" twice.  So I don't get a
usable meaning from what you ask.

I know that the 2nd P in GPP stands for Preprocessor... I added the
word "preprocessor" to help you google-ing because google-ing GPP
alone leads to many unrelated topics.

What I am designing is specific to C programs.

As GPP was originally designed for (AFAIK).

Using it for other languages
could potentially make the meta pre-processor fail if what that language
allows could appear to the meta pre-processor as one of its own statements.

You were asking for example of extensions to the C preprocessor. I
just mention GPP to look at because this primarily what it does. If it
doesn't fit your need, just drop it (after reading the doc).

a+, ld.

 

[Stefan Ram]

I'm starting to design a meta pre-processor for the C language.
Any suggestions?

http://www.ross.net/funnelweb/tutorial/macro_times.html
http://www.ross.net/funnelweb/tutorial/index.html

 

[Nick Keighley]

I'm starting to design a meta pre-processor for the C language.  It could
also be used for other languages, by C is my focus.  The purpose of this
pre-processor is to select sections of code from files to be included in
other files.  The goal is the ability to code related items such as structs,
and functions or macros that use those structs, in a single file, while the
actual code needs to be split up into separate .c and .h files, and combined
the parts from other code, for compiling.  This is to allow my code to be
organized more like modules.

I think you've re-discovered Literate Programming

That way a module can be added in without the
need to change existing code.  The meta pre-processor would extract code from
these modules and construct the code to be compiled as well as the header to
be exported.

<snip>

 

[Guest]

| On 21 juil, 02:32, (e-mail address removed) wrote:
|>
|> | On 20 juil, 23:27, (e-mail address removed) wrote:
|> |> I'm starting to design a meta pre-processor for the C language.  It could
|> |> also be used for other languages, by C is my focus.  The purpose of this
|> |> pre-processor is to select sections of code from files to be included in
|> |> other files.  The goal is the ability to code related items such as structs,
|> |> and functions or macros that use those structs, in a single file, while the
|> |> actual code needs to be split up into separate .c and .h files, and combined
|> |> the parts from other code, for compiling.  This is to allow my code to be
|> |> organized more like modules.  That way a module can be added in without the
|> |> need to change existing code.  The meta pre-processor would extract code from
|> |> these modules and construct the code to be compiled as well as the header to
|> |> be exported.
|> |>
|> |> What I am looking for suggestions on is how to define a control statement
|> |> for the meta pre-processor to look for.  This control statement will be
|> |> removed from the code, so it does not have to be something that would be
|> |> ignored or bypassed in the C pre-processor and C compiler.  But it does
|> |> need to be something that no one would ever need to code in C that the meta
|> |> pre-processor would mistakenly think is its control statement when it is
|> |> not.  The control decisions will be on a line-by-line basis and will not be
|> |> embedded in code within a line, much like the C pre-processor.
|> |>
|> |> My first inclination is to use ## as a prefix, possibly with the added
|> |> requirement that it must be in positions 0 and 1 (0 based) on the line,
|> |> and/or must be followed with a unique keyword.  There would be additional
|> |> control words and arguments to these meta pre-processor statements.
|> |>
|> |> Any suggestions?
|> |
|> | looking at GPP preprocessor?
|>
|> I don't follow.  Looking up "GPP" finds "General Purpose Preprocessor",
|> which makes your statment have "preprocessor" twice.  So I don't get a
|> usable meaning from what you ask.
|
| I know that the 2nd P in GPP stands for Preprocessor... I added the
| word "preprocessor" to help you google-ing because google-ing GPP
| alone leads to many unrelated topics.

When I have a specific term, I start my searches at Wikipedia, first.


|> What I am designing is specific to C programs.
|
| As GPP was originally designed for (AFAIK).

It doesn't appear to be.


|> Using it for other languages
|> could potentially make the meta pre-processor fail if what that language
|> allows could appear to the meta pre-processor as one of its own statements.
|
| You were asking for example of extensions to the C preprocessor. I
| just mention GPP to look at because this primarily what it does. If it
| doesn't fit your need, just drop it (after reading the doc).

No, I'm not asking for extensions of the C preprocessor. What I am looking
for is how to avoid a conflict with it, such that coding of directives for
the C preprocessor won't be (mis) interpreted by my meta pre-processor (or
whatever better name for it I come up with later).

 

[Guest]

| On 20 July, 22:27, (e-mail address removed) wrote:
|
|> I'm starting to design a meta pre-processor for the C language.  It could
|> also be used for other languages, by C is my focus.  The purpose of this
|> pre-processor is to select sections of code from files to be included in
|> other files.  The goal is the ability to code related items such as structs,
|> and functions or macros that use those structs, in a single file, while the
|> actual code needs to be split up into separate .c and .h files, and combined
|> the parts from other code, for compiling.  This is to allow my code to be
|> organized more like modules.
|
|
| I think you've re-discovered Literate Programming

Except that my intentions are not related to documentation specifically,
but rather, code modularization and organization. I suppose that can be
thought of as literate programming to the extent that such organization
aids in documentation. I could more easily document what that module
does in one place with what I'm trying to do. What I have seen literate
programming try to do often looks rather ugly in the code part. That is
no surprise since its focus was on the documentation part and the code
was just some baggage carried along.

I do remember a project a while back that tried to make a subset of English
language prose be compilable into runnable programs. They called it COBOL.


|> That way a module can be added in without the
|> need to change existing code.  The meta pre-processor would extract code from
|> these modules and construct the code to be compiled as well as the header to
|> be exported.
|
| <snip>

 

[Stefan Ram]

I do remember a project a while back that tried to make a subset of English
language prose be compilable into runnable programs. They called it COBOL.

http://attempto.ifi.uzh.ch/site/main.php?text=description/description.html

 

[ld]

| On 21 juil, 02:32, (e-mail address removed) wrote:
|>
|> | On 20 juil, 23:27, (e-mail address removed) wrote:
|> |> I'm starting to design a meta pre-processor for the C language.  It could
|> |> also be used for other languages, by C is my focus.  The purpose of this
|> |> pre-processor is to select sections of code from files to be included in
|> |> other files.  The goal is the ability to code related items such as structs,
|> |> and functions or macros that use those structs, in a single file, while the
|> |> actual code needs to be split up into separate .c and .h files, and combined
|> |> the parts from other code, for compiling.  This is to allow my code to be
|> |> organized more like modules.  That way a module can be added in without the
|> |> need to change existing code.  The meta pre-processor would extract code from
|> |> these modules and construct the code to be compiled as well as the header to
|> |> be exported.
|> |>
|> |> What I am looking for suggestions on is how to define a control statement
|> |> for the meta pre-processor to look for.  This control statement will be
|> |> removed from the code, so it does not have to be something that would be
|> |> ignored or bypassed in the C pre-processor and C compiler.  But it does
|> |> need to be something that no one would ever need to code in C that the meta
|> |> pre-processor would mistakenly think is its control statement when it is
|> |> not.  The control decisions will be on a line-by-line basis and will not be
|> |> embedded in code within a line, much like the C pre-processor.
|> |>
|> |> My first inclination is to use ## as a prefix, possibly with the added
|> |> requirement that it must be in positions 0 and 1 (0 based) on the line,
|> |> and/or must be followed with a unique keyword.  There would be additional
|> |> control words and arguments to these meta pre-processor statements.
|> |>
|> |> Any suggestions?
|> |
|> | looking at GPP preprocessor?
|>
|> I don't follow.  Looking up "GPP" finds "General Purpose Preprocessor",
|> which makes your statment have "preprocessor" twice.  So I don't get a
|> usable meaning from what you ask.
|
| I know that the 2nd P in GPP stands for Preprocessor... I added the
| word "preprocessor" to help you google-ing because google-ing GPP
| alone leads to many unrelated topics.

When I have a specific term, I start my searches at Wikipedia, first.

|> What I am designing is specific to C programs.
|
| As GPP was originally designed for (AFAIK).

It doesn't appear to be.

|> Using it for other languages
|> could potentially make the meta pre-processor fail if what that language
|> allows could appear to the meta pre-processor as one of its own statements.
|
| You were asking for example of extensions to the C preprocessor. I
| just mention GPP to look at because this primarily what it does. If it
| doesn't fit your need, just drop it (after reading the doc).

No, I'm not asking for extensions of the C preprocessor.

To quote myself, "example of extensions" doesn't have the same meaning
as "extensions of" for me.

 What I am looking
for is how to avoid a conflict with it, such that coding of directives for
the C preprocessor won't be (mis) interpreted by my meta pre-processor (or
whatever better name for it I come up with later).

That's why I mentioned GPP, because it provides cpp extensions (as
examples) and extensible syntax. I don't use it myself since I can do
what I need directly with cpp.

Now, coming back to you initial guess and considering the simplicity
of you aim, I would make a small awk script which grabs some tags and
values to do the job.

a+, ld.

 

[Keith Thompson]

No, I'm not asking for extensions of the C preprocessor. What I am looking
for is how to avoid a conflict with it, such that coding of directives for
the C preprocessor won't be (mis) interpreted by my meta pre-processor (or
whatever better name for it I come up with later).

[...]

Assuming you decide to implement your own meta preprocessor (I might
call it a pre-preprocessor), you could probably use "#:" as the prefix
for your directives. It's unlikely to appear in valid C code at the
beginning of a line. I think the only way it could appear at the
beginning of a line, even in deliberately contrived valid C code, is
as part of a comment or following a line that ends with \. If you
strip comments and join lines before processing your directives, that
won't be a problem; even if you don't, it's unlikely to be a problem
in practice.

I'd probably treat #: as a single, um, pre-preprocessing token, so it
can't be written as "# :", but I'd allow arbitrary whitespace to
appear before and/or after it, just for the sake of consistency with
the way the preprocessor's # token is treated.

 

[Guest]

| Now, coming back to you initial guess and considering the simplicity
| of you aim, I would make a small awk script which grabs some tags and
| values to do the job.

I'm more at ease coding it in C than in awk.

 

[Guest]

| Assuming you decide to implement your own meta preprocessor (I might
| call it a pre-preprocessor), you could probably use "#:" as the prefix
| for your directives. It's unlikely to appear in valid C code at the
| beginning of a line. I think the only way it could appear at the
| beginning of a line, even in deliberately contrived valid C code, is
| as part of a comment or following a line that ends with \. If you
| strip comments and join lines before processing your directives, that
| won't be a problem; even if you don't, it's unlikely to be a problem
| in practice.

I've decided I will parse out "line group" instead of "line", where a
"line group" is all the lines where all but the last end with backslash.
Then I would apply the test for the sentinal at the beginning of the
"line group". I don't actually need to buffer the whole line group, as
I could assert the rule that my meta pre-preprocessor directives are not
extended into the next line with backslash. Then once I merely have the
beginning of a line group (it is not, if the previous line ended with a
backslash) that is a solo line, I test for the sentinal, and if prosent
proceed with interpretation, and if not, process the line and its line
group as content however that content is to processed at that point.


| I'd probably treat #: as a single, um, pre-preprocessing token, so it
| can't be written as "# :", but I'd allow arbitrary whitespace to
| appear before and/or after it, just for the sake of consistency with
| the way the preprocessor's # token is treated.

That sounds like a good idea.

 

[Guest]

| (e-mail address removed) writes:
|>I do remember a project a while back that tried to make a subset of English
|>language prose be compilable into runnable programs. They called it COBOL.
|
| http://attempto.ifi.uzh.ch/site/main.php?text=description/description.html

Is this an admission by people working in an area where the native language
is German that English is the defacto language of information? IMHO, English
is a poor choice. Not that German would be much better. I think the best
choice would be Esperanto.

 

[Guest]

| |> I'm starting to design a meta pre-processor for the C language. It could
|> also be used for other languages, by C is my focus. The purpose of this
|> pre-processor is to select sections of code from files to be included in
|> other files.
|
| You should check out XVCL, which is a tool for managing generation of code
| from arbitrary fragments.
|
| http://xvcl.comp.nus.edu.sg/overview_brochure.php

Access counter shows me as number "000001". It must be broken if you have
accessed this page before.

This appears to be XML based. That's not a syntax I would tend to recommend
for hand coding. And it might not be understood well by text editors that
are trying to parse C code.

 

[Stefan Ram]

http://www.ross.net/funnelweb/tutorial/macro_times.html
http://www.ross.net/funnelweb/tutorial/index.html

Oh yes, and this is fun to read:

http://conal.net/blog/posts/the-c-language-is-purely-functional/

 

[Kaz Kylheku]

Well, maybe I will consider environment variable substitution:

### target code "${FUNCTION_NAME}.c"
### target funproto "header.h"

I would say that it's pointless to expose this division into header files and
..c files. Your processor can emit complete translation units which can be passed
straight to a compiler. These would just be temporary files with generated
names. Or even just pipes.

I suggest you integrate it with a build system; you want to support
incremental recompiling right? That can't be based on timestamps of your files.

### begin code
### begin funproto
double ${FUNCTION_NAME}( int foo, double bar )
### end funproto
{
bar += (double) foo;
return bar;
}
### end code

If we modify the code above, but not the prototype, how will you ensure that
only the code is recompiled, but not anything which depends on the prototype?

If interfaces and implementations are split into separate files, then you have
the file timestamps.

You might want some kind of hash based scheme; your preprocessor can detect
when an interface has changed by a change in the hash.

The integrated build system can then only generate the text that needs to be
generated and compile only what needs to be compiled.