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);
}
```

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 :(

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

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.

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.

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.

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.

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.

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?

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.