change mixins

[grauzone]

Nick Sabalausky wrote:
> "grauzone" <none at example.net> wrote in message 
> news:hlbg22$6fb$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> "BCS" <none at anon.com> wrote in message 
>>> news:a6268ff103d38cc7ba48d6fabda at 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!
>>>
>> 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.

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.