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