On Friday, 11 July 2014 at 22:59:10 UTC, Dicebot wrote:
> On Friday, 11 July 2014 at 22:38:36 UTC, Idan Arye wrote:
>> On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
>>> Full macro system is not needed to implement it, just AST reflection can do the trick (and has better fit with existing features).
>>
>> Wouldn't AST reflection be more complex to implement&use than a macro system? I mean, a macro system is quite functional in nature - the macro takes AST arguments and return an AST that the compiler embeds into the code. With AST reflection, you need to mutate an existing AST, which is more complex because order of execution matters.
>
> I mean read-only reflection akin to existing __traits

I assume "read-only" reflection means that functions produce ASTs that are directly embedded into the code(rather than modifying the AST of existing code) which is the same as with macros. So, if the method of output is the same, I assume the difference is the method of input. Macros take raw code(either as text like C macros as or AST like Lisp macros) and return modified code of the same format. Reflection is about looking at code from elsewhere, which would make the OP's request impractical, as `x + 10` will have to be defined elsewhere and the reflection code will have to be referred to that place.

I would like to see an AST based macro system, where `mixin` can accept ASTs and the `macro` keyword is an attribute for function arguments that turns them into ASTs. With this, we don't need special syntax to create ASTs on the fly - we can have a simple `toAST` library function:

    AST(T) toAST(T)(macro(T) expr){
        return expr;
    }

Note that `expr` is of type `AST(T)` - `macro` converts arguments of type `T` to `AST(T)` just like `lazy` converts arguments of type `T` to `T delegate()`.


The OP's function macro will look like this:

    AST(void) debugLog(T)(macro(T) expr){
        auto printStatement=toAST(writeln(expr.toString()));
        return new AST!(void)(printStatement,expr);
    }

    mixin(debugLog(x+10));

On 2014-07-11 16:14, H. S. Teoh via Digitalmars-d wrote:

> 	auto result = logAndCall!(myFunc, q{1.0 + 2.0/4});

You're passing it as a string.

-- 
/Jacob Carlborg

On 2014-07-12 01:02, Dicebot wrote:

> Whatever is ideal solution, we better focus on something practical that
> can be realistically added to the language within current priorities
> (stability, minimizing addition of new features, clearing corner cases
> etc.)

Funny thing you should mention "minimizing addition of new features". That's exactly what AST macros are for. Just the recent addition of supporting C++ namespaces could have easily been implemented with AST macros.

-- 
/Jacob Carlborg

On 2014-07-12 01:46, Idan Arye wrote:

> I assume "read-only" reflection means that functions produce ASTs that
> are directly embedded into the code(rather than modifying the AST of
> existing code) which is the same as with macros.

No, I'm pretty sure he means you can only reflect on the AST. Not produce new a new AST that will be inserted somewhere.


> I would like to see an AST based macro system, where `mixin` can accept
> ASTs and the `macro` keyword is an attribute for function arguments that
> turns them into ASTs. With this, we don't need special syntax to create
> ASTs on the fly - we can have a simple `toAST` library function:
>
>      AST(T) toAST(T)(macro(T) expr){
>          return expr;
>      }
>
> Note that `expr` is of type `AST(T)` - `macro` converts arguments of
> type `T` to `AST(T)` just like `lazy` converts arguments of type `T` to
> `T delegate()`.
>
>
> The OP's function macro will look like this:
>
>      AST(void) debugLog(T)(macro(T) expr){
>          auto printStatement=toAST(writeln(expr.toString()));
>          return new AST!(void)(printStatement,expr);
>      }
>
>      mixin(debugLog(x+10));

Here's my current proposal: http://wiki.dlang.org/DIP50

-- 
/Jacob Carlborg

On Friday, 11 July 2014 at 23:46:44 UTC, Idan Arye wrote:
>     AST(T) toAST(T)(macro(T) expr){
>         return expr;
>     }

And I mean something like this:

string takeAST(__ast expr)()
{
    return expr.stringof; // need more detailed reflection than that of course ;)
}

mixin(takeAST!(2 + 2));

On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
> On 2014-07-12 01:02, Dicebot wrote:
>
>> Whatever is ideal solution, we better focus on something practical that
>> can be realistically added to the language within current priorities
>> (stability, minimizing addition of new features, clearing corner cases
>> etc.)
>
> Funny thing you should mention "minimizing addition of new features". That's exactly what AST macros are for. Just the recent addition of supporting C++ namespaces could have easily been implemented with AST macros.

Yes I know and likely would have preferred that approach if we were speaking about designing brand new language. But right now we already have string mixins and those won't ever be deprecated -> any new code generation feature should be built on top of either those or template mixins.

On Friday, 11 July 2014 at 16:44:32 UTC, Ary Borenszweig wrote:
> I think D would be much easier to use if it had proper macros. No need to mess around with q{...}, with string concatenations for generating code (let the compiler do that) and also to make the code more readable and easier to write.
>
> Please, D designers, try looking at other languages to get some inspiration. I read in Reddit that Walter said "I didn't have time to look at how Rust does things". Really? As a language designer I would try to learn about every other possible language to get the best of all of them in my language. Looking at only C++ is not very good.
>
> But that's just my opinion. I'd like D to be easier to use. If one day I have to use it in my workplace, better if it's good! :-)

Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain. Mixins can
give you pretty much the same amoun of functionality while
imposing sane limits to what can be done.

On 07/13/2014 01:13 PM, fra wrote:
> ...
>
> Macros are an aberration that allow code writers to create code
> that is plan impossible to understand and mantain.

If that is what they want to do, that is what they are going to do.
They don't need macros for that.

> Mixins can give you pretty much the same amoun of functionality

No.

> while imposing sane limits to what can be done.

No. The _limits_ reach far into insanity already.

On 07/13/2014 12:45 PM, Dicebot wrote:
> On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
>> On 2014-07-12 01:02, Dicebot wrote:
>>
>>> Whatever is ideal solution, we better focus on something practical that
>>> can be realistically added to the language within current priorities
>>> (stability, minimizing addition of new features, clearing corner cases
>>> etc.)
>>
>> Funny thing you should mention "minimizing addition of new features".
>> That's exactly what AST macros are for. Just the recent addition of
>> supporting C++ namespaces could have easily been implemented with AST
>> macros.
>
> Yes I know and likely would have preferred that approach if we were
> speaking about designing brand new language. But right now we already
> have string mixins

They are not a great liability. They are a simple feature. They take up less than 200 lines of code in my D frontend implementation, _together_ with template mixins.

> and those won't ever be deprecated -> any new code
> generation feature should be built on top of either those or template
> mixins.

That does not follow. In any case Jacob's macros are a code _reflection_ feature and a _hygienic_ code generation feature.

On Sunday, 13 July 2014 at 12:33:21 UTC, Timon Gehr wrote:
>> Yes I know and likely would have preferred that approach if we were
>> speaking about designing brand new language. But right now we already
>> have string mixins
>
> They are not a great liability. They are a simple feature. They take up less than 200 lines of code in my D frontend implementation, _together_ with template mixins.

I am not saying it is insanely complicated but that it is not orthogonal to existing features. And having many ways to do the same thing is rather bad, especially if it is such high-level abstraction.