On Mon, Jun 16, 2014 at 08:08:50PM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/16/2014 5:44 AM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dl...@gmail.com>" wrote:
> >As far as I can tell string mixins have the same bad properties that
> >macros have.
>
> Assuming you are talking about C macros:
>
> Having implemented the C preprocessor (multiple times), make's macro
> system, designed and implemented ABEL's macro system, Ddoc's macro
> system, and string mixins, I can unequivocably object to that opinion!
> The C macro system is awesome in its awfulness. Let me count the ways:
>
> 1. Probably < 10 people in the world actually understand it all the
> way down. It is absurdly complex for what little it does. Paul
> Mensonidas is usually acknowledged as the "world's leading expert on
> the C preprocessor." Why would a freakin' macro processor even have an
> ecological niche for a world leading expert on it? The mind boggles.
So that you can write IOCCC entries that abuse the dark corners of cpp,
of course. ;-)
[...]
> 5. There is no scoping of names of any sort - no hygiene whatsoever.
> Any #include file can trash any subsequent, unrelated, #include file
> in any way.
Do string mixins have scoping of names?
I do agree, though, that D's string mixins eliminated a whole class of
cpp abuses by requiring that the input string be a set of complete
statements or declarations -- things like:
mixin("writeln(");
mixin(");");
are rejected by the compiler, whereas in C:
#define MIXIN_1 writeln(
#define MIXIN_2 );
MIXIN_1 MIXIN_2
are happily accepted, leading to IOCCC tricks like:
#define block(x) { x }
#define split_block(y) } y {
void func()
block(
printf("a");
split_block(void main())
printf("b");
)
// The above nastiness translates to:
void func() {
printf("a");
}
void main() {
printf("b");
}
(To my shame, I must admit that I actually did this in an IOCCC entry --
in fact, in an even worse form than shown above. :P)
None of this insanity is permitted by D's string mixins, which is a big
plus, in my book.
> 6. Any syntax highlighter cannot work entirely correctly without
> having a full preprocessor.
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
> 7. Because of the preprocessor, valid C code need not look remotely
> like C code according to the C grammar.
Ah yes, this brings back sweet memories of this amusing little IOCCC
entry:
http://www.ioccc.org/2005/chia/chia.c
:-)
> 8. There are no looping macros, no CAR/CDR capabilities (Ddoc has the
> latter).
[...]
On Mon, Jun 16, 2014 at 08:10:40PM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/16/2014 8:18 AM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dl...@gmail.com>" wrote:
> >Sure, just like m4 and cpp can be extremely powerful. Too powerful…
>
> One of the sins of cpp is it is not powerful enough, forcing a lot of
> awkward usages.
I thought cpp's non-Turing-completeness was actually intentional? As if
cpp nastiness isn't already bad enough, as you pointed out above... I
dread to imagine a cpp that is "powerful enough"(!).
In any case, string mixins are better than cpp in several ways, but they
still do suffer from some of cpp's problems.
T
--
Stop staring at me like that! It's offens... no, you'll hurt your eyes!
