February 02, 2019
On Saturday, 2 February 2019 at 00:25:02 UTC, Per Nordlöw wrote:
> On Saturday, 2 February 2019 at 00:06:58 UTC, Rubn wrote:
>> void dbg(alias a)(string file = __FILE__, int line = __LINE__) {
>> 	writeln( file, "(", line, "): ", __traits(identifier, a), " = ", a );
>> }
>
> Nice!
>
> I wasn't aware of `__traits(identifier, a)`. What role does it play here?
>
> Further, can we make this variadic with respect to `alias a`?

I got this working without using the alias a, but working with variadic:

```
template dbg(args...)
{
	alias dbgImpl!(args).print dbg;
}

template dbgImpl(args...)
{
	void print(string file = __FILE__, uint line = __LINE__, string fun = __FUNCTION__)
	{
		static foreach (int i, a; args)
		{
			debug stderr.writefln("[%s:%s (%s)] %s = %s", file, line, fun,
					__traits(identifier, args[i]), args[i]);
		}
	}
}

void main()
{
	int i;
	float f = 3.14;
	string s = "some string";

	dbg!(i, f, s);
}
```
prints:
[dbg.d:28 (dbg.main)] i = 0
[dbg.d:28 (dbg.main)] f = 3.14
[dbg.d:28 (dbg.main)] s = some string
February 02, 2019
On Fri, 01 Feb 2019 21:40:29 +0000, Meta wrote:
> His main argument, about not wanting people to be able to invent their own syntax and encourage fragmentation within the language community, does not ring true. All you have to do is look at Rust to see that it is possible to support a limited form of AST macro without any adverse effects.

From what I've read, Rust macros allow you to define new syntax:

    let fib = recurrence![ a[n]: u64 = 0, 1 ... a[n-1] + a[n-2] ];

credit: https://danielkeep.github.io/practical-intro-to-macros.html

That "..." isn't a Rust language construct; it's defined by the macro (and only works within the macro's arguments, so you can't do a Pascal-in-C style `#define begin {`).

Even without defining new syntax, AST macros in C# have allowed things like database libraries that take normal lambdas. They're sufficient for writing an assertion tool that can take an expression, evaluate it, and print out every part of it for analysis if something went wrong.

An old DIP <https://wiki.dlang.org/DIP50> for AST macros in D suggests this strategy, along with implicit stringification of block statements belonging to a macro invocation and access to the context of the invocation. That probably shouldn't be necessary to do a lot of weird and wonderful things.

But it's not going to happen.
February 02, 2019
On Saturday, 2 February 2019 at 05:20:50 UTC, Neia Neutuladh wrote:
> An old DIP <https://wiki.dlang.org/DIP50> for AST macros in D
It looks interesting. Why didn't it go?
February 02, 2019
On Saturday, 2 February 2019 at 00:06:58 UTC, Rubn wrote:
> import std.stdio;
>
> void dbg(alias a)(string file = __FILE__, int line = __LINE__) {
> 	writeln( file, "(", line, "): ", __traits(identifier, a), " = ", a );
> }
>
> int value = 10;
> dbg!value;      // filename.d(12): value = 10

I did think it was weird that a similar result couldn't be produced using __FILE__ and __LINE__, given that even C++ has them.

Look like something that could be added to std.stdio.

Only problem:

    dbg!(2 + 1); // Prints "a = 3"

(could be mitigated by naming the alias "_")
February 02, 2019
On Friday, 1 February 2019 at 15:49:24 UTC, Per Nordlöw wrote:
> Rust just added a standard macro `dbg` for debug printing
>
> https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html#the-dbg-macro
>
> [...]

What's wrong with `debug log(<whatever>);` from `std.experimental.logger;`?

Works like a charm in my project. The message is prepended with a time stamp and location in file/function/line.

February 02, 2019
On Friday, 1 February 2019 at 23:50:04 UTC, jmh530 wrote:
> In general, the rvalue DIP makes pretty clear that Walter and Andrei have a high bar for the quality of a DIP, particularly one that could have a big impact on the language. I don't think the old AST macro DIP is probably up to the standard that would be needed at this point regardless. It would need a re-work and definitely need to be written from the perspective of convincing W&A, which is a pretty high hurdle given their biases.

While you're being more charitable than most people I've seen on the forum, I think this isn't a constructive approach to dealing with language maintainers.

A lot of people on the forum are essentially treating the maintainers as living obstacles to be worked around, not people to work with, which:

- Is kind of disrespectful in the first place.
- Excludes them from the discussion, instead of trying to improve communication.
- Asks the wrong question: "How can we convince them?" instead of "What is best for the language, and how does that overlap with their opinion?"

I'm not saying they're always right, mind you.

But to get back to AST macros, I think it would be more constructive to look at the positive aspects of macros, the intended use cases, examples from other languages where macros are useful, etc... and *also* look at their drawbacks, investigate the problems they can create, probably ask Walter and Andrei for an exhaustive list of objections, ideally examples of problematic code...

Then, when it comes to writing a DIP, try to propose something that covers the intended use cases in an elegant way *without* hitting the drawbacks they're worried about. The DIP shouldn't be "That thing you already refused except this time it's going to convince you despite your biases!", because that's not an intellectually honest way to proceed.

I don't think I'm saying anything crazy either. Most use cases for AST macros in other languages are already covered by D's template system. It might be possible to get the most popular use cases (eg smart assertions) by just giving templates more power.
February 02, 2019
On Saturday, 2 February 2019 at 10:42:27 UTC, Olivier FAURE wrote:
> (could be mitigated by naming the alias "_")

Or adding a new "expressionString" trait applicable to aliases and variadic templates. A trait like that might be useful for smart assertions.
February 02, 2019
On 2019-02-01 21:32, 12345swordy wrote:

> I am pretty sure that the universe will freeze-over, before Walter consider AST macros.

Yeah, I know :(.

-- 
/Jacob Carlborg
February 02, 2019
On 2019-02-02 00:50, jmh530 wrote:
> It would need a re-work and definitely need to be written from the perspective of convincing W&A, which is a pretty high hurdle given their biases.

All of the old DIPs (on the wiki) are written in a completely different style. Back then the requirements to get a DIP passed was a lot less then it is now. Those DIP are not really written like a spec. On the other hand the D spec is not written like a spec either :).

> Two of the interesting things about AST macros to me are 1) that it seems pretty straightforward to implement C++'s metaclass proposal using them

Yes, I think so.

> 2) not only could a lot of D's other features like foreach be written in terms of them but a lot of the attributes could too. This could enable a lot of customization, which could be good or bad...

Yes, exactly.

-- 
/Jacob Carlborg
February 02, 2019
On 2019-02-02 08:24, Dmitry wrote:
> On Saturday, 2 February 2019 at 05:20:50 UTC, Neia Neutuladh wrote:
>> An old DIP <https://wiki.dlang.org/DIP50> for AST macros in D
> It looks interesting. Why didn't it go?

It was never formally put through a process. Not sure if we had a process back then for DIPs. Originally it was just me writing down what I though AST macros would be like in a single place, to avoid having to repeat long explanations on the forums.

-- 
/Jacob Carlborg