A Perspective on D from game industry

[H. S. Teoh via Digitalmars-d]

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+dlang at 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+dlang at 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!