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

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

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

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

BCS wrote:
>>
>> 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?
>>
> 

Agreed!  Its the same with all code, its about using the technique that works best for the problem at hand.

-Joel

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

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

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