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 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
parent reply 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
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

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.
Mar 01 2007
parent reply 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
Mar 01 2007
parent reply 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.
Mar 01 2007
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 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

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
Mar 01 2007
parent reply 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
Mar 01 2007
parent reply "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
Mar 01 2007
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 next 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?

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

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

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
Mar 01 2007
prev sibling parent reply 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
Mar 02 2007
next sibling parent 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

Mar 02 2007
prev sibling next sibling parent 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.
Mar 02 2007
prev sibling next sibling parent reply 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
Mar 02 2007
parent 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
Mar 02 2007
prev sibling parent reply "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
Mar 03 2007
parent reply 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.
Mar 03 2007
parent reply "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
Mar 03 2007
parent 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.
Mar 04 2007