On Thursday, 29 August 2019 at 10:20:28 UTC, RazvanN wrote:
> On Wednesday, 28 August 2019 at 22:18:28 UTC, Max Haughton wrote:
>> On Wednesday, 28 August 2019 at 17:35:56 UTC, Manu wrote:
>>> As a development workflow feature, having compiler access to symbol comments would be very useful in many cases.
>>
>> Speaking of which, has anyone tried/discussed giving access to a frozen version of the AST through (say) __traits(getAST, symbol)? I'd try it myself but I haven't spent the time learning how dmd works.
>
> Whatever you want to do with traits(getAST) would likely be a job for dmd as a library.

The use cases for traits(getAST) are CTFE-only by definition (think implementing AST-macros), so using dmd as a library is not an option.

See for example:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/

https://doc.rust-lang.org/reference/procedural-macros.html
https://doc.rust-lang.org/1.30.0/book/2018-edition/appendix-04-macros.html

https://nim-lang.github.io/Nim/tut3.html
https://nim-lang.org/blog/2018/06/07/create-a-simple-macro.html
https://nim-lang.github.io/Nim/manual.html#macros

BTW, we had a long discussion about that on Slack a while ago:
https://dlang.slack.com/archives/C1ZDHBB2S/p1511992601000433

On Thursday, 29 August 2019 at 10:20:28 UTC, RazvanN wrote:
>
> Whatever you want to do with traits(getAST) would likely be a job for dmd as a library.

BTW, the argument "<..> is a job for the compiler as a library" is what languages like Go use as an excuse for why they don't have neither templates, nor even generics. And if you want type-safety, you would use build-time (not compile-time) code-generation tools like this:

https://godoc.org/github.com/searKing/golang/tools/cmd/go-syncmap
https://godoc.org/github.com/searKing/golang/tools/cmd/go-syncpool
https://github.com/ChimeraCoder/gojson

In D such tools are completely replaces by templates (modulo compilation time trade off). If you have experience with languages that have some sort of AST macros, you start to think of languages that don't, just as we think of languages without templates or generics, like Go.

See also https://web.archive.org/web/20190622093122/http://wiki.c2.com/?BlubParadox ;)

On Thursday, 29 August 2019 at 10:20:28 UTC, RazvanN wrote:
> On Wednesday, 28 August 2019 at 22:18:28 UTC, Max Haughton wrote:
>> On Wednesday, 28 August 2019 at 17:35:56 UTC, Manu wrote:
>>> As a development workflow feature, having compiler access to symbol comments would be very useful in many cases.
>>
>> Speaking of which, has anyone tried/discussed giving access to a frozen version of the AST through (say) __traits(getAST, symbol)? I'd try it myself but I haven't spent the time learning how dmd works.
>
> Whatever you want to do with traits(getAST) would likely be a job for dmd as a library.

I know but I had a idea to generate instruction selection trees based on D code and a theorem prover which would be very nice to do actually at compile time. Inefficient but very cool

You also can't get a list of template constraints from traits, I don't think.

On 2019-08-29 00:18, Max Haughton wrote:

> Speaking of which, has anyone tried/discussed giving access to a frozen version of the AST through (say) __traits(getAST, symbol)? I'd try it myself but I haven't spent the time learning how dmd works.

Yes, it's been discussed. Also AST macros which are related has been discussed quite a lot. I've worked a bit on the compiler to implement AST macros [1]. `__traits(getAST)` would be half of what's required for AST macros.

It's pretty easy to do, just a bit tedious.

[1] https://github.com/jacob-carlborg/dmd/tree/macro

-- 
/Jacob Carlborg

On 2019-08-29 13:24, Petar Kirov [ZombineDev] wrote:

> BTW, the argument "<..> is a job for the compiler as a library" is what languages like Go use as an excuse for why they don't have neither templates, nor even generics. And if you want type-safety, you would use build-time (not compile-time) code-generation tools like this:
> 
> https://godoc.org/github.com/searKing/golang/tools/cmd/go-syncmap
> https://godoc.org/github.com/searKing/golang/tools/cmd/go-syncpool
> https://github.com/ChimeraCoder/gojson
> 
> In D such tools are completely replaces by templates (modulo compilation time trade off). If you have experience with languages that have some sort of AST macros, you start to think of languages that don't, just as we think of languages without templates or generics, like Go.
> 
> See also https://web.archive.org/web/20190622093122/http://wiki.c2.com/?BlubParadox ;)

True, although I think there are use cases for both AST macros/`__traits(getAST)` and using the compiler as a library.

Something like inspecting the AST of all source files of a project and do something seems a bit difficult to do with AST macros/`__traits(getAST)`.

-- 
/Jacob Carlborg

On Thursday, 29 August 2019 at 12:27:33 UTC, Jacob Carlborg wrote:
>
> True, although I think there are use cases for both AST macros/`__traits(getAST)` and using the compiler as a library.
>
> Something like inspecting the AST of all source files of a project and do something seems a bit difficult to do with AST macros/`__traits(getAST)`.

Yes of course, I'm just saying that __traits(getAST) is definitely a necessary feature, just like templates are today for D. That doesn't exclude all the other valid reasons for using the compiler as a library.

On Wednesday, August 28, 2019 4:18:28 PM MDT Max Haughton via Digitalmars-d wrote:
> On Wednesday, 28 August 2019 at 17:35:56 UTC, Manu wrote:
> > As a development workflow feature, having compiler access to symbol comments would be very useful in many cases.
>
> Speaking of which, has anyone tried/discussed giving access to a
> frozen version of the AST through (say) __traits(getAST, symbol)?
> I'd try it myself but I haven't spent the time learning how dmd
> works.

Walter has made it quite clear that he has no interest in exposing the AST to the program or in having something like AST macros in the language. It's come up time and time again, and it's always rejected.

- Jonathan M Davis

On 2019-08-30 07:41, Jonathan M Davis wrote:

> Walter has made it quite clear that he has no interest in exposing the AST
> to the program or in having something like AST macros in the language. It's
> come up time and time again, and it's always rejected.

Copy constructors and binding rvalues to references have come up several times throughout the years and has always been rejected. Now we have copy constructors in the language and most likely binding rvalues to references soon.

The funny thing though, is that at the first D conference Walter presented a talk about D2 (if I recall correctly) that included AST macros as one of the features. Not sure what or who changed his mind about that.

-- 
/Jacob Carlborg