mixin + CTFE, to big a hammer??

[Reiner Pope]

BCS wrote:
> I have been thinking about the new functionality added by the code mixin 
> and CTFE features and I'm thinking that they may be "to big a hammer" 
> for may jobs.
> 
> Take my parser generator as an example. I don't think there would be 
> anything to gain by using mixin as the primary method of code 
> generation. Firstly, code generated this way will inherently be harder 
> to read and debug. Also it doesn't do anything that tuple iteration 
> doesn't do just as well.
> 
> I will admit that there may be some things to be gained there by using 
> mixin code (the terminal and action call backs could benefit a lot from 
> this) but these are only minor changes. Also mixin code would be 
> invaluable for some more complicated cases.
> 
> Why is this important? I think that many valuable types of code 
> generation would benefit more by improving the static control structures 
> (foreach/if/etc.) than they would from more mixin like features.
> 
> One feature I would like is a true static foreach, one that can iterate 
> over any built in type arrays or a tuple but does unrolling and per-loop 
> semantic analysis like with tuples. This, in conjunction with CTFE, 
> would make for huge improvements in what can readily be accomplished by 
> moving much of the processing of the code generator input into function 
> and out of templates.
> 
> Basically, I'm saying that while mixin+CTFE is good from many things, it 
> shouldn't be pushed at the expense of the more mundane techniques.
> 
> Just some thoughts, what do you all think?
I think they have already proven useful, looking at what people are 
doing with them:

- renoX's improvement on format strings, to allow putf("x is %d{x}");
- Kevin Bealer's reflective enums
- Kirk says that mixins resulted in a vast reduction of code for using PyD

Sure, *perhaps* only some people will write mixin code, but these three 
examples could be of direct use to many people; anyone can understand 
how putf should behave, even if the implementation is trickier.

As I see it, the major use of mixins is to completely solve the 
identof(char[]) problem: we can now very simply make an identifier out 
of a compile-time char[], and I believe that this is what all 3 of these 
projects make use of.

Mixins are also quite useful in mostly-D DSLs; instead of parsing all 
the DSL code and converting it into D code, you just need to get the 
overall structure, and then mixin the D code again:
> mixin MyStateMachine(`
> state Finished { /* Some D code */ ... }
> state Starting { /+ More D code +/ ... }
> `);
It's relatively easy to write a parser which just counts bracket levels, 
so all you have to do is parse 'state Finished' and 'state Starting' and 
then capture the D code and mix it back in. I've done this kind of thing 
   for implementing pattern-matching, and it is quite painless; mixins 
are what make this possible.


CTFE is an improvement on template meta-programming, since it allows for 
plain D code implementations of compile-time functions. This is 
therefore inherently /easier/ to read than template meta-programs, and I 
think it is preferable in all cases: anyone who can read D code can 
understand it.


Of course, neither of these mechanisms are mature yet, so there are 
syntactic issues and other gripes, but we can rest assured that these 
will (mostly) be fixed as we get more experience with them.

Cheers,

Reiner