DIP 50 - AST macros

[Rob T]

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei 
Alexandrescu wrote:
[...]
>
> Natural languages are "humans complete" because they are the 
> one vehicle we use to describe and manipulate our understanding 
> of the entire reality. If configurable syntax was something 
> necessary to model the world, it would have inevitably occurred 
> in natural languages one way or another. Instead, all human 
> languages (with no exception I know of) have fixed syntax and 
> prefer to add modeling power in other ways. There must be 
> something about this.
>
>
> Andrei

Not an unreasonable assumption to make, so assuming it's true, 
then we need a fixed way to deal with a certain set of problems 
that so far cannot be done reasonably (or at all) in current D.

One case, which I also so happen to want to solve, is the 
async/await type of problem. There's simply no reasonable 
solution available other than through extensions to the language, 
which may or may not ever materialize. It's very frustrating when 
you want to explore possibilities today rather than wait for an 
extension that may never arrive.

Adding in the async/await extensions can help solve only that 
specific problem, but how many other types of problems that are 
similar to this one will programmers still want to solve? A more 
general solution would seem to be far more useful.

The other simple problem I encountered, at first seems like a 
mixin can deal with or perhaps a template, but current D simply 
cannot do it in a reasonable way that I'm aware of.

I want to be able to pass an argument to an "inspect" function, 
that will log or display the symbol name of the top-level 
argument and it's corresponding value.

Example:

int a = 300;
inspect( a ); // or inspect!a;

The only way I can do this is through double entry of the item to 
inspect
eg

inspect( a.stringof, a ); // error prone and irritatingly 
redundant

I can get some success using an alias template parameter, but it 
does not work in general, only in a few cases will it work, so 
templates are not a solution without some additional enhancements.

May be by adding in something like __ARGS__, or expanding 
on__traits can solve this type of problem, but there's no doubt 
many other scenarios that will require similar extensions that 
users of the language cannot implement. There's no end to this 
without much better access to reflection.

--rt