digitalmars.D.announce - Re: mixin + CTFE, to big a hammer??
- Mikola Lysenko <mclysenk mtu.edu> Mar 02 2007
- Don Clugston <dac nospam.com.au> Mar 02 2007
- BCS <BCS pathlink.com> Mar 02 2007
- janderson <askme me.com> Mar 02 2007
- janderson <askme me.com> Mar 02 2007
- "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> Mar 03 2007
- Mikola Lysenko <mclysenk mtu.edu> Mar 03 2007
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
Don Clugston <dac nospam.com.au> 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
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
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
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
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
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
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
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
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