Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: Kaz Kylheku Newsgroups: comp.compilers Subject: Re: Looking for volunteers for XL Date: Thu, 1 Dec 2011 05:35:32 +0000 (UTC) Organization: A noiseless patient Spider Lines: 78 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-12-002@comp.compilers> References: <11-11-048@comp.compilers> <11-11-053@comp.compilers> <11-11-054@comp.compilers> <11-11-061@comp.compilers> <11-11-064@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1322803755 56736 64.57.183.58 (2 Dec 2011 05:29:15 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 2 Dec 2011 05:29:15 +0000 (UTC) Keywords: design, syntax Posted-Date: 02 Dec 2011 00:29:15 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:374 On 2011-11-28, BartC wrote: > "Kaz Kylheku" wrote in message >> On 2011-11-26, BartC 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 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.