11-Nov-2013 01:20, Jacob Carlborg пишет:
> I've been thinking quite long of how AST macros could look like in D.
> I've been posting my vision of AST macros here in the newsgroup a couple
> of times already. I've now been asked to create a DIP out of it, so here
> it is:
>
> http://wiki.dlang.org/DIP50
>

I have to say I like it.

I find it nice that it would allow one to finally ensure that inlining is always done by making critical primitives macros instead of functions. This is vastly superior compared to the _only_ current option of generating unrolled code with string mixins.

I'd call attribute macros - declaration macros in line with statement macros, then describe how they look - a lot like attributes.

Things to note though:
 - Can't implement scope(exit/success/failure) because that would need to capture the outer scope to pack it into try/catch/finally.
 - Can't implement foreach if only because of the syntax of the latter.
 - There is no definition of Ast!(T) construct - I take it's a struct or a class of sorts and the whole thing works with the CTFE engine. Then it also needs specification of Statements, Declarations.
 - It seems like I can use AST literal in R-T code as well? That would be useful but only if some library actually accepted these AST nodes.

-- 
Dmitry Olshansky

Am Sun, 10 Nov 2013 22:20:30 +0100
schrieb Jacob Carlborg <doob@me.com>:

> I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is:
> 
> http://wiki.dlang.org/DIP50

Wow, some topics really explode recently. Is the D user base growing or are AST macros drawing so much attention?

-- 
Marco

On Monday, 11 November 2013 at 12:13:54 UTC, Marco Leise wrote:
> Wow, some topics really explode recently. Is the D user base
> growing or are AST macros drawing so much attention?

I'd like to say both. AST macros are one of those few things that I wouldn't mind seeing breaking changes for and I'm in the camp of "avoid breaking changes at all cost". AST macros are to code what templates are to data. Despite it being possible to go without templates, I'm not at all tempted to switch to Go.

On 2013-11-11 12:04, Rikki Cattermole wrote:

> Ok pragmas essentially call functions like error in the compiler [0].
> What I am thinking error will do is instead of outputting like msg it'll
> call error[1]. This is exactly what you want.
>
> [0]
> https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2862
>
> [1]
> https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2957

Yes, I still don't understand why you would want it as a pragma. Be usable outside of macros?

-- 
/Jacob Carlborg

On 2013-11-11 12:08, Rikki Cattermole wrote:

> I was referring to the use case as to why we should have the ability to
> get scoped variables from the initiation point.
> Example:
>
> void func(int i) {
>      bool b;
>      macr {}
> }
>
> macro foo (Context context, Ast!(string) str)
> {
>      writeln(context.scopeVariables!int("i"));
>      writeln(context.scopeVariables!bool("b"));
>      return "";
> }

Ok, I see. Please add additional examples to the DIP if you think it's missing.

-- 
/Jacob Carlborg

On 2013-11-11 12:06, Timothee Cour wrote:

> I'm using a modified assert that uses the ugly import(file)[line] trick,
> so that can be done (but is really ugly and has impact either runtime or
> compile time). But we're essentially in agreement.

Right, that ugly trick :)

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 12:30:07 UTC, Jacob Carlborg wrote:
> Yes, I still don't understand why you would want it as a pragma. Be usable outside of macros?

Yes outside of macros would be useful. For example code like this would become redundant:
pragma(msg, "Support for x is not implemented on platform y");
static assert(0);

Becoming:
pragma(error, "Support for x is not implemented on platform y");

Also pragma's core responsibility is to cause the compiler to do something. In this case to say we hit an error during compilation please tell the user/dev and die.

It is a hook to the compilers workings.

Currently working on getting this implemented. Nearly done with it. Just got some extra spaces that shouldn't be in output.

On Monday, 11 November 2013 at 01:49:45 UTC, Timothee Cour wrote:
> People have shunned proposals to have @mixin functions because it wouldn't
> be obvious at call site that some statement is executed under a mixin
> (which could access all variables in scope etc).
>
> The same will happen here; I think it should be clear at call site that a
> macro is used.
> How about:
>
> macro!myAssert(1 + 2 == 4);
> instead of myAssert(1 + 2 == 4);

If macros are supposed to access outer scope, I agree, this is a necessary restriction.

On 2013-11-11 12:34, Dmitry Olshansky wrote:

> I have to say I like it.

Cool :)

> I find it nice that it would allow one to finally ensure that inlining
> is always done by making critical primitives macros instead of
> functions. This is vastly superior compared to the _only_ current option
> of generating unrolled code with string mixins.
>
> I'd call attribute macros - declaration macros in line with statement
> macros, then describe how they look - a lot like attributes.

Ok, I can change that.

> Things to note though:
>   - Can't implement scope(exit/success/failure) because that would need
> to capture the outer scope to pack it into try/catch/finally.

Right. scope(exit) could perhaps be implement with a custom struct and calling a block in the destructor.

>   - Can't implement foreach if only because of the syntax of the latter.

I would think something like this:

macro foreach (T) (Context context, Ast!(Symbol) var, Ast!(T) collection, Statement block)
{
    if (isRange(collection))
    {
        return <[
            for (auto __r = $collection; !__r.empty; __r.popFront())
            {
                auto $var = __r.front;
                block;
            }
        ]>;
    }

    else if (hasOpApply(collection))
    {
        ...
    }

    else ...
}

Perhaps not all of the existing syntax can fit in a macro.

>   - There is no definition of Ast!(T) construct - I take it's a struct
> or a class of sorts and the whole thing works with the CTFE engine. Then
> it also needs specification of Statements, Declarations.

Yes, something like that. I don't know exactly how the Ast type need to look like. See one of my replies to bearophile:

http://forum.dlang.org/thread/l5otb1$1dhi$1@digitalmars.com

>   - It seems like I can use AST literal in R-T code as well? That would
> be useful but only if some library actually accepted these AST nodes.

Actually, I haven't thought about this. I think my original idea was that <[ ]> should only work inside macros. But that it would be possible to pass Ast nodes to other functions.

-- 
/Jacob Carlborg

On 2013-11-11 13:13, Marco Leise wrote:

> Wow, some topics really explode recently. Is the D user base
> growing or are AST macros drawing so much attention?

AST macros are drawing so much attension. For some, it's like the holy grail.

-- 
/Jacob Carlborg