www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How can I dump an expression into log and execute it

reply "Delorien" <none none.no> writes:
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.
Jul 10 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 10 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 10 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Jul 11 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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! :-)
Jul 11 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Full macro system is not needed to implement it, just AST 
reflection can do the trick (and has better fit with existing 
features).
Jul 11 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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.
Jul 11 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Jul 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.)
Jul 11 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jul 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 13 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jul 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/13/2014 02:44 PM, Dicebot wrote:
 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. ...
I am saying that string mixins are way too simple a feature to meaningfully block the way for features that are "not orthogonal" to them.
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 14:23:07 UTC, Timon Gehr wrote:
 I am not saying it is insanely complicated but that it is not 
 orthogonal
 to existing features.  ...
I am saying that string mixins are way too simple a feature to meaningfully block the way for features that are "not orthogonal" to them.
AST reflection + string mixins can do anything that AST macros can do - assuming one does not want to allow transparent macros (without explicit mixin/macro keyword at call site) which is a terrible idea in my opinion anyway.
Jul 13 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/13/14, 12:11 PM, Dicebot wrote:
 On Sunday, 13 July 2014 at 14:23:07 UTC, Timon Gehr wrote:
 I am not saying it is insanely complicated but that it is not orthogonal
 to existing features.  ...
I am saying that string mixins are way too simple a feature to meaningfully block the way for features that are "not orthogonal" to them.
AST reflection + string mixins can do anything that AST macros can do - assuming one does not want to allow transparent macros (without explicit mixin/macro keyword at call site) which is a terrible idea in my opinion anyway.
Why?
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 20:54:27 UTC, Ary Borenszweig wrote:
 AST reflection + string mixins can do anything that AST macros 
 can do -
 assuming one does not want to allow transparent macros 
 (without explicit
 mixin/macro keyword at call site) which is a terrible idea in 
 my opinion
 anyway.
Why?
Good language encourages code base with small "surprise factor". That means that by looking at a single line of code you can may quick safe assumptions about it. Limiting operator overloading, advertising pure functions, banning silent macros - all it helps this goal. Explicit "mixin" keyword warns you : "Here be dragons! Exceptional stuff may happen, pay attention". Silent macros easily break any basic language assumptions and thus are bad in that regard. I must admit D is far from perfect in that regard because operator overloading is still not limited enough and optional parens / unconstrained properties may wreck their own havoc. But this is hardly an excuse for introducing new features with even more surprise potential.
Jul 14 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/14/2014 11:55 AM, Dicebot wrote:
 I must admit D is far from perfect in that regard because operator
 overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of naming your functions properly. auto subtract(int a, int b){ return a+b; }
Jul 14 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
 On 07/14/2014 11:55 AM, Dicebot wrote:
 I must admit D is far from perfect in that regard because 
 operator
 overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of naming your functions properly. auto subtract(int a, int b){ return a+b; }
Same principle of surprise minimization. Reader expects arbitrary actions done by function call. Reader expects arithmetical semantics from arithmetical operations. I don't see "you can change anything" language working for any large team production.
Jul 14 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/14/14, 12:29 PM, Dicebot wrote:
 On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
 On 07/14/2014 11:55 AM, Dicebot wrote:
 I must admit D is far from perfect in that regard because operator
 overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of naming your functions properly. auto subtract(int a, int b){ return a+b; }
Same principle of surprise minimization. Reader expects arbitrary actions done by function call. Reader expects arithmetical semantics from arithmetical operations. I don't see "you can change anything" language working for any large team production.
Macros are not "you can change anything". Macros generate code based on AST nodes. No surprise at all. You read the comments on what the macro does (or look at the code) and that's it. Making macros look like regular function calls, that you might not like. For me, it makes the code more readable. Instead of this: class Foo mixin(property :foo) end Or this: class Foo property!(:foo) end You simple write this: class Foo property :foo end And it's super clear to everyone what this does (again: or read the docs or check the source code to see what this does). What kind of "macros that change anything" you have in mind?
Jul 14 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
 Making macros look like regular function calls, that you might 
 not like. For me, it makes the code more readable. Instead of 
 this:

 class Foo
   mixin(property :foo)
 end

 Or this:

 class Foo
   property!(:foo)
 end

 You simple write this:

 class Foo
   property :foo
 end

 And it's super clear to everyone what this does (again: or read 
 the docs or check the source code to see what this does).
Well as soon as it has own unique syntax it is not what I call "silent". Though `mixin` is much more notable than single : symbol but that is less of an issue. This is exactly the point where I consider mixins + AST relfection functionally equivalent to macros.
Jul 14 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 14 July 2014 at 16:46:08 UTC, Dicebot wrote:
 On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
 Making macros look like regular function calls, that you might 
 not like. For me, it makes the code more readable. Instead of 
 this:

 class Foo
  mixin(property :foo)
 end

 Or this:

 class Foo
  property!(:foo)
 end

 You simple write this:

 class Foo
  property :foo
 end

 And it's super clear to everyone what this does (again: or 
 read the docs or check the source code to see what this does).
Well as soon as it has own unique syntax it is not what I call "silent". Though `mixin` is much more notable than single : symbol but that is less of an issue. This is exactly the point where I consider mixins + AST relfection functionally equivalent to macros.
Seeing as good ast reflection would form part of any ast macro system, perhaps everyone could agree to focus on designing the reflection syntax/semantics first, whether or not they ultimately want a macro system too.
Jul 14 2014
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/14/2014 05:29 PM, Dicebot wrote:
 On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
 On 07/14/2014 11:55 AM, Dicebot wrote:
 I must admit D is far from perfect in that regard because operator
 overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of naming your functions properly. auto subtract(int a, int b){ return a+b; }
Same principle of surprise minimization. Reader expects arbitrary actions done by function call.
No way.
 Reader expects arithmetical semantics
Right, arithmetical semantics, which for built-in '+' can reach from wrap-around behaviour to saturated behaviour which is not even associative. Knowing what '+' does without being very aware what types its operands are is a pipe dream.
 from arithmetical operations.
'+' is opBinary!"+" and it is just another function name. There don't need to be 'anti-abuse' mechanics in place for this name and not for others.
 I don't see "you can change anything"
D does not allow you to e.g. redefine what the built-in operators do on built-in types, so where is this complaint coming from?
 language working for any large team production.
Languages that do not make built-in operators syntactically special are way better off regarding this issue because this way the question of automatically limiting implementations to match naming is even more obviously pointless. In any case, what are you arguing against here? Lexical scoping? Named definitions? Module systems? :o)
Jul 14 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 16:10:59 UTC, Timon Gehr wrote:
 Same principle of surprise minimization. Reader expects 
 arbitrary
 actions done by function call.
No way.
?
 Reader expects arithmetical semantics
Right, arithmetical semantics, which for built-in '+' can reach from wrap-around behaviour to saturated behaviour which is not even associative. Knowing what '+' does without being very aware what types its operands are is a pipe dream.
I don't mean low level semantics, just very simple "this adds two numbers" semantics - something you can ignore and abuse in D (though I don't know if it is even possible to define such constraints reasonably)
 from arithmetical operations.
'+' is opBinary!"+" and it is just another function name. There don't need to be 'anti-abuse' mechanics in place for this name and not for others.
Do you like boost::spirit? :)
 I don't see "you can change anything"
D does not allow you to e.g. redefine what the built-in operators do on built-in types, so where is this complaint coming from?
D is decent language in that regard - I am speaking about imaginary language that does not constraint any semantics and provides perfect expressive power.
 Languages that do not make built-in operators syntactically 
 special are way better off regarding this issue because this 
 way the question of automatically limiting implementations to 
 match naming is even more obviously pointless.
You do realize this statement creates self-referential cycle and is thus pointless? :)
 In any case, what are you arguing against here? Lexical 
 scoping? Named definitions? Module systems? :o)
macros that can't be recognized as macros at call site based on pure syntax
Jul 14 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:luounykqutytridryekt forum.dlang.org... 

 D is decent language in that regard - I am speaking about 
 imaginary language that does not constraint any semantics and 
 provides perfect expressive power.
Forth is not an imaginary language.
Jul 14 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 14 July 2014 at 17:48:12 UTC, Daniel Murphy wrote:
 Forth is not an imaginary language.
Ah, Forth, a language so terse that you don't edit files, but screens. Quite expressive indeed, remember waiting in line behind some dude hijacking printer for raytracing in postscript... ;)
Jul 14 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/14/14, 2:48 PM, Daniel Murphy wrote:
 "Dicebot"  wrote in message news:luounykqutytridryekt forum.dlang.org...
 D is decent language in that regard - I am speaking about imaginary
 language that does not constraint any semantics and provides perfect
 expressive power.
Forth is not an imaginary language.
I can't seem to learn anything about this language without paying first.
Jul 14 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 14 July 2014 at 18:58:58 UTC, Ary Borenszweig wrote:
 I can't seem to learn anything about this language without 
 paying first.
Not much to learn, it is kinda like stack-based assembly, but useful knowledge if you want to generate Postscript. GNU appears to have a free version: http://www.gnu.org/software/gforth/
Jul 14 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ary Borenszweig"  wrote in message news:lq199i$1312$1 digitalmars.com...

 I can't seem to learn anything about this language without paying first.
http://en.wikipedia.org/wiki/Forth_(programming_language) It allows you to edit syntax as you go! 1 2 3 + + . (prints 6) : 1 2 ; : 2 3 ; 1 2 3 + + . (prints 8) : + * ; 1 2 3 + + . (prints 18) It even allows defining new control structures. Every program is a new dsl. Too much freedom is a bad thing.
Jul 15 2014
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
 On 07/14/2014 11:55 AM, Dicebot wrote:
 I must admit D is far from perfect in that regard because 
 operator
 overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of naming your functions properly. auto subtract(int a, int b){ return a+b; }
Naming things is the second hardest problem in Computer Science, after the Halting Problem. ;D
Jul 14 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 13/07/14 17:11, Dicebot wrote:

 AST reflection + string mixins can do anything that AST macros can do -
 assuming one does not want to allow transparent macros (without explicit
 mixin/macro keyword at call site) which is a terrible idea in my opinion
 anyway.
I think that is the same thing as operator overloading. auto a = b + c; The + operator can be overloaded without you knowing. What about if it wasn't transparent? I don't like using a keyword but perhaps a symbol, like Rust: foo!("asd"); In Rust ! indicates a macro invocation. But this is already occupied in D for template instantiation. I wonder if we can come up with another good symbol. -- /Jacob Carlborg
Jul 14 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-07-13 14:33, Timon Gehr wrote:

 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.
Do you have the source for your frontend available somewhere? -- /Jacob Carlborg
Jul 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/13/2014 04:09 PM, Jacob Carlborg wrote:
 On 2014-07-13 14:33, Timon Gehr wrote:

 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.
Do you have the source for your frontend available somewhere?
(Just to be sure: I was talking about string mixins, not macros, I haven't implemented macros.) Currently it isn't. It isn't really in a state where I'd like to see it released. There are some language features still missing, and its design is still insufficiently documented. It's full of hacks to keep it compiling, and it currently only compiles with DMD 2.060, hence it needs to very poorly emulate UDA's. But if some of the regulars would like to get a copy, just send me a private email, I guess.
Jul 13 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
 (Just to be sure: I was talking about string mixins, not 
 macros, I haven't implemented macros.)

 Currently it isn't. It isn't really in a state where I'd like 
 to see it released. There are some language features still 
 missing, and its design is still insufficiently documented. 
 It's full of hacks to keep it compiling, and it currently only 
 compiles with DMD 2.060, hence it needs to very poorly emulate 
 UDA's.

 But if some of the regulars would like to get a copy, just send 
 me a private email, I guess.
btw was there any reason why you decided to not team up with deadalnix in this "alternative frontend" attempt? As far as I know you do collaborate quite a lot anyway which makes such effort distribution strange.
Jul 13 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/13/2014 05:24 PM, Dicebot wrote:
 On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
 (Just to be sure: I was talking about string mixins, not macros, I
 haven't implemented macros.)

 Currently it isn't. It isn't really in a state where I'd like to see
 it released. There are some language features still missing, and its
 design is still insufficiently documented. It's full of hacks to keep
 it compiling, and it currently only compiles with DMD 2.060, hence it
 needs to very poorly emulate UDA's.

 But if some of the regulars would like to get a copy, just send me a
 private email, I guess.
btw was there any reason why you decided to not team up with deadalnix in this "alternative frontend" attempt? As far as I know you do collaborate quite a lot anyway which makes such effort distribution strange.
Well, it's just some recreational hacking that I do now and then in my spare time, and then I prefer working with my own code.
Jul 13 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 13/07/14 17:17, Timon Gehr wrote:

 (Just to be sure: I was talking about string mixins, not macros, I
 haven't implemented macros.)
Aha, I misunderstood that.
 Currently it isn't. It isn't really in a state where I'd like to see it
 released. There are some language features still missing, and its design
 is still insufficiently documented. It's full of hacks to keep it
 compiling, and it currently only compiles with DMD 2.060, hence it needs
 to very poorly emulate UDA's.
Ok, I see. -- /Jacob Carlborg
Jul 14 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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
Jul 11 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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));
Jul 11 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 13 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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));
Jul 13 2014
prev sibling parent reply "fra" <a b.it> writes:
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.
Jul 13 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 13 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/13/14, 8:13 AM, fra wrote:
 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.
Do you really find my sample code hard to understand? Macros looks just like regular function definitions, only with placeholders. Concatenating strings to generate code, or creating ast nodes to generate code: that is plain impossible to understand and maintain.
Jul 13 2014
parent reply "fra" <a b.it> writes:
On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
 On 7/13/14, 8:13 AM, fra wrote:
 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.
Do you really find my sample code hard to understand? Macros looks just like regular function definitions, only with placeholders.
#define sizeof(x) rand() :o)
Jul 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/14/2014 03:25 AM, fra wrote:
 On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
 On 7/13/14, 8:13 AM, fra wrote:
 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.
Do you really find my sample code hard to understand? Macros looks just like regular function definitions, only with placeholders.
#define sizeof(x) rand() :o)
(This is not about C macros.)
Jul 13 2014
parent "fra" <a b.it> writes:
On Monday, 14 July 2014 at 01:32:38 UTC, Timon Gehr wrote:
 On 07/14/2014 03:25 AM, fra wrote:
 On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
 On 7/13/14, 8:13 AM, fra wrote:
 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.
Do you really find my sample code hard to understand? Macros looks just like regular function definitions, only with placeholders.
#define sizeof(x) rand() :o)
(This is not about C macros.)
(He is still advocating macros that would not need any keyword at the call site, and this half joke was about that.)
Jul 14 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 13 2014
prev sibling parent reply "sigod" <sigod.mail gmail.com> writes:
On Friday, 11 July 2014 at 01:35:41 UTC, 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?

 Thank you.
Something like this would be possible if one could get string representation of a lazy expression: ``` void _logfx(lazy int expr) { DebugLog(expr.stringof); // currently it outputs `expr()` fx(expr); } ```
Jul 13 2014
parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 12:55:30 UTC, sigod wrote:
 Something like this would be possible if one could get string 
 representation of a lazy expression:
 ```
 void _logfx(lazy int expr)
 {
     DebugLog(expr.stringof); // currently it outputs `expr()`
     fx(expr);
 }
 ```
lazy expressions are in fact delegates so this can't work reliably if there is no access to _logfx source - it has to be template parameter or language spec adjusted to be more demanding :(
Jul 13 2014