Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feed.news.qwest.net!mpls-nntp-05.inet.qwest.net!216.196.98.143.MISMATCH!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: Marco van de Voort Newsgroups: comp.compilers Subject: Re: designing language extensions, was Looking for volunteers for XL Date: Sat, 3 Dec 2011 13:02:38 +0000 (UTC) Organization: Stack Usenet News Service Lines: 49 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-12-009@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> <11-12-002@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1323028898 35188 64.57.183.58 (4 Dec 2011 20:01:38 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 4 Dec 2011 20:01:38 +0000 (UTC) Posted-Date: 04 Dec 2011 15:01:38 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:381 On 2011-12-01, Kaz Kylheku wrote: >> 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, So can brainf*ck code :-) A faulty language doesn't precluding investing an huge amount of engineering, testing and adminstration/documentation to manage it. But that doesn't meant that all languages should be faulty :-) > 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. Well, that is what (pure) preprocessors do? :-) If you start adding more knowledge to the preprocessor it becomes a part of the compiler and language, and your macros are not true macros anymore, but inlinable functions. > 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. I would write that up to keeping the preprocessor mostly a text manipulator rather than a compiler, not a target language defect. A preprocessor that fully understood what it was parsing could hoist such declarations out of the block if the language needed it? > 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. I think this is a symptom of the above. A simple hierarchical structure is easier to duplicate between preprocessor and compiler, but it is the barriers that are are part of the definition (separate binary, textual substitution) that are the main problems.