DIP78 - macros without syntax extensions

[Artur Skawina via Digitalmars-d]

On 05/27/15 17:47, Idan Arye via Digitalmars-d wrote:
> On Wednesday, 27 May 2015 at 08:14:36 UTC, Kagamin wrote:
>> On Tuesday, 26 May 2015 at 23:47:41 UTC, Dennis Ritchie wrote:
>>> If this proposal is considered, it is required to propose to look
>>> at the implementation of macros in Nemerle. Many believe that it
>>> is in Nemerle macros implemented the most successful compared to
>>> other modern languages. Of course, the most successful macros are
>>> implemented in Lisp, but the syntax of the language is poor :)
>>
>> The problem with declarative macro system is that you would need to learn yet another language. Possibly turing-complete. And a declarative turing-complete language is an overkill both for usage and implementation. Imperative macros get it done in an intuitive way in the existing language.
> 
> But D already has such a declarative language - the one used in template metaprogramming. I think a macro system that plays well with that template metaprogramming sub-language will be really nice. For example, CTFE that works like a macro and returns types/aliases:
> 
>     Auto deduceType(Auto args) {
>         // some complex imperative code to deduce the type from the args
>         return DeducedType;
>     }
> 
>     struct Foo(T...) {
>         deduceType(T) value;
>     }

That already works. Eg:

   alias deduceType(Args...) = typeof({
      // some complex imperative code to deduce the type from the args
      import std.range;
      return mixin(iota(Args.length).map!q{`Args[`~text(a)~']'}().join("+"));
   }());

   struct Foo(T...) {
      deduceType!(T) value;
   }

   static assert(is(typeof(Foo!(short, ubyte, bool).value)==int));


What all these proposals seem to be about is:

a) better introspection (ie exposing a (preferably simplified and std) AST)
b) AST injection
c) "better" syntax
d) better "optimizations", meaning skipping the emission of code and data
     that is never used at runtime.

artur