Nick Sabalausky wrote:
> ...
> 
> But yea, that's is still a good point. Although I think it might be better considered part of the more general problem of passing code literals (even though it's as delegates in one case and as strings in the other). For instance, even without any mixins involved, we still have this kind of mess:
> 
> void repeat(int num,
> IForgetTheSyntaxOffhandButLetsJustSayADgThatTakesVoidAndReturnsVoid dg)
> {
>     for(int i; 0..num)
>         dg();
> }
> 
> // Eeew:
> repeat(3,
> {
>     // Stuff here
> });
> 
> 

Yep.  My thoughts exactly.

"Yigal Chripun" <yigal100@gmail.com> wrote in message news:hkjnp8$ms9$1@digitalmars.com...
> On 05/02/2010 23:24, Trass3r wrote:
>>> Proposed:
>>> -----------------------
>>> mixin template foo1 {
>>> const char[] foo1 = "int a;";
>>> }
>>> mixin char[] foo2() {
>>> return "int b;";
>>> }
>>> foo1!();
>>> foo2();
>>> -----------------------
>>>
>>
>> Well, it's a little bit indistinctive, hard to tell if it's a normal
>> function call or a mixin without e.g. using a mixin prefix for the
>> function name (which is nothing better than it is now)
>> But an advantage would be that these functions could be omitted in the
>> final executable since they are only used at compile-time.
>
> IMO, this is a bad idea.
> The most important thing we should get from Nemerle regarding this is the
> much better compilation model and not just the syntax. The syntax idea
> itself is iffy at best especially in the D version.
>

You don't see the current "mixin(foo(fooArgs));" as being iffy syntax?


> To contrast with the Nemerle solution:
> the "function" foo2 above would be put in a separate file and would be
> compiled *once* into a lib.
> Than, at a separate phase,  this lib can be loaded by the compiler and
> used in the client code.
> Also, In Nemerle, foo2 is a regular function which means, unlike D, it
> isn't restricted compared to "regular" functions and for example can call
> stdlib functions like the equivalent of "writef" (no need for special
> pragma(msg, ..) constructs).
>

Absolutely agree with you here. That would be a fairly involved change though, and I suspect D being natively compiled may raise more difficulties and cross-platform issues than it does in Nemerle as Nemerle is VM-only. Would certainly be nice to have that at some point though.

Pelle Månsson:
> Then we just need a cleaner way to "return" things from templates, and we'll be all good.

I am not sure I like the "mixin" keyword used like that, but I like the idea of a better return syntax for templates (and private attribute for names inside templates).

Bye,
bearophile

On 2/5/2010 3:13 AM, Nick Sabalausky wrote:
> Point #1: It's often been noted that string mixin syntax is ugly. Which is a
> bad thing in and of itself, but it also tends to discourage use of string
> mixins despite their high degree of usefulness.
>
> Point #2: It seems to me that the vast majority of templates and functions
> are either designed specifically to be used as a string mixin or
> specifically designed to be used as something other than a string mixin.
> Only rarely does a single template or function seem to be particularly
> useful both ways.
>
> Proposal:
> So how about taking a cue from Nemerle:
>
> Current:
> -----------------------
> template foo1 {
>      const char[] foo1 = "int a;";
> }
> char[] foo2() {
>      return "int b;";
> }
> mixin(foo1!());
> mixin(foo2());
> -----------------------
>
> Proposed:
> -----------------------
> mixin template foo1 {
>      const char[] foo1 = "int a;";
> }
> mixin char[] foo2() {
>      return "int b;";
> }
> foo1!();
> foo2();
> -----------------------
>
> One consequence of this worth noting is that the current string-mixin could
> be trivially recreated under the proposed syntax:
>
> -----------------------
> mixin char[] mixinString(char[] str) {
>      return str;
> }
> mixinString("int a;");
> -----------------------
>
> Maybe someone not as half-asleep as I currently am can point out a
> clean/clever way to retrieve the string value of such a template/function
> without actually mixing it in, to cover the occasional cases where that
> actually would be useful.
>
>

I like having nicer mixing.  My proposal was to allow templates to take a string.  That would make the mixin both visible but still make it look neat.

void mixinString(string T)()
{
	mixin(func(T));
}

On the call site...

mixinString!("int a;");

The extra ! indicates that the string must be compile time constant because its going into a template.

"Joel Anderson" <ask@me.com> wrote in message news:hl1cdn$2fkn$1@digitalmars.com...
>
> I like having nicer mixing.  My proposal was to allow templates to take a string.  That would make the mixin both visible but still make it look neat.
>
> void mixinString(string T)()
> {
> mixin(func(T));
> }
>
> On the call site...
>
> mixinString!("int a;");
>
> The extra ! indicates that the string must be compile time constant because its going into a template.

While that wouldn't be my preferred solution, I could certainly live with that and be very happy.