On Thursday, 14 November 2013 at 01:38:29 UTC, Walter Bright wrote:
> On 11/13/2013 5:14 PM, deadalnix wrote:
>> My very first project in D involved quite a lot of them. So I very aware of what
>> they are.
>>
>> The whole idea is to be able to extends that to statement and declarations.
>
> My question about that is just what problem is this trying to solve, and why that problem cannot be reformulated in terms of expression templates?
>
> I.e. we shouldn't be adding things to D just because they are cool. They need to solve a problem that is fairly commonplace and too painful to solve with existing mechanisms. The larger the proposed language enhancement is, the more commonplace and and painful the problems must be that it purports to solve.
>

I think the whole point of macro is to NOT add too much feature to the language.

See for instance the example I gave before to create generator. This can be added with extra language support (C# async/await is an example). But with macro, the feature can be implemented as a library.

It is NOT achievable with expression templates.

I can say with certainty that the async/await mechanism is heavily used in some codebases and with great benefit. It is being added to all languages one after another.

The idea behind macros is that instead of adding new feature to the language, the language should propose a toolkit to build these features as library.

I don't think the time has come for macros in D. As discussed before, it seems like filling the gap in existing feature is more important than adding new ones. This should however be considered very seriously when the gaps has been filled.

On 2013-11-14 01:16, Walter Bright wrote:

> Yes. But that's a good thing. I'd be pretty skeptical of the value of an
> AST macro that took 3+4 and changed it so it did something other than
> compute 7.

You can still do stupid things like that with operator overloading. Not on built-in types, but on user defined types. Every language allows you to do stupid things, one way or another.

-- 
/Jacob Carlborg

On 2013-11-14 02:56, deadalnix wrote:

> I think the whole point of macro is to NOT add too much feature to the
> language.
>
> See for instance the example I gave before to create generator. This can
> be added with extra language support (C# async/await is an example). But
> with macro, the feature can be implemented as a library.
>
> It is NOT achievable with expression templates.
>
> I can say with certainty that the async/await mechanism is heavily used
> in some codebases and with great benefit. It is being added to all
> languages one after another.
>
> The idea behind macros is that instead of adding new feature to the
> language, the language should propose a toolkit to build these features
> as library.

Agree, good points.

> I don't think the time has come for macros in D. As discussed before, it
> seems like filling the gap in existing feature is more important than
> adding new ones. This should however be considered very seriously when
> the gaps has been filled.

Unfortunately I don't think we will have a feature freeze from now until those gaps has been filled. Most likely there will be added a couple of small features that could have been solved by AST macros. The problem with that is that each of these features, in themselves, are way to small to add AST macros for. So instead we get new features and even less chance of adding AST macros.

Example. There's a bug report about adding support for C++ namespaces. That should be solveable with library code. It's just mangling and we already have pragma(mangle).

pragma(mangle, namespace("foo::bar")) extern(C++) void x ();

The problem here is that "x" needs to be mangled as well.

pragma(mangle, namespace("foo::bar", x)) extern(C++) void x ();

The above doesn't work due to forward reference errors.

pragma(mangle, namespace("foo::bar", void function (), "x")) extern(C++) void x ();

The problem with the above is that we now need to repeat the signature and the name of the function.

With AST macros:

macro namespace (Context context, Ast!(string) name, Declaration declaration) { ... }

@namespace("foo::bar") extern (C++) void x ();

This works because the macro receives the whole declaration that is "x" and "x" is replaced with whatever the macro returns:

pragma(mangle, "mangled_name_of_x") extern (C++) void x ();

Since it uses the same syntax as UDA's you it can look like real namespaces in C++:

@namespace("foo::bar") extern (C++)
{
    void x ();
    void y ();
}

-- 
/Jacob Carlborg

On 2013-11-13 20:19, Walter Bright wrote:

> The reflection ability is not something specific to an AST, it could be
> added so that any expression node can be reflected. We already do much
> of that with __traits.

Yes, I been thinking of ways to expand __traits. When there's enough of __traits it's not much left during it into real AST macros. Just the part that passes the AST instead of the evaluated result of the arguments to a function.

BTW, is it complicated to return a more structured values, like a struct or a class, than just plain values like strings?

-- 
/Jacob Carlborg

Am 14.11.2013 08:50, schrieb Jacob Carlborg:
> On 2013-11-14 02:56, deadalnix wrote:
>
>> I think the whole point of macro is to NOT add too much feature to the
>> language.
>>
>> See for instance the example I gave before to create generator. This can
>> be added with extra language support (C# async/await is an example). But
>> with macro, the feature can be implemented as a library.
>>
>> It is NOT achievable with expression templates.
>>
>> I can say with certainty that the async/await mechanism is heavily used
>> in some codebases and with great benefit. It is being added to all
>> languages one after another.
>>
>> The idea behind macros is that instead of adding new feature to the
>> language, the language should propose a toolkit to build these features
>> as library.
>
> Agree, good points.
>
>> I don't think the time has come for macros in D. As discussed before, it
>> seems like filling the gap in existing feature is more important than
>> adding new ones. This should however be considered very seriously when
>> the gaps has been filled.
>
> Unfortunately I don't think we will have a feature freeze from now until
> those gaps has been filled. Most likely there will be added a couple of
> small features that could have been solved by AST macros. The problem
> with that is that each of these features, in themselves, are way to
> small to add AST macros for. So instead we get new features and even
> less chance of adding AST macros.
>
> Example. There's a bug report about adding support for C++ namespaces.
> That should be solveable with library code. It's just mangling and we
> already have pragma(mangle).
>
> pragma(mangle, namespace("foo::bar")) extern(C++) void x ();
>
> The problem here is that "x" needs to be mangled as well.
>
> pragma(mangle, namespace("foo::bar", x)) extern(C++) void x ();
>
> The above doesn't work due to forward reference errors.
>
> pragma(mangle, namespace("foo::bar", void function (), "x")) extern(C++)
> void x ();
>
> The problem with the above is that we now need to repeat the signature
> and the name of the function.
>
> With AST macros:
>
> macro namespace (Context context, Ast!(string) name, Declaration
> declaration) { ... }
>
> @namespace("foo::bar") extern (C++) void x ();
>
> This works because the macro receives the whole declaration that is "x"
> and "x" is replaced with whatever the macro returns:
>
> pragma(mangle, "mangled_name_of_x") extern (C++) void x ();
>
> Since it uses the same syntax as UDA's you it can look like real
> namespaces in C++:
>
> @namespace("foo::bar") extern (C++)
> {
>       void x ();
>       void y ();
> }
>

perfect for the DIP example section - more of these please :)

On 2013-11-14 00:27, Rob T wrote:
> On Wednesday, 13 November 2013 at 12:21:22 UTC, Jacob Carlborg wrote:
>
>> I need to read up on what expression templates can do.
>
> But where to read? There's no such thing as "expression template"
> explicitly mentioned in here.
>
> http://dlang.org/template.html

I guess everything about C++ expression templates would be a start.

http://en.wikipedia.org/wiki/Expression_templates

-- 
/Jacob Carlborg

On 2013-11-13 20:16, Walter Bright wrote:

> It actually generated a very fast regex engine, though Dmitry's work has
> since eclipsed it.

Right, a specially tuned engine for that particular regex.

-- 
/Jacob Carlborg

On 2013-11-13 23:29, Martin Nowak wrote:

> Well, codeof is nice but it lacks the parser.

Yes, and the you need to mixin it again. Several unnecessary steps, see the bottom of:

http://forum.dlang.org/thread/l5otb1$1dhi$1@digitalmars.com?page=13#post-l5vcct:242lit:241:40digitalmars.com

-- 
/Jacob Carlborg

On 2013-11-13 23:29, Martin Nowak wrote:

> Right, that's the basic functionality we want.
> What's not clear is how to get the type of y.

That's what the reflection API is for. I guess many people here know a lot more about building AST's than me. But here's a simple API:

auto ast = "x = y".astof;

auto type = ast.right.type;
auto name = type.name;

assert(ast.left.type == type);

-- 
/Jacob Carlborg

On 2013-11-14 08:54, dennis luehring wrote:

> perfect for the DIP example section - more of these please :)

Done: http://wiki.dlang.org/DIP50#C.2B.2B_Namespaces_.28issue_7961.29

-- 
/Jacob Carlborg