Re: Looking for volunteers for XL

On 2011-11-28, BartC <bc@freeuk.com> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> On 2011-11-26, BartC <bc@freeuk.com> wrote:
>
>>> However, if the design of X2 isn't going to change, you might as well
>>> just write a compiler directly for X2; it's not necessary to make
>>> available, to the programmer of X2, all those untidy language-building
>>> features (for an example, see C++).
>
>> You're trying to fit extensible languages into the traditional model,
>> in which a lone guru (or small group of such) working atop a mountain
>> carves a programming language onto stone tablets, which then descend
>> down to the masses.
>
> You've put that well, that's exactly what I think!
>
> Take the well-known language C, which has a crude mechanism to extend
> it in the form of its pre-processing macro language.
>
> Most enhancements you might want to make to the language, can be
> achieved by some clunky, ugly macro. But the real problem is that your
> code now consists of a private, ad-hoc collection of macros which
> no-one else understands.


That isn't the problem, because collections of macros can be
well-designed, implemented and documented, and even in C there have
been some decent C macros developed, like the <sys/queue.h> stuff in
BSD UNIX. People other than the original authors understand those and
use them.


No, the only problem is that the C preprocessor is weak.


Using the C preprocessor to argue against macros is a textbook example of a
strawman argument: pick the weakest example of a category as a representative
of the category.


I was struggling with C macros just today. In my codebase I have an
a macro or2(x,y) which is supposed to return X and not evaluate Y,
or else if X is the value nil, then return Y. Problem is I wrote it like
this:


    #define or2(x,y) ((x) ? (x) : (y))


I made a mental note not to use this where the double evaluation of x would
matter. But then of course months later I forgot about the mental note and
misused it, creating a bug. So I set about fixing the macro, but quickly
remembered that there isn't a way to do it. You can't do this simple thing in
standard C, period.


So I came up with this kludge:


    {
        use_or2;


        /*...*/


        /* ... */ foo = or2(xyzzy, flop()) /*...*/
    }


In a lexical scope where you want to use or2, you have to have this
magic incantation "use_or2;". This declares the hidden variable needed
to do the job, without explicitly revealing what it is.


Not all the problems in the C preprocessor are in the preprocessor. Never mind
that all it can do is substitute, arguments, paste tokens. produce strings,
and suck in include files. One big problem is that the target language for
macro expansions (C) sucks. For one thing, any syntactic unit that contains
declarations cannot be an expression that returns a value. Macros that need to
generate complex code that requires hidden variables automatically have a
difficulty in returning a value in a function-call-like way, because only
expressions do that. Macros do not work well over languages that don't have a
uniform syntax that corresponds well to the implied abstract syntax trees.
Divisions between statements, expressions and declarations are
anti-extensibility barriers. Then there are syntactic issues such as that
MAC({a, b}) doesn't recognize {a, b} as unit, but as {a and b}. Only
parentheses are processed. That could have been easily fixed by specifying
that braces, brackets as well as parentheses must properly nest in a macro
argument, and will protect embedded commas.

Return to the comp.compilers page.
Search the comp.compilers archives again.