www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - mixin + CTFE, to big a hammer??

reply BCS <BCS pathlink.com> writes:
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?
Mar 01 2007
next sibling parent reply kris <foo bar.com> writes:
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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no
Mar 01 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
kris wrote:
 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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no

...to unbacked arguments. What is exactly the base for comparing D's mixins with crack-cocaine? Andrei
Mar 01 2007
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
kris wrote:
 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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no

Just give it time, wait for it to mature from experience.
Mar 01 2007
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:
 
 kris wrote:
 BCS wrote:

 D mixin, in it's current guise, is about equivalent to crack-cocaine. 
 Easily the worst thing that happened to the language, IMO.

 Just say no


?? It's been around for a bit already. It doesn't seem to be getting better? -JJR

um, it's only been around for 2 versions ... I'm not in a position to say this, but keep using and testing it, report problems and suggest improvements.
Mar 01 2007
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
John Reimer wrote:
 On Thu, 01 Mar 2007 14:03:27 -0700, Hasan Aljudy wrote:
 
 John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:

 kris wrote:
 BCS wrote:

 D mixin, in it's current guise, is about equivalent to crack-cocaine. 
 Easily the worst thing that happened to the language, IMO.

 Just say no


It's been around for a bit already. It doesn't seem to be getting better? -JJR

I'm not in a position to say this, but keep using and testing it, report problems and suggest improvements.

Two versions?? I meant mixins... I was referring to mixin's alone, not CTFE. mixin's aren't the loveliest or most reliable feature to enter the D arsenal. And it's unfortunate if the language ends up adopting the mixin syntax as a base for experimenting with certain features. -JJR

well, mixins are 3 versions old ... not to be confused with template mixins, which is a totally different thing.
Mar 01 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:
 
 kris wrote:
 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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no


?? It's been around for a bit already. It doesn't seem to be getting better?

Patience is a virtue. :o) Besides, it's not like they started real bad. Andrei
Mar 01 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
John Reimer wrote:
 On Thu, 01 Mar 2007 13:25:43 -0800, Andrei Alexandrescu (See Website For
 Email) wrote:
 
 John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:

 kris wrote:
 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?

Easily the worst thing that happened to the language, IMO. Just say no


It's been around for a bit already. It doesn't seem to be getting better?

Andrei

mixin's mixin's mixin's...that's all I'm saying.

That's grammatically incorrect :o).
 They didn't start really good either. But, I guess you and I could go back
 and forth about whether that cup is half-full or half-empty. :)  Oh well.

Now we can go back and forth about spellchequers :oD. Andrei
Mar 01 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:

 kris wrote:
 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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no

Just give it time, wait for it to mature from experience.

?? It's been around for a bit already. It doesn't seem to be getting better? -JJR
Mar 01 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 01 Mar 2007 14:03:27 -0700, Hasan Aljudy wrote:

 John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:
 
 kris wrote:
 BCS wrote:

 D mixin, in it's current guise, is about equivalent to crack-cocaine. 
 Easily the worst thing that happened to the language, IMO.

 Just say no


?? It's been around for a bit already. It doesn't seem to be getting better? -JJR

um, it's only been around for 2 versions ... I'm not in a position to say this, but keep using and testing it, report problems and suggest improvements.

Two versions?? I meant mixins... I was referring to mixin's alone, not CTFE. mixin's aren't the loveliest or most reliable feature to enter the D arsenal. And it's unfortunate if the language ends up adopting the mixin syntax as a base for experimenting with certain features. -JJR
Mar 01 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 01 Mar 2007 13:25:43 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

 John Reimer wrote:
 On Thu, 01 Mar 2007 13:29:30 -0700, Hasan Aljudy wrote:
 
 kris wrote:
 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?

D mixin, in it's current guise, is about equivalent to crack-cocaine. Easily the worst thing that happened to the language, IMO. Just say no


?? It's been around for a bit already. It doesn't seem to be getting better?

Patience is a virtue. :o) Besides, it's not like they started real bad. Andrei

mixin's mixin's mixin's...that's all I'm saying. They didn't start really good either. But, I guess you and I could go back and forth about whether that cup is half-full or half-empty. :) Oh well. -JJR
Mar 01 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 01 Mar 2007 18:23:15 -0700, Hasan Aljudy wrote:

 
 Two versions?? 
 
 I meant mixins... I was referring to mixin's alone, not CTFE.
 mixin's aren't the loveliest or most reliable feature to enter the D
 arsenal. And it's unfortunate if the language ends up adopting the mixin
 syntax as a base for experimenting with certain features.
 
 -JJR

well, mixins are 3 versions old ... not to be confused with template mixins, which is a totally different thing.

Ok, my mistake? Got to love overloaded keywords; suddenly they remove the argument completely from one's grasp. :) -JJR
Mar 01 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 01 Mar 2007 17:47:36 -0800, Andrei Alexandrescu (See Website For
Email) wrote:
 
 
 mixin's mixin's mixin's...that's all I'm saying.  

That's grammatically incorrect :o).
 They didn't start really good either. But, I guess you and I could go back
 and forth about whether that cup is half-full or half-empty. :)  Oh well.

Now we can go back and forth about spellchequers :oD.

No, that sort of back and forth is too condescending, and I'm not very good at that game... actually, at this point I drum my fingers on the table and *yawn*, gradually drifting into a pensive state. My thoughts dance from misplaced possessives to incorrectly used adverbs before finally alighting on the question: "what makes certain people's minds tick?" ... Yes, I likely posted too quickly to this thread, and I really don't have any hard evidence to contribute. Disregard. -JJR
Mar 01 2007
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 01 Mar 2007 10:30:13 -0800, 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.

 Just some thoughts, what do you all think?

<opinion> They seem to be a highly complex solution that should only be used on the type of problem that just cannot be cost-effectively be solved in any other way. I can see that most organizations will ban their use except in a few circumstances and then only after they have been extremely well justified. They add a level of complexity that increases the cost of code maintenance and that needs to be weighed up on a cost-benefit basis. The current syntax and semantics for mixins, templates, and CTFE are difficult for the average programmer to understand. Their usage will become common place only for the exceptionally gifted coder and maybe a toy/tool for code obfuscation contests. I will have little or no use for CTFE in my projects. </opinion> -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Mar 01 2007
prev sibling parent reply Reiner Pope <reIGNOREiner.poCAPSpe gmFOOail.cBARom> writes:
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?

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 +/ ... }
 `);

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
Mar 01 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Reiner,

 
 I think they have already proven useful, looking at what people are
 doing with them:

Oh, they are most defiantly useful
 
 - 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.
 

good examples
 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.

But that is one of the most trivial uses of mixins. I would expect that they most of this benefit of mixins can be had while limiting ones self to cases where only a single expression or a simple statement is used: a = mixin(IdentName) + 1; j = mixin(FnName ~ "(arg1, arg2, arg3)"); These are vary useful features and I wouldn't expect them to show any of the "hard to use" issues I referred to.
 
 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 +/ ... }
 `);

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.

Again a good example of where mixins are good.
 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.
 

CTFE is great, No doubt about 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
 

Mostly I wanted to get a discussion going. The issue isn't that mixin+CTFE is bad, it's that often the cost is high and the benefit (over other solutions) is low. What I would like to see is more effort put into thouse other options. I'd say that as a rule of thumb, if you have a mixin that takes more than two or three ~ to build, you'd better think a lot about it. I'd mutch rather work with static foreaches with a few mixins inside it than the same code generated as a string inside of a single mixin. With a few additions and tweaks to static foreach and friends this becomes vary practical. which of these would you rather use? |static foeach(char[] ident; SplitByChar(String, ';')) | writef("%s", mixin(ident)); vs. |mixin(build(String)); | |... // lost of other code | |char[] build(char[] ins) |{ | char[] ret = ""; | foreach(char[] ident; SplitByChar(String, ';')) | ret ~= `writef("%s",` ~ ident ~ `);`; | return ret; |}
Mar 01 2007
parent janderson <askme me.com> writes:
BCS wrote:
 Reply to Reiner,
 
 I think they have already proven useful, looking at what people are
 doing with them:

Oh, they are most defiantly useful
 - 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.

good examples
 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.

But that is one of the most trivial uses of mixins. I would expect that they most of this benefit of mixins can be had while limiting ones self to cases where only a single expression or a simple statement is used: a = mixin(IdentName) + 1; j = mixin(FnName ~ "(arg1, arg2, arg3)"); These are vary useful features and I wouldn't expect them to show any of the "hard to use" issues I referred to.
 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 +/ ... }
 `);

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.

Again a good example of where mixins are good.
 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.

CTFE is great, No doubt about 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

Mostly I wanted to get a discussion going. The issue isn't that mixin+CTFE is bad, it's that often the cost is high and the benefit (over other solutions) is low. What I would like to see is more effort put into thouse other options. I'd say that as a rule of thumb, if you have a mixin that takes more than two or three ~ to build, you'd better think a lot about it. I'd mutch rather work with static foreaches with a few mixins inside it than the same code generated as a string inside of a single mixin. With a few additions and tweaks to static foreach and friends this becomes vary practical. which of these would you rather use? |static foeach(char[] ident; SplitByChar(String, ';')) | writef("%s", mixin(ident)); vs. |mixin(build(String)); | |... // lost of other code | |char[] build(char[] ins) |{ | char[] ret = ""; | foreach(char[] ident; SplitByChar(String, ';')) | ret ~= `writef("%s",` ~ ident ~ `);`; | return ret; |}

You could write a mixin that works like: mixin( sforeach("char[] ident; SplitByChar(String, ';')", "writef("%s", mixin(ident));" )); Still static foreach would/will be nice. If the mixin syntax is improved it could look like: static_foreach("char[] ident; SplitByChar(String, ';')", "writef("%s", mixin(ident));"); or (not sure if this will ever be possible: //With the out syntax Andrie is working on static_foreach("char[] ident; SplitByChar(String, ';')") = "writef("%s", mixin(ident));"; Still not perfect and i agree, static foreachs are a basic construct, so should be part of the language rather then a work around. -Joel
Mar 01 2007