On 2021-01-06 17:58, Paul Backus wrote:

> You don't need a stable AST API for AST macros, you just need quasi-quoting and unquoting, à la Common Lisp. There's an old talk by Walter and Andrei that includes a sketch of what AST macros might look like in D [1], which contains the following example:
> 
>      macro foo(e) { e = 3; }
> 
> In Common Lisp, the equivalent would be
> 
>     (defmacro foo (e) `(setf ,e 3))
> 
> You will notice that nowhere in either example is the AST exposed directly.
> 
> [1] https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h5m37s

Yes. Here's my suggestion [1] and bottom of [2].

[1] https://wiki.dlang.org/DIP50#Quasi-Quoting
[2] https://forum.dlang.org/post/rt4df4$2n8g$1@digitalmars.com

-- 
/Jacob Carlborg

On Wednesday, 6 January 2021 at 16:43:26 UTC, Jacob Carlborg wrote:
> I would not expose it exactly as it is. But I don't think a completely new design is required. If you look carefully at my design [1] you'll see that it doesn't map exactly (but more or less) to the internal AST in DMD.

Ok, but it would have to map exactly since it would be modified after a succession of template evaluations? Or maybe not.

On 2021-01-06 20:36, Ola Fosheim Grøstad wrote:

> Ok, but it would have to map exactly since it would be modified after a succession of template evaluations? Or maybe not.

I'm not sure if I follow. But the compiler will convert between the internal AST and external AST on macro boundaries, i.e. when something is passed to a macro and when something is returned.

-- 
/Jacob Carlborg

On Wednesday, 6 January 2021 at 14:08:15 UTC, sighoya wrote:
> On Monday, 4 January 2021 at 19:30:31 UTC, Stefan Koch wrote:
>> With this in mind, please tell me what you think :)
>
> I like the idea of type functions for type calculus only, because it's easier to get the work done and feels more natural as it is pure D-code, not a foreign language to talk with.
>
> Though I wouldn't choose them to introduce generics in D, I think templates are enough for that part.
>
Indeed templates are enough for that.
The issue comes when you want a typefunction to instantiate a template
given a type value, since those values are runtime arguments,
(even though they are evaluated by CTFE)
they cannot be a compile time argument to a template.
As that could change the shape of the function body
(which would make caching impossible and require us to copy the function body on every call).

I don't see that much of an issue to have 2 ways of doing the same thing.
We have that all the time when a lower-level feature gets supplemented with a higher level one.
You just chose the right way for your abstraction level and performance requirements.

In the end there is not wanted wanting to convince people without data.
I am going to run my experiments and we'll see what comes out :)

On Thursday, 7 January 2021 at 10:39:02 UTC, Jacob Carlborg wrote:
> On 2021-01-06 20:36, Ola Fosheim Grøstad wrote:
>
>> Ok, but it would have to map exactly since it would be modified after a succession of template evaluations? Or maybe not.
>
> I'm not sure if I follow. But the compiler will convert between the internal AST and external AST on macro boundaries, i.e. when something is passed to a macro and when something is returned.

But you are able to traverse the whole external AST tree?

So you maintain what is equivalent of a virtual AST? Kinda like React does with a virtual DOM?

That's ok if only the virtual AST changes, then you can propagate changes to the real AST. UNLESS the compiler is caching information in other structures... At that point things get really hairy.

But how to detect changes in the real AST, if the compiler modifies it?

You need to add a tracking mechanism, dirty-marking or some such.

On 2021-01-07 15:05, Ola Fosheim Grøstad wrote:

> But you are able to traverse the whole external AST tree?

Yes.

> So you maintain what is equivalent of a virtual AST? Kinda like React does with a virtual DOM?
> 
> That's ok if only the virtual AST changes, then you can propagate changes to the real AST. UNLESS the compiler is caching information in other structures... At that point things get really hairy.
> 
> But how to detect changes in the real AST, if the compiler modifies it?
> 
> You need to add a tracking mechanism, dirty-marking or some such.

I haven't thought of that.

I have not been able to come up with any other way to expose the AST at least. Otherwise I think there would need to be some significant changes to how CTFE works in the compiler.

-- 
/Jacob Carlborg