• BCS (24/24) Mar 01 2007 I have been thinking about the new functionality added by the code mixin...
• kris (4/34) Mar 01 2007 D mixin, in it's current guise, is about equivalent to crack-cocaine.
• Andrei Alexandrescu (See Website For Email) (4/42) Mar 01 2007 ...to unbacked arguments. What is exactly the base for comparing D's
• Hasan Aljudy (2/40) Mar 01 2007 Just give it time, wait for it to mature from experience.
• John Reimer (4/45) Mar 01 2007 ??
• Hasan Aljudy (4/20) Mar 01 2007 um, it's only been around for 2 versions ...
• John Reimer (7/29) Mar 01 2007 Two versions??
• Hasan Aljudy (3/35) Mar 01 2007 well, mixins are 3 versions old ... not to be confused with template
• John Reimer (4/16) Mar 01 2007 Ok, my mistake? Got to love overloaded keywords; suddenly they remove t...
• Andrei Alexandrescu (See Website For Email) (3/48) Mar 01 2007 Patience is a virtue. :o) Besides, it's not like they started real bad.
• John Reimer (6/56) Mar 01 2007 mixin's mixin's mixin's...that's all I'm saying.
• Andrei Alexandrescu (See Website For Email) (4/59) Mar 01 2007 Now we can go back and forth about spellchequers :oD.
• John Reimer (11/23) Mar 01 2007 No, that sort of back and forth is too condescending, and I'm not very
• Derek Parnell (20/24) Mar 01 2007
• Reiner Pope (31/65) Mar 01 2007 I think they have already proven useful, looking at what people are
• BCS (36/81) Mar 01 2007 good examples
• janderson (16/120) Mar 01 2007 You could write a mixin that works like:
• Mikola Lysenko (7/12) Mar 02 2007 At this point I am inclined to agree.
• Don Clugston (8/23) Mar 02 2007 That's a *huge* claim! Have you got examples of this?
• BCS (6/25) Mar 02 2007 There is one thing mixin do vary well from what I've seen is symbol
• janderson (6/23) Mar 02 2007 I strongly disagree, we haven't even realized the full potential of
• janderson (5/31) Mar 02 2007 Oh, and sorry to be so hard on C++ today. I had to take MS C++ out the
• Andrei Alexandrescu (See Website For Email) (10/45) Mar 03 2007 Syntactic manipulation will be in D, too. The thing is, it only works
• Mikola Lysenko (13/25) Mar 03 2007 I guess it wouldn't hurt to wait and see what happens next. I just hope...
• Andrei Alexandrescu (See Website For Email) (6/42) Mar 03 2007 It will be possible once AST manipulation makes it into the language.
• Don Clugston (9/51) Mar 04 2007 Something which I've found is trivial with strings but would not be with...

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?

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

"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

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.

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

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

 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

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.

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

 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

 
 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

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

 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

 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

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

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

"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

 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?

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

Andrei

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

 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?

 
 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

"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?

 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?

 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.  

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

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

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

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?

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

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

 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.

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;
|}

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

 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.

 
 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

Mikola Lysenko <mclysenk mtu.edu> writes:

kris 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

At this point I am inclined to agree.

Initially, I was skeptical about mixins, but I was also intrigued by the
potential meta programming improvements.  One important problem that I do not
know how to solve without mixins is the creation of a set of patterned names. 
As a case study think of the swizzle operators for a vector class.  You need
functions like, x, yx, xyz, zyx, zzy etc.  These functions can be trivially
enumerated by a computer program, which makes them good candidates for
automatic generation.  The mixin statement is enormously helpful in simplifying
this code.

However, there are simply too many hazards with the mixin statement.  Mixins
are not lexically closed - you can very easily mess with names from the
exterior scope.  They suffer many of the problems encountered in the C
preprocessor.  Excessive use of mixins and metaprogramming causes compile times
to balloon to ridiculous lengths, far exceeding even the horrors of C++.  The
net effect is that they undo many of the advantages D once held.

My belief is that the basic problems with mixins result from their reliance on
string manipulation for meta programming - rather than syntactic and structural
concepts.  If we want to create mixin like behaviors (and I think that
ultimately it is a good goal) they need to be presented in the logical context
of a program manipulator - not a text processor.  The current mixin syntax
needs to be aborted before we go any farther down this line of thought.  The
longer it sticks around in the language, the harder it is going to be to kill. 

I vote it gets axed in the next release.

-Mik

Don Clugston <dac nospam.com.au> writes:

Mikola Lysenko wrote:
 kris 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

 

 However, there are simply too many hazards with the mixin statement.  


 Mixins are not lexically closed - you can very easily mess with names from the
exterior scope.  They suffer many of the problems encountered in the C
preprocessor.


 Excessive use of mixins and metaprogramming causes compile times to balloon to
ridiculous lengths, far exceeding even the horrors of C++.

That's a *huge* claim! Have you got examples of this?
I've done some very nasty things with mixins and metaprogramming, and 
I've never seen a compile time that was longer than for a "Hello World" 
windows C++ app!

I'm inclined to agree that the new string mixins are not adequately 
constrained. But I feel the effects on compile times are exaggerated.



   The net effect is that they undo many of the advantages D once held.
 
 My belief is that the basic problems with mixins result from their reliance on
string manipulation for meta programming - rather than syntactic and structural
concepts.  If we want to create mixin like behaviors (and I think that
ultimately it is a good goal) they need to be presented in the logical context
of a program manipulator - not a text processor.  The current mixin syntax
needs to be aborted before we go any farther down this line of thought.  The
longer it sticks around in the language, the harder it is going to be to kill. 
 
 I vote it gets axed in the next release.
 
 -Mik

BCS <BCS pathlink.com> writes:

Mikola Lysenko wrote:
 kris 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

 
 
 At this point I am inclined to agree.
 
 Initially, I was skeptical about mixins, but I was also intrigued by the
potential meta programming improvements.  One important problem that I do not
know how to solve without mixins is the creation of a set of patterned names. 
As a case study think of the swizzle operators for a vector class.  You need
functions like, x, yx, xyz, zyx, zzy etc.  These functions can be trivially
enumerated by a computer program, which makes them good candidates for
automatic generation.  The mixin statement is enormously helpful in simplifying
this code.
 
 However, there are simply too many hazards with the mixin statement.  Mixins
are not lexically closed - you can very easily mess with names from the
exterior scope.  They suffer many of the problems encountered in the C
preprocessor.  Excessive use of mixins and metaprogramming causes compile times
to balloon to ridiculous lengths, far exceeding even the horrors of C++.  The
net effect is that they undo many of the advantages D once held.
 
 My belief is that the basic problems with mixins result from their reliance on
string manipulation for meta programming - rather than syntactic and structural
concepts.  If we want to create mixin like behaviors (and I think that
ultimately it is a good goal) they need to be presented in the logical context
of a program manipulator - not a text processor.  The current mixin syntax
needs to be aborted before we go any farther down this line of thought.  The
longer it sticks around in the language, the harder it is going to be to kill. 
 
 I vote it gets axed in the next release.
 
 -Mik

There is one thing mixin do vary well from what I've seen is symbol 
access. If mixins are cut back, this should stay. Maybe as a 
MixinIdentifier rule in the grammar. I would hazard to say that this 
will get better than 80% of the expressiveness of mixins with much less 
then 20% of the problems.

janderson <askme me.com> writes:

Mikola Lysenko wrote:
 kris 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

 
 At this point I am inclined to agree.
 
 Initially, I was skeptical about mixins, but I was also intrigued by the
potential meta programming improvements.  One important problem that I do not
know how to solve without mixins is the creation of a set of patterned names. 
As a case study think of the swizzle operators for a vector class.  You need
functions like, x, yx, xyz, zyx, zzy etc.  These functions can be trivially
enumerated by a computer program, which makes them good candidates for
automatic generation.  The mixin statement is enormously helpful in simplifying
this code.
 
 However, there are simply too many hazards with the mixin statement.  Mixins
are not lexically closed - you can very easily mess with names from the
exterior scope.  They suffer many of the problems encountered in the C
preprocessor.  Excessive use of mixins and metaprogramming causes compile times
to balloon to ridiculous lengths, far exceeding even the horrors of C++.  The
net effect is that they undo many of the advantages D once held.
 
 My belief is that the basic problems with mixins result from their reliance on
string manipulation for meta programming - rather than syntactic and structural
concepts.  If we want to create mixin like behaviors (and I think that
ultimately it is a good goal) they need to be presented in the logical context
of a program manipulator - not a text processor.  The current mixin syntax
needs to be aborted before we go any farther down this line of thought.  The
longer it sticks around in the language, the harder it is going to be to kill. 
 
 I vote it gets axed in the next release.
 
 -Mik

I strongly disagree, we haven't even realized the full potential of 
mixins yet.  I hope they get ingained in D because people realize they 
are not the same as C++ macros.  They give D the potential to evolve far 
beyond anything that C++ could ever offer.

-Joel

janderson <askme me.com> writes:

janderson wrote:
 Mikola Lysenko wrote:
 kris 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



[snip]

 My belief is that the basic problems with mixins result from their 
 reliance on string manipulation for meta programming - rather than 
 syntactic and structural concepts.  If we want to create mixin like 
 behaviors (and I think that ultimately it is a good goal) they need to 
 be presented in the logical context of a program manipulator - not a 
 text processor.  The current mixin syntax needs to be aborted before 
 we go any farther down this line of thought.  The longer it sticks 
 around in the language, the harder it is going to be to kill.
 I vote it gets axed in the next release.

 -Mik

 
 I strongly disagree, we haven't even realized the full potential of 
 mixins yet.  I hope they get ingained in D because people realize they 
 are not the same as C++ macros.  They give D the potential to evolve far 
 beyond anything that C++ could ever offer.
 
 -Joel
 

Oh, and sorry to be so hard on C++ today.  I had to take MS C++ out the 
back today and show it who was in charge.  Dam that C++ and its limitations.

-Joel

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:

Mikola Lysenko wrote:
 kris 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

 
 At this point I am inclined to agree.
 
 Initially, I was skeptical about mixins, but I was also intrigued by
 the potential meta programming improvements.  One important problem
 that I do not know how to solve without mixins is the creation of a
 set of patterned names.  As a case study think of the swizzle
 operators for a vector class.  You need functions like, x, yx, xyz,
 zyx, zzy etc.  These functions can be trivially enumerated by a
 computer program, which makes them good candidates for automatic
 generation.  The mixin statement is enormously helpful in simplifying
 this code.
 
 However, there are simply too many hazards with the mixin statement.
 Mixins are not lexically closed - you can very easily mess with names
 from the exterior scope.  They suffer many of the problems
 encountered in the C preprocessor.  Excessive use of mixins and
 metaprogramming causes compile times to balloon to ridiculous
 lengths, far exceeding even the horrors of C++.  The net effect is
 that they undo many of the advantages D once held.
 
 My belief is that the basic problems with mixins result from their
 reliance on string manipulation for meta programming - rather than
 syntactic and structural concepts.  If we want to create mixin like
 behaviors (and I think that ultimately it is a good goal) they need
 to be presented in the logical context of a program manipulator - not
 a text processor.  The current mixin syntax needs to be aborted
 before we go any farther down this line of thought.  The longer it
 sticks around in the language, the harder it is going to be to kill.

Syntactic manipulation will be in D, too. The thing is, it only works 
for manipulating D code, not DSLs that don't, and can't, look like D 
(e.g. regex, SQL, automata, etc.). So we will have syntactic (AST-level) 
manipulation for D forms, and string manipulation for non-D DSLs. It's 
all fine. It's understandable that people who _only_ see the string 
manipulation stuff without the vision behind it will immediately point 
to its limitations. So let's give it a few months and you won't be 
disappointed :o).


Andrei

Mikola Lysenko <mclysenk mtu.edu> writes:

Andrei Alexandrescu (See Website For Email) Wrote:
 
 Syntactic manipulation will be in D, too. The thing is, it only works 
 for manipulating D code, not DSLs that don't, and can't, look like D 
 (e.g. regex, SQL, automata, etc.). So we will have syntactic (AST-level) 
 manipulation for D forms, and string manipulation for non-D DSLs. It's 
 all fine. It's understandable that people who _only_ see the string 
 manipulation stuff without the vision behind it will immediately point 
 to its limitations. So let's give it a few months and you won't be 
 disappointed :o).
 
 
 Andrei

I guess it wouldn't hurt to wait and see what happens next.  I just hope that
we don't end up going so far with the experiment, only to find that it is a
dead end.  MixinStatement is a radical departure from the previous meta
programming constructs in D, and it needs to be carefully balanced.  I'm all
for extending and improving the scope of the language, and I expect we will
continue to see new and radical improvements to the compile time code
manipulation facilities.

However, it just feels like string mixins have been uncritically accepted into
the language, with very little thought paid to the consequences - let alone the
possibility that there might even exist better alternatives.  I think the
situation right now calls for some cautious reappraisal of what benefit mixins
add over traditional approaches, and whether there might be a simpler solution.

I think we can get automata, regexes and SQL expressions without adding direct
source code manipulation.  The key limitiation string mixins address is name
generation.  Right now you can't use a template meta program without string
mixins to generate, say a member name for each field in a SQL query.  If we
could figure out some way to solve this problem without direct text
preprocessing, I would personally feel less ill at ease.  I certainly suspect
it is possible.  We could perhaps have something like a name or identifier type
keyword which could work as follows:

void name("foo") (int x)
{
   writefln("x = %s", x);
}

void main()
{
    foo(5);  // prints "x = 5"
}

This would only allow identifiers to be created - not new code.  This prevents
people from trying to mess with program logic using text tools, which is a
practice that has always seemed suspect to me.

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:

Mikola Lysenko wrote:
 Andrei Alexandrescu (See Website For Email) Wrote:
 Syntactic manipulation will be in D, too. The thing is, it only
 works for manipulating D code, not DSLs that don't, and can't, look
 like D (e.g. regex, SQL, automata, etc.). So we will have syntactic
 (AST-level) manipulation for D forms, and string manipulation for
 non-D DSLs. It's all fine. It's understandable that people who
 _only_ see the string manipulation stuff without the vision behind
 it will immediately point to its limitations. So let's give it a
 few months and you won't be disappointed :o).
 
 
 Andrei

 
 I guess it wouldn't hurt to wait and see what happens next.  I just
 hope that we don't end up going so far with the experiment, only to
 find that it is a dead end.  MixinStatement is a radical departure
 from the previous meta programming constructs in D, and it needs to
 be carefully balanced.  I'm all for extending and improving the scope
 of the language, and I expect we will continue to see new and radical
 improvements to the compile time code manipulation facilities.
 
 However, it just feels like string mixins have been uncritically
 accepted into the language, with very little thought paid to the
 consequences - let alone the possibility that there might even exist
 better alternatives.  I think the situation right now calls for some
 cautious reappraisal of what benefit mixins add over traditional
 approaches, and whether there might be a simpler solution.
 
 I think we can get automata, regexes and SQL expressions without
 adding direct source code manipulation.  The key limitiation string
 mixins address is name generation.  Right now you can't use a
 template meta program without string mixins to generate, say a member
 name for each field in a SQL query.  If we could figure out some way
 to solve this problem without direct text preprocessing, I would
 personally feel less ill at ease.  I certainly suspect it is
 possible.

It will be possible once AST manipulation makes it into the language. 
That, not now, will be the proper time for the cautious reappraisal. 
Even then, if certain idioms will remain much easier with strings vs. 
ASTs, there might be significant pressure to keep the feature.


Andrei

Don Clugston <dac nospam.com.au> writes:

Andrei Alexandrescu (See Website For Email) wrote:
 Mikola Lysenko wrote:
 Andrei Alexandrescu (See Website For Email) Wrote:
 Syntactic manipulation will be in D, too. The thing is, it only
 works for manipulating D code, not DSLs that don't, and can't, look
 like D (e.g. regex, SQL, automata, etc.). So we will have syntactic
 (AST-level) manipulation for D forms, and string manipulation for
 non-D DSLs. It's all fine. It's understandable that people who
 _only_ see the string manipulation stuff without the vision behind
 it will immediately point to its limitations. So let's give it a
 few months and you won't be disappointed :o).


 Andrei

 I guess it wouldn't hurt to wait and see what happens next.  I just
 hope that we don't end up going so far with the experiment, only to
 find that it is a dead end.  MixinStatement is a radical departure
 from the previous meta programming constructs in D, and it needs to
 be carefully balanced.  I'm all for extending and improving the scope
 of the language, and I expect we will continue to see new and radical
 improvements to the compile time code manipulation facilities.

 However, it just feels like string mixins have been uncritically
 accepted into the language, with very little thought paid to the
 consequences - let alone the possibility that there might even exist
 better alternatives.  I think the situation right now calls for some
 cautious reappraisal of what benefit mixins add over traditional
 approaches, and whether there might be a simpler solution.

 I think we can get automata, regexes and SQL expressions without
 adding direct source code manipulation.  The key limitiation string
 mixins address is name generation.  Right now you can't use a
 template meta program without string mixins to generate, say a member
 name for each field in a SQL query.  If we could figure out some way
 to solve this problem without direct text preprocessing, I would
 personally feel less ill at ease.  I certainly suspect it is
 possible.

 
 It will be possible once AST manipulation makes it into the language. 
 That, not now, will be the proper time for the cautious reappraisal. 
 Even then, if certain idioms will remain much easier with strings vs. 
 ASTs, there might be significant pressure to keep the feature.

Something which I've found is trivial with strings but would not be with 
ASTs is generating ASM code from a string.

For each element in the string, I want to generate a line of code, with 
one option from inside each of the braces:

{fadd fsub fmul fsubr}{ p} {FLOAT DOUBLE REAL} PTR [{EAX EBX ECX EDX ESI 
EDI EBP} + {1 2 4 8} * {EAX EBX ECX EDX ESI EDI EBP} ];


That is 4*2*3*7*4*7 = 4704 possibilities. It would be nice to have the 
input in the form of an AST, but not the output -- text is perfect.