DIP 50 - AST macros

[Zsombor Barna]

On Tuesday, 12 November 2013 at 23:34:38 UTC, Martin Nowak wrote:
> On 11/12/2013 09:36 PM, deadalnix wrote:
>> The thing I'd like to be able to do it to create a 
>> async/await/yield
>> like mechanism, purely as library.
>
> That's a prime example for AST macros.

First of all: I haven't used macros extensively yet. Its merely a 
theoretical viewpoint, so don't take the arguments 
well-established.

Macros could be used as in ScalaCL ( I mean the latest version, 
which is experimental : https://github.com/ochafik/ScalaCL ). I 
like the idea using the host language ( or a subset of it) to 
program GPUs, not C, like PyOpenCL does. It reduces the 
complexity of the problem when you switch target of the algorithm 
from CPU to GPU and back.

Macros could also be used in (re)implementing some of the basic 
syntax - that's what developers of Nemerle did. Somebody can 
argue whether it was a good idea or not, but it would be 
interesting to disable syntax by disabling the macro that 
transforms it by a single line in the file ( not importing the 
macro ). ( Could be useful for microcontroller platforms to 
control the runtime's memory usage by disabling certain features 
- not compiling them into the executable )

In AOT compilation, there isn't any difference between macros and 
CTFE functions which do something with AST. That would be a way 
to implement them - creating a compiler API which could only be 
used by compile-time functions.

Yeah, and I know, it's crippling when code is ambigous. But I 
also think macros are the best way to define interfaces for 
modules. Using them can obfuscate code very easily when not 
enough care is taken handling them and it can make the learning 
curve much steeper, but there always existed ill-designed API-s 
and we could still use the good old tools to get the API done :) 
. Maybe it wouldn't be as good as a macro-ed API would be, but 
still works. If we choose the right tool, it can lower the 
complexity of the API.

Let's have a look at the feature: pointers. A very powerful, be 
also dangerous weapon that cal blow up the entire program 
suddenly. With some techniques used to fend off the problems it 
can cause, it can be much safer. Rust made a trial with their 
pointer system. I don't think it is a solution, but ignoring the 
problem isn't either.

The second example: the first cannons blew up, killing people. 
But time showed technology can evolve.
The area of macros - in my opinion - is not explored yet. Only 
the use of them can reveal the ways to make them better. 
Theoretical scientists cannot create good solutions for everyday 
use in the first place. It's a trial-and-error process.

By allowing usage of macros only in certain cases, language 
desginer can make the burden of the coders lighter ( although I 
like statement macros, they can be very ambigous ). Also, if 
designer make macros visually very distinct from other tokens, 
users can read the code even easier, but sense is needed when 
choosing a syntax which fits into the language. ( #-s are very 
alien from D, in my opinion ).

Personally I wouldn't like hacking on the compiler or creating a 
whole new parser to do the same as we could do with macros, and I 
suggest a trial.
Another option is to  wait until somebody comes up with an idea 
and when time proved if the solution is right, include it - doing 
this saves a lot of work. That's how cutting-edge technologies 
work ( even if AST macros are an old idea ).