mixin + CTFE, to big a hammer??

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Sat Mar 3 09:05:59 PST 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



More information about the Digitalmars-d-announce mailing list