Nick Sabalausky wrote:
"grauzone" <n...@example.net> wrote in message
news:hlbg22$6f...@digitalmars.com...
Nick Sabalausky wrote:
"BCS" <n...@anon.com> wrote in message
news:a6268ff103d38cc7ba48d6fa...@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.
