mixin + CTFE, to big a hammer??

[Don Clugston]

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.