As some of you will remember, I'm pretty strongly against macros for
various reasons. I think that most of the well-founded uses are covered by
mixfix and inlining, and I think that most of the *rest* of the uses are
really problematic.

Yet there is one thing we can do in C/C++ that I can't really do anywhere
else. I very often find myself building a "header" file that contains
things like this:

DEFUNICODECATEGORY(Cc, 0x00000001, "Control")

DEFUNICODECATEGORY(Cf, 0x00000002, "Format")

DEFUNICODECATEGORY(Cn, 0x00000004, "Unassigned")

DEFUNICODECATEGORY(Co, 0x00000008, "Private_Use")

DEFUNICODECATEGORY(Cs, 0x00000010, "Surrogate")

DEFUNICODECATEGORY(C,  gc_Cc | gc_Cf | gc_Cn | gc_Co | gc_Cs, "Other")


In this particular example, the file will get included multiple times to
produce:

1. An enum declaration (or more precisely: the members of that declaration)
2. Some structure declarations for the various unicode category tables
3. A string-based lookup table that can be used to locate the category
tables at runtime.

All of this is done in such a way that the output of the transform must be
a sequence of well-formed program fragments.

All of this is done in a purely textual way, and *none* of it changes the
lexical processing of subsequent code, except to the extent that
well-formed declarations and definitions are getting introduced into the
environment. As much as I like the hygene of hygienic macros, I don't think
this type of use rises to a level of complexity that warrants thinking
about hygiene too much.

All of this *could*, of course, be done by an external tool that transforms
text. The problem with such tools is that it is hard to make them work
across a range of platforms.

If we introduced "atoms" or "symbols" into the language, it could also be
done with an in-language compile-time processing mechanism.

Keeping in mind that I am *NOT* going to admit a macro mechanism that
changes the input processing generally, would the ability to do something
like:

    def someident = expand *transformer* constant-input-value;

be useful, where transformer must be a compile-time constant function whose
output is a string that replaces the apply clause?

I'm mostly thinking out loud here.



Jonathan
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to