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)

end

def fx(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