On 2013-11-07 00:23, Philippe Sigaud wrote:

> Well, I remember him saying that he doesn't want everybody and their dog
> to change the D syntax. If we get macros, that's exactly what we can do.
> For example, telling the compiler (or another tool), to rewrite
>
> int a := 1;
>
> into
>
> immutable a = 1;

It depends on what the AST macros allows you to do. I guess everyone here has her/his own definition.

> But that means the original not-D code cannot be compiled by anyone with
> a D compiler anymore (obviously). And soon everybody is transforming the
> grammar according to what they think is cool.
> That's his PoV IIRC.
>
> I'm more interested in getting to ability to define my own lowerings: in
> the same way that scope statements or foreach over ranges are rewritten
> into lower-level D code by the comiler, I would like to be able to
> define my own syntactic constructs.

My idea of AST macros[1] is quite similar to those in Scala and a bit similar to what you want. The most important thing to remember is that AST macros cannot create new syntax. It only works at the semantic level of the language. That means the above example you wrote doesn't not work, since that isn't legal D syntax. What would work is doing something like this:

auto a = Person.where(e => e.name == "John");

In this case "where" is a macro. Which translates the given AST into the following SQL query:

select * from person where name = 'John'

Another thing I would really like is to be able to pass a delegate to a function after argument list, if the function takes a delegate as its last parameter:

void each (T) (T[] arr, void delegate (T) dg);

[1, 2, 3].each(e) {
    writeln(e);
}

Of courses, the compiler needs to be able to inline the delegate.

> Plus, everybody here know that AST macros can cure world hunger :)
> Wouldn't that be nice?

Of course :)

[1] https://dl.dropboxusercontent.com/u/18386187/ast_macros.html

-- 
/Jacob Carlborg

On 2013-11-06 09:34, Chad Joan wrote:

> Also, IIRC, it is believed that string mixins with CTFE are potentially
> more powerful.  I am under the assumption that Walter is taking the long
> view and waiting for the community to furnish their own powerful AST
> manipulation tools using the existing spec.  I suspect that he is
> opposed to baking AST manipulation into the /language spec/, but is
> perfectly accepting of the notion of using AST manipulation to generate
> code, reduce boilerplate, implement exotic features and DSLs, and so
> on.  Just don't complicate the core language any more than it already
> is. Sorry if I misrepresented you Walter; I can only make educated
> guesses ;)

The problem with this is the ugly syntax, it requires a string mixin and the source code needs to be embedded in strings. You also need a complete front end that works at compile time.

This is my vision of AST macros: https://dl.dropboxusercontent.com/u/18386187/ast_macros.html

-- 
/Jacob Carlborg

On Thursday, 7 November 2013 at 13:50:57 UTC, Jacob Carlborg wrote:
> https://dl.dropboxusercontent.com/u/18386187/ast_macros.html

Can you pour that into a DIP?

On 2013-11-10 17:37, Martin Nowak wrote:

> Can you pour that into a DIP?

Absolutely, I've been meaning to do that.

-- 
/Jacob Carlborg

On Sunday, 10 November 2013 at 17:58:35 UTC, Jacob Carlborg wrote:
> On 2013-11-10 17:37, Martin Nowak wrote:
>
>> Can you pour that into a DIP?
>
> Absolutely, I've been meaning to do that.

It require a bit more precision. But as you know I really behind the idea.

On 11/10/13 9:58 AM, Jacob Carlborg wrote:
> On 2013-11-10 17:37, Martin Nowak wrote:
>
>> Can you pour that into a DIP?
>
> Absolutely, I've been meaning to do that.

Just a thought - I think the best strategy for the time being is to explore gainful use of the features already present, instead of adding new features.

Andrei

On Sunday, 10 November 2013 at 18:31:32 UTC, Andrei Alexandrescu wrote:
> On 11/10/13 9:58 AM, Jacob Carlborg wrote:
>> On 2013-11-10 17:37, Martin Nowak wrote:
>>
>>> Can you pour that into a DIP?
>>
>> Absolutely, I've been meaning to do that.
>
> Just a thought - I think the best strategy for the time being is to explore gainful use of the features already present, instead of adding new features.
>
> Andrei

It is also a given that many feature could have been avoided in the first place given that one.

Still I'd rather see thing settle down a little before introducing this. Fix the existing things, then introduce new stuff seems like the proper way to go.

On 2013-11-10 19:44, deadalnix wrote:

> It is also a given that many feature could have been avoided in the
> first place given that one.

I agree. It seems at least a couple of features could have been implemented using AST macros instead.

-- 
/Jacob Carlborg

On Sun, Nov 10, 2013 at 12:27 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-10 19:44, deadalnix wrote:
>
>  It is also a given that many feature could have been avoided in the
>> first place given that one.
>>
>
> I agree. It seems at least a couple of features could have been implemented using AST macros instead.
>
> --
> /Jacob Carlborg
>

I agree; eg, just to name 2 features that I proposed that could be simply
implemented via AST macros as Jacob said:
* [proposal: a new string litteral to embed variables in a
string<http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com>

http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com
]
* [Re: feature request: __ARGS__ for logging (cf __FILE__, __LINE__,
__FUNC___ http://forum.dlang.org/post/kegmp0$30dn$1@digitalmars.com]

It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST macros.

On 2013-11-10 21:38, Timothee Cour wrote:

> I agree; eg, just to name 2 features that I proposed that could be
> simply implemented via AST macros as Jacob said:
> * [proposal: a new string litteral to embed variables in a string
> <http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com>
> http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com]
> * [Re: feature request: __ARGS__ for logging (cf __FILE__, __LINE__,
> __FUNC___ http://forum.dlang.org/post/kegmp0$30dn$1@digitalmars.com]
>
> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
> macros.

Let see, what else. These could, most likely, have been implemented using AST macros:

* scope
* foreach
* for
* inlining delegates. I think the current solution to pass a delegate/lambda as an alias parameter is a bit weird

One of my favorites that is not already in the language is implementing database queries:

Person.where(e => e.name == "John");

Will be translate to the following SQL:

select * from person where name = 'John'

Another one is the property shortcut, see the example for attribute macros: http://wiki.dlang.org/DIP50#Attribute_macros

-- 
/Jacob Carlborg