www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - change mixins

reply Walter Bright <newshound1 digitalmars.com> writes:
Right now, mixins are defined and used as:

    template foo(T) { declarations... }

    mixin foo!(int) handle;

The proposal is to switch it around:

    mixin template foo(T) { declarations... }

    foo!(int) handle;

to follow the notion that mixin templates are very different from 
regular templates, and that should be reflected in their definition 
rather than use.

What do you think?
Feb 14 2010
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Feb 14, 2010 at 01:31:29PM -0800, Walter Bright wrote:
 The proposal is to switch it around:
 
    mixin template foo(T) { declarations... }
 
    foo!(int) handle;

What about: template foo() { int a; } mixin foo!(); a = 0; ? Will the change still let you use the mixed in template without a name? It would look a little weird: struct A { foo!(); }
 What do you think?

I'm on the fence. The difference seems to me that it applies in both places - definition and use. Maybe the mixin keyword should be required in both places? -- Adam D. Ruppe http://arsdnet.net
Feb 14 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-14 16:31:29 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Right now, mixins are defined and used as:
 
     template foo(T) { declarations... }
 
     mixin foo!(int) handle;
 
 The proposal is to switch it around:
 
     mixin template foo(T) { declarations... }
 
     foo!(int) handle;
 
 to follow the notion that mixin templates are very different from 
 regular templates, and that should be reflected in their definition 
 rather than use.
 
 What do you think?

Me likes it. :-) To me it was confusing at first that templates could be used both way. I've rarely seen a template that is meant to be and not to be mixed-in at the same time, so this will make things clearer (and also enforce) how a particular template is meant to be used. And I won't say no to reducing the clutter at the usage point. I only hope you can still use it without the 'handle' part. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 14 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 I only hope you can still use it without the 'handle' part. :-)

Yes, it'll still be usable that way.
Feb 14 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hl9q47$2kjr$1 digitalmars.com...
 Right now, mixins are defined and used as:

    template foo(T) { declarations... }

    mixin foo!(int) handle;

 The proposal is to switch it around:

    mixin template foo(T) { declarations... }

    foo!(int) handle;

 to follow the notion that mixin templates are very different from regular 
 templates, and that should be reflected in their definition rather than 
 use.

 What do you think?

I don't have an opinion on template mixins, as I've never really used them, but I *definitely* want that for string mixins of both the template-generated and ctfe-generated varieties.
Feb 14 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.
 

Why? I don't see any reason aside from documentation to do it. -- <IXOYE><
Feb 14 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.

Why? I don't see any reason aside from documentation to do it.

Well, for one thing, not having it forces any code using my custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!
Feb 14 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Nick,

 "BCS" <none anon.com> wrote in message
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 
 Hello Nick,
 
 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.
 


custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

1) I don't see a lot of difference (I see a /little/ difference), the extra mixin() doesn't get in the way of /me/ seeing what going on. 2) I'd prefer more general solution, like being able to extract the original string from a lazy parameter or pass expressions as alias: void deferAssert!(alias exp, string message) { if(!exp) // deferAssert gets instanced as a local function (or gets a hidden delegate parameter or wherever) writef("%s failed: %s\n", exp.stringof, message); } 3) anything that passes code around as strings looks like a hack (sometimes necessary) to me and has so many downside relating to tools (particularly syntax highlighters) that the mixin() gets lost in the noise. void deferAssert!(foo == 3 || foo > 5, "foo is bad"); // ...ahhh, now I can really see what the hell's going on, and so can my tools! -- <IXOYE><
Feb 14 2010
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff104068cc7bdef4aa51da news.digitalmars.com...
 Hello Nick,

 "BCS" <none anon.com> wrote in message
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...

 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

1) I don't see a lot of difference (I see a /little/ difference), the extra mixin() doesn't get in the way of /me/ seeing what going on.

Different people, I guess.
 2) I'd prefer more general solution, like being able to extract the 
 original string from a lazy parameter or pass expressions as alias:

 void deferAssert!(alias exp, string message)
 {
     if(!exp) // deferAssert gets instanced as a local function (or gets a 
 hidden delegate parameter or wherever)
        writef("%s failed: %s\n", exp.stringof, message);
 }

 3) anything that passes code around as strings looks like a hack 
 (sometimes necessary) to me and has so many downside relating to tools 
 (particularly syntax highlighters) that the mixin() gets lost in the 
 noise.

 void deferAssert!(foo == 3 || foo > 5, "foo is bad"); // ...ahhh, now I 
 can really see what the hell's going on, and so can my tools!

Good points, although for now what we have are mixins, and switching the mixin label to the declaration-side, I suspect, is a simpler change. And as far as the tools seeing it, D2 has q{} strings.
Feb 14 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message 
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


Well, for one thing, not having it forces any code using my custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

Now come on, the second one also looks ugly and confusing as hell. Sure, mixins are powerful (and sometimes I couldn't avoid using them myself), but really, I never understood what people like about writing code into STRING LITERALS. At least with the mixin you see in which context the code will be compiled (though only roughly), unlike the second line of code, which just obfuscates the code further. And the only reason why you need this for your asserts is that you want to get the location of the failing assert. That's mostly because of D's lacking backtrace abilities of D (defAssert just had to resolve the location of the previous stackframe). On the other hand, I heard D2 has an ugly trick to get the caller's location: dd ddd void defAssert(bool condition, cha^Wstring message, string file = __FILE__, int line = __LINE__); defAssert(condition, message);
Feb 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:hlbg22$6fb$1 digitalmars.com...
 Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message 
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


Well, for one thing, not having it forces any code using my custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

Now come on, the second one also looks ugly and confusing as hell. Sure, mixins are powerful (and sometimes I couldn't avoid using them myself), but really, I never understood what people like about writing code into STRING LITERALS.

I certainly agree with that, but until we get AST macros or at least some movement in that direction, this sort of thing is often the best we can do.
 At least with the mixin you see in which context the code will be compiled 
 (though only roughly), unlike the second line of code, which just 
 obfuscates the code further.

I can understand that. Not sure I agree, but I can certainly see what you mean.
 And the only reason why you need this for your asserts is that you want to 
 get the location of the failing assert. That's mostly because of D's 
 lacking backtrace abilities of D (defAssert just had to resolve the 
 location of the previous stackframe).

 On the other hand, I heard D2 has an ugly trick to get the caller's 
 location:
 dd ddd
 void defAssert(bool condition, cha^Wstring message, string file = 
 __FILE__, int line = __LINE__);

 defAssert(condition, message);

Maybe it's not clear from that code, but there's more to it than that: One of the main ideas behind that lib (aside from unittests that don't exit on the first failure), is to get detailed unittest diagnostics that are comparable to what one gets from something like JUnit/NUnit, but with something much closer to actual syntax than obfuscated crap like: Assert.AreEqual(x, y); // And it just gets worse from here... // Actual examples from NUnit's documentation Assert.That( myString, Is.EqualTo("Hello") ); Assert.That(5, Is.InstanceOfType(typeof(string))); Assert.That( 5, Is.Not.SubsetOf( iarray ) ); Unittesting frameworks have garbage fake-syntax like that so that (without making the user violate DRY and state every assert in both real code for the first param and then again in plain english in the second param), it can respond to a failure by providing detailed information like: foo.cs(17): Wrong value in variable "bar". Was 3, but expected greater than 5. Instead of: foo.cs(17): Assert failure: "Wrong value" But with D's string mixins and metaprogramming, we can get diagnostics that are nearly as good, but with syntax that differs from normal expressions in little more than just sticking a few quotes around things. Not perfect, granted, but one hell of an improvement.
Feb 15 2010
parent grauzone <none example.net> writes:
Nick Sabalausky wrote:
 "grauzone" <none example.net> wrote in message 
 news:hlbg22$6fb$1 digitalmars.com...
 Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message 
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

mixins are powerful (and sometimes I couldn't avoid using them myself), but really, I never understood what people like about writing code into STRING LITERALS.

I certainly agree with that, but until we get AST macros or at least some movement in that direction, this sort of thing is often the best we can do.

You're discussing here about syntax proposals to make string mixins better readable. IMHO they should stay as ugly as they are to discourage using them. (Although Andrei is already fearless enough to use advertise string mixins as a standard way to overcome the still-too-ugly syntax and bad compiler optimizer support for passing delegates; the std.algorithm documentation still passes functions as string, and his book will probably too.) Before discussing syntax improvements, you really should solve some basic problems of string mixins: for example, solve the issue that string mixins may be compiled in a completely foreign environment, as opposed to the environment where the user wrote them. (When I understand correctly, this is the "hygienic" aspect of LISP macros.) My favorite example is still this: void helper(int x) { /+ whatever here is +/ return x; } map!"helper(a)+1"(range) Also, why should the "function" passed by the user be able to access the internals of std.algorithm? Building the function with a string is not that bad (seriously ugly but works). What I've seen from early macro proposals didn't sound that great either. But what's really needed is solving the symbol lookup problems above. D macros were supposed to be hygienic, solving this particular problem. Actually, I wouldn't be too surprised if one day, Walter announced that D won't get macros, because they tried to figure out how they should work and came to the conclusion that macros suck. That's how things work in D Land, right?
 Maybe it's not clear from that code, but there's more to it than that:
 
 One of the main ideas behind that lib (aside from unittests that don't exit 
 on the first failure), is to get detailed unittest diagnostics that are 
 comparable to what one gets from something like JUnit/NUnit, but with 
 something much closer to actual syntax than obfuscated crap like:
 
 Assert.AreEqual(x, y); // And it just gets worse from here...
 
 // Actual examples from NUnit's documentation
 Assert.That( myString, Is.EqualTo("Hello") );
 Assert.That(5, Is.InstanceOfType(typeof(string)));
 Assert.That( 5, Is.Not.SubsetOf( iarray ) );
 
 Unittesting frameworks have garbage fake-syntax like that so that (without 
 making the user violate DRY and state every assert in both real code for the 
 first param and then again in plain english in the second param), it can 
 respond to a failure by providing detailed information like:
 
 foo.cs(17): Wrong value in variable "bar". Was 3, but expected greater than 
 5.
 
 Instead of:
 
 foo.cs(17): Assert failure: "Wrong value"

OK. Though I find it ironic that good old C with its dumb text based macro processor can already do half of the job by stringifying the expression passed to the assert macro. Yeah, it can't tell you the variable values. (But how would you do this in D?) And the example about logging... sometimes it looks like people are just looking for a problem to apply their solution.
 But with D's string mixins and metaprogramming, we can get diagnostics that 
 are nearly as good, but with syntax that differs from normal expressions in 
 little more than just sticking a few quotes around things. Not perfect, 
 granted, but one hell of an improvement.

Yes, otherwise I'd vote for completely removing string mixins from the language.
Feb 16 2010
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:

 Mon, 15 Feb 2010 01:08:38 -0500, Nick Sabalausky wrote:
 
 "BCS" <none anon.com> wrote in message
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

To me it's not clear why you just can't do this with higher order functions. For instance in Scala I would just write: object MyUnitTestFramework { def deferAssert(pred: => Boolean, msg: String) { if (pred) println(msg) } } or whatever functionality you might want. Passing the predicate by name does not force evaluation yet on the call site.

You can do the same in D of course, lambda's and closures are available after all. But with a string mixin you can print the line / file info (at least you need this for D1, in D2 there is another way) AND the source code of the expression itself. That is quite useful for unittesting. Can you do that in scala?
Feb 15 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 15 Feb 2010 01:08:38 -0500, Nick Sabalausky wrote:

 "BCS" <none anon.com> wrote in message
 news:a6268ff103d38cc7ba48d6fabda news.digitalmars.com...
 Hello Nick,

 I *definitely* want that for string mixins of both the
 template-generated and ctfe-generated varieties.


custom-assert library to look like this crap... mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad")); ...which understandably no one wants to touch and I *absolutely* don't blame them one bit. Compare that to this... deferAssert!(`foo == 3 || foo > 5`, "foo is bad"); ...ahhh, now I can actually see what the hell's going on!

To me it's not clear why you just can't do this with higher order functions. For instance in Scala I would just write: object MyUnitTestFramework { def deferAssert(pred: => Boolean, msg: String) { if (pred) println(msg) } } or whatever functionality you might want. Passing the predicate by name does not force evaluation yet on the call site.
Feb 15 2010
prev sibling parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 21:08:19 +0100, grauzone wrote:

 You're discussing here about syntax proposals to make string mixins
 better readable. IMHO they should stay as ugly as they are to discourage
 using them. (Although Andrei is already fearless enough to use advertise
 string mixins as a standard way to overcome the still-too-ugly syntax
 and bad compiler optimizer support for passing delegates; the
 std.algorithm documentation still passes functions as string, and his
 book will probably too.)
 
 Before discussing syntax improvements, you really should solve some
 basic problems of string mixins: for example, solve the issue that
 string mixins may be compiled in a completely foreign environment, as
 opposed to the environment where the user wrote them. (When I understand
 correctly, this is the "hygienic" aspect of LISP macros.)
 
 My favorite example is still this:
 
 void helper(int x) { /+ whatever here is +/ return x; }
 map!"helper(a)+1"(range)
 
 Also, why should the "function" passed by the user be able to access the
 internals of std.algorithm?

Agreed, lambdas should be used instead of string macros in some cases.
 
 Building the function with a string is not that bad (seriously ugly but
 works). What I've seen from early macro proposals didn't sound that
 great either. But what's really needed is solving the symbol lookup
 problems above. D macros were supposed to be hygienic, solving this
 particular problem.
 
 Actually, I wouldn't be too surprised if one day, Walter announced that
 D won't get macros, because they tried to figure out how they should
 work and came to the conclusion that macros suck. That's how things work
 in D Land, right?

My guess is that macros are getting there eventually, but atm D design team lacks manpower and D2 release is too soon so they can't really introduce a half-broken macro system now.
Feb 16 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

 What do you think?

I support the change, expect that I believe mixing in the mixin template should involve the "mixin" keyword. In fact, I have proposed exactly the same more that a year ago. Here is a quote: Usually templates and mixin templates are completely different, mixin'ing usual template or instantiating template that is intended for being mixed-in makes no sense in the majority of real cases. Moreover, I would prefer to separate these terms and so their syntax: mixin template Bar { private int value; public int getValue() { return value; } } class Foo { mixin Bar!(); } int bar = Bar!().getValue(); // Error: can't instantiate mixin template template Square(alias x) { private enum temp = x * x; public enum Square = temp; } class Test { mixin Square!(42); // Error: can't mixin non-mixin template }
Feb 14 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from 
 regular templates, and that should be reflected in their definition 
 rather than use.

 What do you think?

I support the change, expect that I believe mixing in the mixin template should involve the "mixin" keyword.

The hope with the proposed change is to leverage existing mixin implementation into a solid and useful facility that could actually obviate the need for macros. I reckon there is a lot of value in the current mixin template idea, but it's just packaged the wrong way. Requiring mixin on the call side (something that many have complained about) would, in my opinion, keep the feature packaged the wrong way. As an example of where we want to take this, consider an interpolation facility. The expression: interp!"a = $a and b = $b\n" expands into: "a = ", a, " and b = ", b, "\n" which you can writeln, pass to text or whatnot. Andrei
Feb 14 2010
parent reply grauzone <none example.net> writes:
Steven Schveighoffer wrote:
 On Sun, 14 Feb 2010 18:28:38 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Denis Koroskin wrote:
 On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from 
 regular templates, and that should be reflected in their definition 
 rather than use.

 What do you think?

template should involve the "mixin" keyword.

The hope with the proposed change is to leverage existing mixin implementation into a solid and useful facility that could actually obviate the need for macros. I reckon there is a lot of value in the current mixin template idea, but it's just packaged the wrong way. Requiring mixin on the call side (something that many have complained about) would, in my opinion, keep the feature packaged the wrong way. As an example of where we want to take this, consider an interpolation facility. The expression: interp!"a = $a and b = $b\n" expands into: "a = ", a, " and b = ", b, "\n" which you can writeln, pass to text or whatnot.

could you use this to avoid lazy arguments for logging? One of the huge uses I see for a macro is to do logging (and things like assert) without requiring lazy evaluation. For example, in Tango from what I remember, logging is done like this: log.logInfo("created object " ~ obj.toString); where you may not want to execute obj.toString unless the info log is enabled. Solving this currently in Tango is done via lazy arguments. However, this means making temporary functions, passing delegates, etc. It's much more straightforward and generates smaller code to do: if(log.infoEnabled) log.log("created object " ~ obj.toString); This is the solution in log4j and it's plethora of clones. A much better solution IMO is to use a macro where logInfo is a macro that inserts the if statement at the call site. You can do this with mixins, but clearly it is not as attractive, plus since you are invariably dealing with strings in logging, you have to escape them when doing the mixin. It would be awesome if macros can solve this problem by just making mixins easier to use. i.e. class Log { macro logInfo(s) mixin("if(this.infoEnabled) this.log(" ~ s ~ ")"); }

Eh. How about class Log { void logInfo(char[] format, ...) { if (infoEnabled) std.format.doFormat(&log, _arguments, _argptr); } } Log.logInfo("created object %s", obj); Doesn't require new features, doesn't require lazy, doesn't require thousands of templates, works if Log is an interface. Granted, even if logging is disabled, the compiler will push the arguments on the stack and call logInfo().
Feb 15 2010
parent reply grauzone <none example.net> writes:
retard wrote:
 Granted, even if logging is disabled, the compiler will push the
 arguments on the stack and call logInfo().

This is a case where a JIT compiler wins. The code runs equally fast without the call at all and with logging turned off (dynamically). In languages like D, the like has to be statically turned off unless compilers have any new dynamic optimizations.

Can the JIT really do this optimization? It sounds as if it'd detect that the variable never changes, and generate code with that fixed value.
Feb 16 2010
parent grauzone <none example.net> writes:
retard wrote:
 Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:
 
 retard wrote:
 Granted, even if logging is disabled, the compiler will push the
 arguments on the stack and call logInfo().

without the call at all and with logging turned off (dynamically). In languages like D, the like has to be statically turned off unless compilers have any new dynamic optimizations.

that the variable never changes, and generate code with that fixed value.

It sure can recompile the code assuming that the logging policy doesn't change that often - in case it does change often switching the code might have larger overhead than testing the condition. In real life you would probably start the program with either logging on or off. With JIT compiled languages, the decision can be postponed to runtime, in D it

We're talking about a globally accessible runtime variable here, right? Not just a local variable that was detected to be constant. What I don't understand is: how does the VM efficiently detect, that the value never changes, and that generating code for that fixed value may be worthwhile? It is well possible in theory: the VM could just set up write barriers to detect changes to a variable, and then recompile speed critical code that uses the variable. But it had to collect statistics about all accessed variables, and then decide to recompile the code. Both collecting and analyzing statistics and recompiling code takes time, and it has to be fast enough to not slow down the program even if there are "misses" (e.g. unexpected variable writes). Other typical JIT optimizations sound easy compared to this case. I'd be really interested how this works out.
 probably has to be done on compile time and provide two binaries, if both 
 logging and efficiency are required options. I can post a rather short 
 test case in Java/Scala here, if you insist.

Feb 16 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 15 Feb 2010 02:28:38 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

 What do you think?

template should involve the "mixin" keyword.

The hope with the proposed change is to leverage existing mixin implementation into a solid and useful facility that could actually obviate the need for macros. I reckon there is a lot of value in the current mixin template idea, but it's just packaged the wrong way. Requiring mixin on the call side (something that many have complained about) would, in my opinion, keep the feature packaged the wrong way. As an example of where we want to take this, consider an interpolation facility. The expression: interp!"a = $a and b = $b\n" expands into: "a = ", a, " and b = ", b, "\n" which you can writeln, pass to text or whatnot. Andrei

Point taken. I agree this makes code look cleaner.
Feb 14 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 14 Feb 2010 18:28:38 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

 What do you think?

template should involve the "mixin" keyword.

The hope with the proposed change is to leverage existing mixin implementation into a solid and useful facility that could actually obviate the need for macros. I reckon there is a lot of value in the current mixin template idea, but it's just packaged the wrong way. Requiring mixin on the call side (something that many have complained about) would, in my opinion, keep the feature packaged the wrong way. As an example of where we want to take this, consider an interpolation facility. The expression: interp!"a = $a and b = $b\n" expands into: "a = ", a, " and b = ", b, "\n" which you can writeln, pass to text or whatnot.

could you use this to avoid lazy arguments for logging? One of the huge uses I see for a macro is to do logging (and things like assert) without requiring lazy evaluation. For example, in Tango from what I remember, logging is done like this: log.logInfo("created object " ~ obj.toString); where you may not want to execute obj.toString unless the info log is enabled. Solving this currently in Tango is done via lazy arguments. However, this means making temporary functions, passing delegates, etc. It's much more straightforward and generates smaller code to do: if(log.infoEnabled) log.log("created object " ~ obj.toString); This is the solution in log4j and it's plethora of clones. A much better solution IMO is to use a macro where logInfo is a macro that inserts the if statement at the call site. You can do this with mixins, but clearly it is not as attractive, plus since you are invariably dealing with strings in logging, you have to escape them when doing the mixin. It would be awesome if macros can solve this problem by just making mixins easier to use. i.e. class Log { macro logInfo(s) mixin("if(this.infoEnabled) this.log(" ~ s ~ ")"); } and have the compiler take care of the "this" substitution. Obviously this isn't a fully fleshed out idea, but I think abandoning the possibility of doing macros because you found an easy way to make mixins slightly better leaves out a lot of potential uses for macros. -Steve
Feb 15 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 15 Feb 2010 18:46:52 -0500, grauzone <none example.net> wrote:

 Steven Schveighoffer wrote:
 On Sun, 14 Feb 2010 18:28:38 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

 What do you think?

template should involve the "mixin" keyword.

The hope with the proposed change is to leverage existing mixin implementation into a solid and useful facility that could actually obviate the need for macros. I reckon there is a lot of value in the current mixin template idea, but it's just packaged the wrong way. Requiring mixin on the call side (something that many have complained about) would, in my opinion, keep the feature packaged the wrong way. As an example of where we want to take this, consider an interpolation facility. The expression: interp!"a = $a and b = $b\n" expands into: "a = ", a, " and b = ", b, "\n" which you can writeln, pass to text or whatnot.

One of the huge uses I see for a macro is to do logging (and things like assert) without requiring lazy evaluation. For example, in Tango from what I remember, logging is done like this: log.logInfo("created object " ~ obj.toString); where you may not want to execute obj.toString unless the info log is enabled. Solving this currently in Tango is done via lazy arguments. However, this means making temporary functions, passing delegates, etc. It's much more straightforward and generates smaller code to do: if(log.infoEnabled) log.log("created object " ~ obj.toString); This is the solution in log4j and it's plethora of clones. A much better solution IMO is to use a macro where logInfo is a macro that inserts the if statement at the call site. You can do this with mixins, but clearly it is not as attractive, plus since you are invariably dealing with strings in logging, you have to escape them when doing the mixin. It would be awesome if macros can solve this problem by just making mixins easier to use. i.e. class Log { macro logInfo(s) mixin("if(this.infoEnabled) this.log(" ~ s ~ ")"); }

Eh. How about class Log { void logInfo(char[] format, ...) { if (infoEnabled) std.format.doFormat(&log, _arguments, _argptr); } } Log.logInfo("created object %s", obj); Doesn't require new features, doesn't require lazy, doesn't require thousands of templates, works if Log is an interface.

That solves my example, yes. But it does not solve the generic case. If toString isn't the complex/time consuming part, then the thing that is toString'd will still be computed. -Steve
Feb 15 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 00:46:52 +0100, grauzone wrote:

 How about
 
 class Log
 {
 	void logInfo(char[] format, ...) {
 		if (infoEnabled)
 			std.format.doFormat(&log, _arguments, _argptr);
    	}
 }
 
 Log.logInfo("created object %s", obj);
 
 
 Doesn't require new features, doesn't require lazy, doesn't require
 thousands of templates, works if Log is an interface.
 
 Granted, even if logging is disabled, the compiler will push the
 arguments on the stack and call logInfo().

This is a case where a JIT compiler wins. The code runs equally fast without the call at all and with logging turned off (dynamically). In languages like D, the like has to be statically turned off unless compilers have any new dynamic optimizations.
Feb 16 2010
prev sibling parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:

 retard wrote:
 Granted, even if logging is disabled, the compiler will push the
 arguments on the stack and call logInfo().

This is a case where a JIT compiler wins. The code runs equally fast without the call at all and with logging turned off (dynamically). In languages like D, the like has to be statically turned off unless compilers have any new dynamic optimizations.

Can the JIT really do this optimization? It sounds as if it'd detect that the variable never changes, and generate code with that fixed value.

It sure can recompile the code assuming that the logging policy doesn't change that often - in case it does change often switching the code might have larger overhead than testing the condition. In real life you would probably start the program with either logging on or off. With JIT compiled languages, the decision can be postponed to runtime, in D it probably has to be done on compile time and provide two binaries, if both logging and efficiency are required options. I can post a rather short test case in Java/Scala here, if you insist.
Feb 16 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-14 16:31:29 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Right now, mixins are defined and used as:
 
     template foo(T) { declarations... }
 
     mixin foo!(int) handle;
 
 The proposal is to switch it around:
 
     mixin template foo(T) { declarations... }
 
     foo!(int) handle;
 
 to follow the notion that mixin templates are very different from 
 regular templates, and that should be reflected in their definition 
 rather than use.
 
 What do you think?

There's one thing I'd wish a lot to be able to do in a template mixin: being able to get the name of the 'handle' part from inside the template. I'm wondering, if you implement this change, could you add syntax to get that? I was thinking of "mixin.stringof", and it'd be usable like this: mixin template Value(int) { int value; void write() { writeln("Value '", mixin.stringof, "' is ", value); } } class A { Value!int test; } A a = new A; a.hello.write(); // writes "Value 'test' is 0" -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 14 2010
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 14, 2010 at 1:31 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Right now, mixins are defined and used as:

 =A0 template foo(T) { declarations... }

 =A0 mixin foo!(int) handle;

 The proposal is to switch it around:

 =A0 mixin template foo(T) { declarations... }

 =A0 foo!(int) handle;

 to follow the notion that mixin templates are very different from regular
 templates, and that should be reflected in their definition rather than u=

I have had one use for templates that are both stand-alone and mixed in -- that's collections of aliases and utility functions based on a particular type. For instance imagine you have a Mesh type and a template that teases apart the different subtypes it uses (VectorT, NormalT, floatT, VertexT, ColorT, etc). That's useful as a standalone: MeshTypes!(MyMeshT).VectorT But also mixed into some class that deals with meshes class MeshManipulator(MeshT) { mixin MeshTypes!(MeshT); ... } I also had a collection of geometry utility functions in a template (templated on the point type) which I would both use directly, and mix in to classes that did a lot of geometry. I guess that seems a little wasteful (creating instantiations of these same functions in multiple classes), but it was darn convenient. pointSegmentDistance(p,a,b) is much nicer than GeomUtils!(PointT).pointSegmentDistance(p,a,b). You can alias GeomUtils!(PointT) to something shorter, but aside from 'mixin' there's no way to import that templated namespace into another namespace. --bb
Feb 14 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-14 18:12:45 -0500, Bill Baxter <wbaxter gmail.com> said:

 That's useful as a standalone:
    MeshTypes!(MyMeshT).VectorT
 But also mixed into some class that deals with meshes
    class MeshManipulator(MeshT) {  mixin MeshTypes!(MeshT); ... }

Can't you use alias MeshTypes!(MyMeshT) this; now with D2? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 14 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I have had one use for templates that are both stand-alone and mixed
 in -- that's collections of aliases and utility functions based on a
 particular type.

You'll possibly run into a serious problem doing that. With templates, the name lookup is done in the scope of the template definition. With mixin templates, name lookup is done in the scope of the template instantiation.
Feb 14 2010
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Walter Bright wrote:
 Right now, mixins are defined and used as:
 
    template foo(T) { declarations... }
 
    mixin foo!(int) handle;
 
 The proposal is to switch it around:
 
    mixin template foo(T) { declarations... }
 
    foo!(int) handle;
 
 to follow the notion that mixin templates are very different from
 regular templates, and that should be reflected in their definition
 rather than use.
 
 What do you think?

This was discussed once: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Template_mixins_Why_is_the_decision_to_mixin_made_at_the_call_site_17477.html At some level I am OK with this. Too me though, it is more important to be able to omit the "mixin" keyword at invocation than it is to dictate it at declaration. In fact, even that isn't so bad. I don't think mixin templates are really that much of an issue. String mixins are. The lack of being able to place D statements into the mixin templates makes them considerably less useful than string mixins. You can perform arbitrary (runtime) code with mixin templates of course, it's just that you have to spawn an enormous number of dummy declarations to make the wheels turn. For an example, see this monstrosity I made long ago: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=47471&header That may have been before string mixins. So I could see moving mixin from use to declaration. I just don't think I would care about it nearly as much as this: http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Dedicated-string-mixin_templates_functions_105748.html Note that with good string mixin syntax, we could have something like int foo = 42; string bar = "answer"; writefln("The $bar is $foo."); // Prints "The answer is 42." OR writefln#("The $bar is $foo."); // Prints "The answer is 42." // Use this syntax if it needs to be greppable. // Nothing says it has to be # either. The other usecase for that which came up recently was sql queries. I suppose my point in all of this is that you can probably make much better gains by messing with mixin syntax in a different way.
Feb 14 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 The proposal is to switch it around:

 What do you think?

Off the cuff, I'm fine with needing the mixin on the template but don't drop it from the use end. Without the 'mixin' it's not visually distinct enough. On the other hand, your way would make this trick cleaner: http://arrayboundserror.blogspot.com/2009/03/i-just-got-free-25-speedup-in-my-code.html -- <IXOYE><
Feb 14 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff103d08cc7ba4f39a307e news.digitalmars.com...
 Hello Walter,

 The proposal is to switch it around:

 What do you think?

Off the cuff, I'm fine with needing the mixin on the template but don't drop it from the use end. Without the 'mixin' it's not visually distinct enough.

Not to be contentious, but why do you consider it important for it to be visually distinct?
Feb 14 2010
parent BCS <none anon.com> writes:
Hello Nick,

 "BCS" <none anon.com> wrote in message
 news:a6268ff103d08cc7ba4f39a307e news.digitalmars.com...
 
 Hello Walter,
 
 The proposal is to switch it around:
 

 What do you think?
 

don't drop it from the use end. Without the 'mixin' it's not visually distinct enough.

be visually distinct?

Given that these are imported from "somewhere" class list(T) { ... } template toMixin(T) { ... } How do I tell these apart (aside from by the names)? list!(int) intList; toMixin!(int) asInt; They do very different things and I can think of more time where I'd want to know what each is than where I'd want to hide it. -- <IXOYE><
Feb 14 2010
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 14, 2010 at 3:39 PM, Michel Fortin
<michel.fortin michelf.com> wrote:
 On 2010-02-14 18:12:45 -0500, Bill Baxter <wbaxter gmail.com> said:

 That's useful as a standalone:
 =A0 MeshTypes!(MyMeshT).VectorT
 But also mixed into some class that deals with meshes
 =A0 class MeshManipulator(MeshT) { =A0mixin MeshTypes!(MeshT); ... }

Can't you use =A0 =A0 =A0 =A0alias MeshTypes!(MyMeshT) this; now with D2?

Maybe. But I was thinking that only worked for one type per class. If so, then 'alias this' is a limited resource I wouldn't generally want to waste on that. --bb
Feb 14 2010
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Feb 14, 2010 at 4:39 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 I have had one use for templates that are both stand-alone and mixed
 in -- that's collections of aliases and utility functions based on a
 particular type.

You'll possibly run into a serious problem doing that. With templates, the name lookup is done in the scope of the template definition. With mixin templates, name lookup is done in the scope of the template instantiation.

Hmm, well it never caused a problem in my case. The contents of the templates were mostly self contained and didn't refer to much of anything from the outside world. Anyway, I'm not saying this is a must-have capability, just providing a data point that someone has actually used the functionality. If there's something super cool that can be enabled by making the change, then that probably wins. --bb
Feb 14 2010
prev sibling next sibling parent reply sybrandy <sybrandy gmail.com> writes:
On 02/14/2010 04:31 PM, Walter Bright wrote:
 Right now, mixins are defined and used as:

 template foo(T) { declarations... }

 mixin foo!(int) handle;

 The proposal is to switch it around:

 mixin template foo(T) { declarations... }

 foo!(int) handle;

 to follow the notion that mixin templates are very different from
 regular templates, and that should be reflected in their definition
 rather than use.

 What do you think?

Personally, I like it. I wrote my first batch of code using mixins a couple weeks ago and I hate the fact you have to specify "mixin" every time you use the template. To me, this seemed very annoying, especially when I was trying to implement something in a way where depending on a compiler switch, the functionality would or would not be there. To me, the proposal makes it look more like a normal function, which means less typing and clutter in the code. Btw: I was doing this for a logging library that I was working on. As one can deduce, when you have a lot of logging statements in your code, being able to leverage a mixin to cleanly enable/disable the functionality in conjunction with a compiler switch can have an impact on performance. Casey
Feb 14 2010
parent reply BCS <none anon.com> writes:
Hello sybrandy,

 Btw: I was doing this for a logging library that I was working on.  As
 one can deduce, when you have a lot of logging statements in your
 code, being able to leverage a mixin to cleanly enable/disable the
 functionality in conjunction with a compiler switch can have an impact
 on performance.

How were you doing it that the mixin keyword got in your way? I think the following should work right now: version(WithLogging) mixin Logging!(whatever); -- <IXOYE><
Feb 14 2010
parent reply sybrandy <sybrandy gmail.com> writes:
On 02/15/2010 01:47 AM, BCS wrote:
 How were you doing it that the mixin keyword got in your way? I think
 the following should work right now:

 version(WithLogging) mixin Logging!(whatever);

 --
 <IXOYE><

That's actually the reverse of what I was doing. My template looked something like this (And forgive me if I screw up the syntax...I don't have the code in front of me): template Trace(string msg) { version (NoLogging) { } else { // Write to the log file... } } And then in the code you'd see something like this: mixin(Trace!("Msg...")); My reason for this was to not have the user add all the version statements throughout their code if they want to be able to compile a version with no logging. In my design, I also have a normal class that does the logging and the mixins are simply a wrapper around it. As for why the mixin keyword is in the way, how much would you like write the above line in your code? That's what I mean by being in the way. To me, the following code would be more user-friendly: mixin template Trace(string msg) { version (NoLogging) { } else { // Write to the log file... } } Trace!("Msg..."); Granted, it's not clear that a mixin is being used where you call Trace, but I don't think it really matters too much. Did I make that clear enough?
Feb 15 2010
parent reply BCS <none anon.com> writes:
Hello sybrandy,

[...]
 Did I make that clear enough?

OK I see what you are doing, but now I don't see why you are using mixins at all. (Unless you are doing the pass-expressions-as-strings trick but just didn't show that. As for that case, I've already pointed out why I think mixins at all is the wrong way to go.) -- <IXOYE><
Feb 15 2010
parent reply sybrandy <sybrandy gmail.com> writes:
On 02/15/2010 01:50 PM, BCS wrote:
 Hello sybrandy,

 [...]
 Did I make that clear enough?

OK I see what you are doing, but now I don't see why you are using mixins at all. (Unless you are doing the pass-expressions-as-strings trick but just didn't show that. As for that case, I've already pointed out why I think mixins at all is the wrong way to go.)

doesn't have to put in version(DoLogging)... all over the place. By containing it in one location, I was trying to keep the code using the library cleaner.
Feb 15 2010
next sibling parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 02/15/2010 10:53 PM, sybrandy wrote:
 In short: I'm using mixins so that the person who's using the library
 doesn't have to put in version(DoLogging)... all over the place.  By
 containing it in one location, I was trying to keep the code using the
 library cleaner.

version (NoTrace) { //do nothing } else { //do tracing } } trace("Stuff"); will this not work?
Feb 15 2010
parent reply sybrandy <sybrandy gmail.com> writes:
On 02/15/2010 05:37 PM, Pelle Månsson wrote:
 On 02/15/2010 10:53 PM, sybrandy wrote:
 In short: I'm using mixins so that the person who's using the library
 doesn't have to put in version(DoLogging)... all over the place. By
 containing it in one location, I was trying to keep the code using the
 library cleaner.

version (NoTrace) { //do nothing } else { //do tracing } } trace("Stuff"); will this not work?

It will work, however I was going for "if you're not logging, why have the logging code in there?" Like I said, I was going for performance and with mixins I could ensure there was no runtime overhead with instantiating the class, setting up the logger, etc. when the user turned logging off. In this version: template Trace(string msg) { version (NoLogging) { } else { // Write to the log file... } } If NoLogging is turned on, then no code to perform the logging is even added to the file. It seemed to me that this was favorable to having a bunch of empty functions laying around. Now, if DMD was smart enough to eliminate empty functions, that would be great and I wouldn't have to do this. Regardless, I'm still all for moving the "mixin" keyword to the mixin declaration vs. where it's instantiated.
Feb 16 2010
parent sybrandy <sybrandy gmail.com> writes:
On 02/16/2010 07:52 PM, sybrandy wrote:
 On 02/15/2010 05:37 PM, Pelle Månsson wrote:
 On 02/15/2010 10:53 PM, sybrandy wrote:
 In short: I'm using mixins so that the person who's using the library
 doesn't have to put in version(DoLogging)... all over the place. By
 containing it in one location, I was trying to keep the code using the
 library cleaner.

version (NoTrace) { //do nothing } else { //do tracing } } trace("Stuff"); will this not work?

It will work, however I was going for "if you're not logging, why have the logging code in there?" Like I said, I was going for performance and with mixins I could ensure there was no runtime overhead with instantiating the class, setting up the logger, etc. when the user turned logging off. In this version: template Trace(string msg) { version (NoLogging) { } else { // Write to the log file... } } If NoLogging is turned on, then no code to perform the logging is even added to the file. It seemed to me that this was favorable to having a bunch of empty functions laying around. Now, if DMD was smart enough to eliminate empty functions, that would be great and I wouldn't have to do this. Regardless, I'm still all for moving the "mixin" keyword to the mixin declaration vs. where it's instantiated.

Well, I tried out what you guys suggested and it worked perfectly. I really don't know why I thought there would still be a little overhead if I didn't use a mixin. So, thanks for the help. On a brighter note, at least I learned something new :)
Feb 16 2010
prev sibling parent BCS <none anon.com> writes:
Hello sybrandy,

 On 02/15/2010 01:50 PM, BCS wrote:
 
 Hello sybrandy,
 
 [...]
 
 Did I make that clear enough?
 

mixins at all. (Unless you are doing the pass-expressions-as-strings trick but just didn't show that. As for that case, I've already pointed out why I think mixins at all is the wrong way to go.)

doesn't have to put in version(DoLogging)... all over the place. By containing it in one location, I was trying to keep the code using the library cleaner.

OK, but I'm still not seeing why you do it that way. Why not put the version(DoLogging) inside the logging function? void Trace(string msg)() { version (NoLogging) {} else { DoTrace(msg); } } or if that doesn't work for some reason: version (NoLogging) { void Trace(string msg)(){} } else { void Trace(string msg)() { DoTrace(msg); } } -- <IXOYE><
Feb 16 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Walter Bright wrote:

 Right now, mixins are defined and used as:
 
     template foo(T) { declarations... }
 
     mixin foo!(int) handle;
 
 The proposal is to switch it around:
 
     mixin template foo(T) { declarations... }
 
     foo!(int) handle;
 
 to follow the notion that mixin templates are very different from
 regular templates, and that should be reflected in their definition
 rather than use.
 
 What do you think?

I do like the idea of differentiating between normal templates and templates intended to be mixed in. However, I'm a bit concerned that removing the need for the mixin keyword when actually mixing it in could result in a loss of clarity - especially when it's legal to give the mixin a name. If I see foo!(int) handle; I'm going to thing that you just declared a variable of type foo!(int). I wouldn't expect it to be a mixin. And how could you tell except if the variable is used or not? And if it isn't, then it makes it look like maybe it's an unused variable. Disallowing the name would help foo!(int); (I don't know why you'd want the name in the first place), but I think that it's much clearer to have mixin foo!(int); That way I know exactly what you're doing. It costs some extra keystrokes, but I think that the additional clarity is well worth it. So, I think that making templates intended to be mixed in have to be marked with the mixin keyword is a good idea, but I think that it's a bad idea to not require the mixin keyword when actually mixing it in. - Jonathan M Davis
Feb 14 2010
parent reply BCS <none anon.com> writes:
Hello Jonathan,

 (I don't know why you'd want the name in the first place),

mixin foo!(int) asInt; mixin foo!(float) asFloat; Without the names you can't access anything.
 So, I think that making templates intended to be mixed in have to be
 marked with the mixin keyword is a good idea, but I think that it's a
 bad idea to not require the mixin keyword when actually mixing it in.

Ditto. -- <IXOYE><
Feb 14 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
BCS wrote:

 Hello Jonathan,
 
 (I don't know why you'd want the name in the first place),

mixin foo!(int) asInt; mixin foo!(float) asFloat; Without the names you can't access anything.

Well, I obviously need to read up on mixins again. I don't have any clue why you'd ever want to access them. I thought that they were just replaced with the code that they contain, and I don't know what you'd be trying to access. I'll have to go read the documentation again... - Jonathan M Davis
Feb 15 2010
parent BCS <none anon.com> writes:
Hello Jonathan,

 BCS wrote:
 
 Hello Jonathan,
 
 (I don't know why you'd want the name in the first place),
 

mixin foo!(float) asFloat; Without the names you can't access anything.

clue why you'd ever want to access them. I thought that they were just replaced with the code that they contain, and I don't know what you'd be trying to access. I'll have to go read the documentation again...

Mixins (of that kind) are replaced by the contents of the template. Because templates only contain declarations, unless you access them, all you end up doing (RAII like cases aside) is adding unreferenced variables/functions/etc. -- <IXOYE><
Feb 15 2010
prev sibling next sibling parent reply Joel Anderson <ask me.com> writes:
On 2/14/2010 1:31 PM, Walter Bright wrote:
 Right now, mixins are defined and used as:

 template foo(T) { declarations... }

 mixin foo!(int) handle;

 The proposal is to switch it around:

 mixin template foo(T) { declarations... }

 foo!(int) handle;

 to follow the notion that mixin templates are very different from
 regular templates, and that should be reflected in their definition
 rather than use.

 What do you think?

I think this is a good idea. Particularly for string mixins.
Feb 15 2010
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Joel Anderson wrote:
 On 2/14/2010 1:31 PM, Walter Bright wrote:
 Right now, mixins are defined and used as:

 template foo(T) { declarations... }

 mixin foo!(int) handle;

 The proposal is to switch it around:

 mixin template foo(T) { declarations... }

 foo!(int) handle;

 to follow the notion that mixin templates are very different from
 regular templates, and that should be reflected in their definition
 rather than use.

 What do you think?

I think this is a good idea. Particularly for string mixins.

But string mixins are a different thing, I don't think this change applies to them.
Feb 15 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

 What do you think?

I wholeheartedly support this. As for the criticisms given by many here, one usage I have often encountered is the 'pseudo-type' - a mixin'ed template that offers behavior close to that of embedding a struct, but with better access to its context. -- Simen
Feb 15 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:

     template foo(T) { declarations... }

     mixin foo!(int) handle;

 The proposal is to switch it around:

     mixin template foo(T) { declarations... }

     foo!(int) handle;

 to follow the notion that mixin templates are very different from  
 regular templates, and that should be reflected in their definition  
 rather than use.

What consensus was reached here? I see that instantiating mixin templates without the mixin prefix does not work. Will it in the future? -- Simen
Jun 29 2010
next sibling parent BCS <none anon.com> writes:
Hello Simen,

 Walter Bright <newshound1 digitalmars.com> wrote:
 
 Right now, mixins are defined and used as:
 
 template foo(T) { declarations... }
 
 mixin foo!(int) handle;
 
 The proposal is to switch it around:
 
 mixin template foo(T) { declarations... }
 
 foo!(int) handle;
 


IIRC, none. -- ... <IXOYE><
Jun 29 2010
prev sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
On Tue, 29 Jun 2010 16:05:26 +0200, BCS <none anon.com> wrote:

 Hello Simen,

 Walter Bright <newshound1 digitalmars.com> wrote:

 Right now, mixins are defined and used as:
  template foo(T) { declarations... }
  mixin foo!(int) handle;
  The proposal is to switch it around:
  mixin template foo(T) { declarations... }
  foo!(int) handle;


IIRC, none.

I really hope they make it optional at the usage site and compulsory at the definition site.
Jun 29 2010