Getting function's AST at compile-time

Daniel N ufo at orbiting.us
Mon Sep 16 07:08:22 PDT 2013


On Monday, 16 September 2013 at 07:07:01 UTC, Kapps wrote:
> There was a pull request previously for a trait that would get 
> the code of a function, but apparently there were issues with 
> when the semantic stage was run and having things be 
> transformed at that point. I don't remember the exact details, 
> but the pull request goes into a bit more detail: 
> https://github.com/D-Programming-Language/dmd/pull/953

The compiler wouldn't even have to provide the original source, 
only 2 offsets into the original file which then could be used to 
create a slice from an user owned "import(__FILE__)" buffer.

I posted a very inefficient proof-of-concept hack a while ago 
when the original [] UDA syntax was used, now slightly updated 
for @.
http://dpaste.dzfl.pl/b6c7a95f

The __LINE__ based approach is clearly not robust enough... but 
it allows prototyping as if (a very broken) .codeof was available 
today.

I think a realistic first step would be to have a working 
".codeof", instead of arguing how the perfect AST representation 
would look like. Once a robust way of getting the original code 
is available, it's easy to plugin the upcoming std.lex or any 3rd 
party software, like pegged to build AST:s. After people start 
using this feature a lot, it will be easier to define the next 
step.

One way could be to have a 3rd param to codeof for the 
import(__FILE__)" buffer.

__traits(codeof, buffer_2_slice, symbol)


More information about the Digitalmars-d mailing list