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)

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

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

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

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

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.

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

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.

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

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?