Walter, I need a __trait please.

[Jacob Carlborg via Digitalmars-d]

On 15/03/16 12:47, ZombineDev wrote:

> Hi Jacob,
>
> I've been thinking quite a bit about the next step in the evolution of
> D's metaprogramming, and I thought that AST macros are the best way
> forward, however since then I become convinced that macros are a
> distraction from a much more powerful language feature.
>
> Firstly, macros are a kind of declarative preprocessor, in the case of
> AST macros they process ASTs. Surely operating at AST level is a
> significant improvement than plain text processing, however macros by
> themselves are separate language that requires a lot of additions to
> work. One of the biggest advantages of D is you don't need to use a
> different language for CTFE. Furthermore being purely declarative is
> very limiting, compared to how powerful imperative CTFE is.

AST macros can be implemented in many different ways. The basic idea of 
the way I'm thinking is very simple. It consists of two feature (or one, 
depending on how you look at it).

1. A way to expose parts of the AST in the compiler to user
2. A way to turn an AST create by a user to something the compiler can use

Example:

macro foo(Ast a)
{
     return a;
}

foo(3 + 4);

The compiler exposes the AST of the expression "3 + 4" as the library 
type "Ast". That would be 1.

Converting the returned value of the library type "Ast" to something the 
compiler can use. That would be 2.

The rest is just manipulating AST's with CTFE.

> Next, macros may add new syntax to the language

Not in my vision.

> or change the meaning of the existing syntax which would be a very disruptive change to the
> language (even if it's made in a backwards compatible way).

It's already possible to do that today with operator overloading. I 
think that's a very important feature of AST macros, which allows to do 
things like this:

Person.where(e => e.name == "John")

Which would be turned into an SQL query that fetches all rows from the 
"Person" table where name is "John".

> Instead I think that if we improve D's existing introspection
> capabilities and expose the compiler as a library at compile-time, we
> will have a much powerful system than any potential macro system, for a
> fraction of the complexity.
>
> These videos are what changed my mind:
> 1. https://www.youtube.com/watch?v=OHZwYYW9koI
> 2. https://www.youtube.com/watch?v=59lKAlb6cRg
> (Jonathan Blow's programming language for games)

I've only watched the second video, but yes, that's very powerful. I 
don't think what's in the video is any more or less complex than my view 
of AST macros. It's just two different ways of exposing the AST of the 
compiler. I think both kinds are useful. Or rather, it's useful to have 
a way to hook into the compiler before all semantic processing is done.

For more details of my vision see DIP 50 [1].

[1] http://wiki.dlang.org/DIP50

-- 
/Jacob Carlborg