DIP 50 - AST macros

[deadalnix]

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright 
wrote:
> On 11/14/2013 11:40 AM, deadalnix wrote:
>> This is not proposing to configure syntax.
>
> Right, it is about inserting arbitrarily different meaning into 
> existing syntax.
>

Yes, but EXPLICITELY.

> (Also, a popular way of encrypting communications is to have 
> private meanings for phrases like "my cat ate my homework" 
> meaning "initiate Operation X".)
>

Note that you do not pretend that sentence with "THIS IS AN 
ENCRYPTED SENTENCE, HERE TO DECRYPT IT DO XXX".

> Now, let's take the AST macros, and pass it "4+3". Apparently 
> is a feature that the macro can transform this to produce 
> "hello" as the result. The result is that although the language 
> looks the same, there is no "anchor" a person can rely on to 
> indicate the meaning. The meaning of "fine" is reversed, so to 
> speak.
>

mymacro(4+3); // <= can be "hello"
myfunction(4+3); // <= can be "hello as well"

Quite frankly, this isn't really convincing.

> The riposte is, of course, every feature can be abused and good 
> programmers won't do that. Unfortunately, it's IN THE VERY 
> NATURE of macros to be abusive, and even the very best 
> programmers can and will take it to the limit. They will see 
> and decry the abuse in everyone else's code but their own, 
> which they will justify. As I said, I see this over and over 
> again.
>

I can find article on the internet saying the exact same thing 
for any feature ever invented. You'll find quite easily some 
about templates or operator overloading, but if you go in 
Functionnalland, you'll find the same about virtual dispatch and 
inheritance. If you go in OOPland, you'll find the exact same 
argument for monads.

You are qualifying the nature of macro here, that is not an 
argument. "Macros are bad, so I conclude macro are bad."

> On the other hand, with string mixins, it is immediately 
> obvious that one is dealing with different syntax, and so 
> expect something different to happen.

string mixins + a CTFE usable lexer+parser+D codegen from AST 
would achieve something close to the macros proposed here. This 
would obviously require quite a lot of work and is doomed to be 
dramatically slow and resources hungry, less hygienic (as 
identifier are implicitly resolved in the mixed in scope rather 
than explicitly) but quite close in term of capabilities.

You can't argue that string mixin is good while AST macro is bad.