Hi,

I have a C macro, which takes an argument, log it and call a function.
So, if I had a source code like this:

{
  _logfx(x + 10);
}

the actual code would be

  DebugLog("x + 10");
  fx(x + 10);

Can I make similar tricks in the D language?

Thank you.

Delorien:

> I have a C macro, which takes an argument, log it and call a function.
> So, if I had a source code like this:
>
> {
>   _logfx(x + 10);
> }
>
> the actual code would be
>
>   DebugLog("x + 10");
>   fx(x + 10);
>
> Can I make similar tricks in the D language?

Is a syntax like this acceptable?

mixin(LogIt!(fn, q!{x + 10}));

Bye,
bearophile

On 11/07/14 03:35, Delorien wrote:
> Hi,
>
> I have a C macro, which takes an argument, log it and call a function.
> So, if I had a source code like this:
>
> {
>    _logfx(x + 10);
> }
>
> the actual code would be
>
>    DebugLog("x + 10");
>    fx(x + 10);
>
> Can I make similar tricks in the D language?

No, I don't think so. Not without passing it as a string to begin with. Or AST macros, which we don't have.

-- 
/Jacob Carlborg

On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 11/07/14 03:35, Delorien wrote:
> >Hi,
> >
> >I have a C macro, which takes an argument, log it and call a function.  So, if I had a source code like this:
> >
> >{
> >   _logfx(x + 10);
> >}
> >
> >the actual code would be
> >
> >   DebugLog("x + 10");
> >   fx(x + 10);
> >
> >Can I make similar tricks in the D language?
> 
> No, I don't think so. Not without passing it as a string to begin with. Or AST macros, which we don't have.
[...]

Sure you can:

	auto logAndCall(alias func, string expr)() {
		DebugLog(expr);
		return func(mixin(expr));
	}

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


T

-- 
I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.  In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright

On 7/11/14, 11:14 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d wrote:
>> On 11/07/14 03:35, Delorien wrote:
>>> Hi,
>>>
>>> I have a C macro, which takes an argument, log it and call a
>>> function.  So, if I had a source code like this:
>>>
>>> {
>>>    _logfx(x + 10);
>>> }
>>>
>>> the actual code would be
>>>
>>>    DebugLog("x + 10");
>>>    fx(x + 10);
>>>
>>> Can I make similar tricks in the D language?
>>
>> No, I don't think so. Not without passing it as a string to begin
>> with. Or AST macros, which we don't have.
> [...]
>
> Sure you can:
>
> 	auto logAndCall(alias func, string expr)() {
> 		DebugLog(expr);
> 		return func(mixin(expr));
> 	}
>
> 	double myFunc(double arg) { ... }
> 	auto result = logAndCall!(myFunc, q{1.0 + 2.0/4});
>
>
> T
>

But the OP wanted to write:

_logfx(x + 10)

Not:

logAndCall!(fx, q{x + 10})

Notice that the first one is much more readable, and also much easier to use.

D lacks proper macros. In Crystal you can do it like this:

---
def debug_log(msg)
  puts "Debug: #{msg}"
end

def fx(exp)
  puts "Exp is: #{exp}"
end

macro logfx(exp)
  debug_log({{exp.stringify}})
  fx({{exp}})
end

logfx(1 + 2)
---

Output:

Debug: 1 + 2
Exp is: 3

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! :-)

Full macro system is not needed to implement it, just AST reflection can do the trick (and has better fit with existing features).

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.

On 7/11/14, 7:38 PM, 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.

Also, what you want to do with an AST is definitely creating code. And, in my opinion, it's much easier to create code by writing it and not by creating the nodes.

Compare this:

macro logfx(exp)
  debug_log({{exp.stringify}})
  fx({{exp}})
end

To this:

macro logfx(exp)
  debug_log_call = Call.new("debug_log", StringLiteral.new(exp.to_s))
  fx_call = Call.new("fx", exp)
  Expressions.new [debug_log_call, fx_call]
end

The second one is very hard to understand and, if implemented with CTFE, will be much slower to execute.

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

On Friday, 11 July 2014 at 22:42:26 UTC, Ary Borenszweig wrote:
> Also, what you want to do with an AST is definitely creating code. And, in my opinion, it's much easier to create code by writing it and not by creating the nodes.

Choice is very simple in my opinion. AST macro system overlaps with string mixins in functionality and we are not going to remove the latter from the D. Simply making possible to reflect upon AST and generate code for very same string mixins will be an incremental addition to existing D feature set, full macro system will be a completely new feature.

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.)