www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - trait to get the body code of a function?

reply Guillaume Lathoud <gsub glat.info> writes:
Hello,

__traits and std.traits already offer access to function 
information like input parameters, e.g. in std.traits: 
ParameterIdentifierTuple ParameterStorageClassTuple

Even if that might sound strange, is there a compile time access 
to the body of the function, e.g. as a code string, or at least 
to the filename where it was declared?

I have not found a direct "string" access, but I found these:

https://dlang.org/phobos/std_traits.html#moduleName

https://dlang.org/phobos/std_traits.html#packageName

...and I am not sure how to proceed from here to get the code as 
a string that declared the function. Context: I have some 
compile-time ideas in mind (code transformation).

Best regards,
Guillaume Lathoud
Jul 23 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/07/2018 4:43 PM, Guillaume Lathoud wrote:

 Hello,
 
 __traits and std.traits already offer access to function information 
 like input parameters, e.g. in std.traits: ParameterIdentifierTuple 
 ParameterStorageClassTuple
 
 Even if that might sound strange, is there a compile time access to the 
 body of the function, e.g. as a code string, or at least to the filename 
 where it was declared?
 
 I have not found a direct "string" access, but I found these:
 
 https://dlang.org/phobos/std_traits.html#moduleName
 
 https://dlang.org/phobos/std_traits.html#packageName
 
 ...and I am not sure how to proceed from here to get the code as a 
 string that declared the function. Context: I have some compile-time 
 ideas in mind (code transformation).
 
 Best regards,
 Guillaume Lathoud


Doesn't exist.
Jul 23 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole wrote:

 On 24/07/2018 4:43 PM, Guillaume Lathoud wrote:

 [...]


 Doesn't exist.


Well, IMO it should exist as it can be quite useful for 
generating metainfo.
Jul 24 2018
parent reply Guillaume Lathoud <gsub glat.info> writes:
On Tuesday, 24 July 2018 at 14:26:45 UTC, 12345swordy wrote:

 On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole 
 wrote:

 On 24/07/2018 4:43 PM, Guillaume Lathoud wrote:

 [...]


 Doesn't exist.


 Well, IMO it should exist as it can be quite useful for 
 generating metainfo.


Thanks for all the answers. I've just had a look at an 
alternative: using dmd as a package. However that's a lot of doc 
to browse... Maybe someone has experience with dmd as a package?

Otherwise I'll just stick to strings, but it'd be nice to have.

Best regards,
Guillaume
Jul 24 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/07/2018 5:32 AM, Guillaume Lathoud wrote:

 Thanks for all the answers. I've just had a look at an alternative: 
 using dmd as a package. However that's a lot of doc to browse... Maybe 
 someone has experience with dmd as a package?


Not a solution. Leaks memory, not reusable and in general not very 
friendly to work with.
Jul 24 2018
parent reply Guillaume Lathoud <gsub glat.info> writes:
On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole 
wrote:

 On 25/07/2018 5:32 AM, Guillaume Lathoud wrote:

 Thanks for all the answers. I've just had a look at an 
 alternative: using dmd as a package. However that's a lot of 
 doc to browse... Maybe someone has experience with dmd as a 
 package?


 Not a solution. Leaks memory, not reusable and in general not 
 very friendly to work with.


Thanks.
Jul 25 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud 
wrote:

 On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole 
 wrote:

 On 25/07/2018 5:32 AM, Guillaume Lathoud wrote:

 Thanks for all the answers. I've just had a look at an 
 alternative: using dmd as a package. However that's a lot of 
 doc to browse... Maybe someone has experience with dmd as a 
 package?


 Not a solution. Leaks memory, not reusable and in general not 
 very friendly to work with.


 Thanks.


Please submit a bug report to Bugzilla on this, as I am also 
interest in this.

Alexander
Jul 25 2018
parent Seb <seb wilzba.ch> writes:
On Wednesday, 25 July 2018 at 19:10:03 UTC, 12345swordy wrote:

 On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud 
 wrote:

 On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole 
 wrote:

 On 25/07/2018 5:32 AM, Guillaume Lathoud wrote:

 Thanks for all the answers. I've just had a look at an 
 alternative: using dmd as a package. However that's a lot of 
 doc to browse... Maybe someone has experience with dmd as a 
 package?


 Not a solution. Leaks memory, not reusable and in general not 
 very friendly to work with.


 Thanks.


 Please submit a bug report to Bugzilla on this, as I am also 
 interest in this.

 Alexander


I once had a similar PR in DMD to a potential 
`__traits(getFunctionBody, X)` for `__traits(documentation, X)`:

https://github.com/dlang/dmd/pull/6872

There was a bit of a forum discussion about it: 
https://forum.dlang.org/post/cwjtsmnwwwwepvgvlqcy forum.dlang.org

The gist:


 Putting this in the Phantom Zone due it needing a compelling 
 use case(s) to justify consuming memory and compilation time. 
 <<




tl;dr: just Bugzilla won't do it. It will need a short DIP 
illustrating use cases. Sorry. Happy to implement it for you 
though.
Jul 26 2018
prev sibling next sibling parent Timoses <timosesu gmail.com> writes:
On Tuesday, 24 July 2018 at 04:43:33 UTC, Guillaume Lathoud wrote:

 Hello,

 __traits and std.traits already offer access to function 
 information like input parameters, e.g. in std.traits: 
 ParameterIdentifierTuple ParameterStorageClassTuple

 Even if that might sound strange, is there a compile time 
 access to the body of the function, e.g. as a code string, or 
 at least to the filename where it was declared?

 I have not found a direct "string" access, but I found these:

 https://dlang.org/phobos/std_traits.html#moduleName

 https://dlang.org/phobos/std_traits.html#packageName

 ...and I am not sure how to proceed from here to get the code 
 as a string that declared the function. Context: I have some 
 compile-time ideas in mind (code transformation).

 Best regards,
 Guillaume Lathoud


Not sure if this could be of interest:
https://forum.dlang.org/thread/ifllo2$a45$1 digitalmars.com
Jul 24 2018
prev sibling parent reply Mr.Bingo <Bingo Namo.com> writes:
On Tuesday, 24 July 2018 at 04:43:33 UTC, Guillaume Lathoud wrote:

 Hello,

 __traits and std.traits already offer access to function 
 information like input parameters, e.g. in std.traits: 
 ParameterIdentifierTuple ParameterStorageClassTuple

 Even if that might sound strange, is there a compile time 
 access to the body of the function, e.g. as a code string, or 
 at least to the filename where it was declared?

 I have not found a direct "string" access, but I found these:

 https://dlang.org/phobos/std_traits.html#moduleName

 https://dlang.org/phobos/std_traits.html#packageName

 ...and I am not sure how to proceed from here to get the code 
 as a string that declared the function. Context: I have some 
 compile-time ideas in mind (code transformation).

 Best regards,
 Guillaume Lathoud


If all you need is the string you can write a template function 
that imports the file and searches for the function and returns 
it's body.

It's not very robust but it can work for some cases. D really 
should allow one to get the function body in D, possibly in a 
type safe way(such as each line is parsed properly and return 
type info about what the line contains.
Jul 26 2018
parent reply Alex <sascha.orlov gmail.com> writes:
On Thursday, 26 July 2018 at 07:32:19 UTC, Mr.Bingo wrote:

 If all you need is the string you can write a template function 
 that imports the file and searches for the function and returns 
 it's body.

 It's not very robust but it can work for some cases. D really 
 should allow one to get the function body in D, possibly in a 
 type safe way(such as each line is parsed properly and return 
 type info about what the line contains.


I would argue, just because of "type safety" you mentioned, D 
should not allow one to get the function body. The type safety is 
not achievable because of
https://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence

The string itself could be useful however... Whatever OP has in 
mind with this string...
Jul 26 2018
parent reply Mr.Bingo <Bingo Namo.com> writes:
On Thursday, 26 July 2018 at 10:20:04 UTC, Alex wrote:

 On Thursday, 26 July 2018 at 07:32:19 UTC, Mr.Bingo wrote:

 If all you need is the string you can write a template 
 function that imports the file and searches for the function 
 and returns it's body.

 It's not very robust but it can work for some cases. D really 
 should allow one to get the function body in D, possibly in a 
 type safe way(such as each line is parsed properly and return 
 type info about what the line contains.


 I would argue, just because of "type safety" you mentioned, D 
 should not allow one to get the function body. The type safety 
 is not achievable because of
 https://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence


What the hell does that have to do with anything? I don't know 
what you are talking about when it comes to "type safety" and 
equivalence. What I am talking about is being able to parse the 
function body in a type safe way rather than having to hack 
strings or write a D parser oneself.

Instead of

     "int x;"

one has <expression, <int, "x">>

or whatever the parser parses in to(some type of AST).


 The string itself could be useful however... Whatever OP has in 
 mind with this string...



Having a code block is useful in many ways simply because not 
having it is the most limiting case. If one doesn't have it and 
requires it then it is impossible for them to do what they want. 
If one does have it and has no need, then no loss. Lots of people 
like to err on the side of "caution" which is really the side of 
limitations and frustrations and laziness. Of course, sometimes 
things should be limited, but I think this is probably not one of 
those cases(I see no harm in allowing meta code to get a function 
body and, say, create another function based off it but a slight 
change.

For example, one could mutate algorithms and run genetics 
algorithms on them to see how function scan evolve. This might 
lead to genetic ways to assemble programs. In any case, one can't 
do it since one can't get at a functions body.

For example, maybe one wants a way to debug a mixin:

mixin("int x;"); <- can't debug

void foo()
{
    int x;
}

mixin(funcBody!foo) <- can debug since we defined foo outside of 
the mixin and the compiler see's it naturally.
Jul 26 2018
parent reply Alex <sascha.orlov gmail.com> writes:
On Thursday, 26 July 2018 at 11:54:39 UTC, Mr.Bingo wrote:


 The string itself could be useful however... Whatever OP has 
 in mind with this string...



 Having a code block is useful in many ways simply because not 
 having it is the most limiting case. If one doesn't have it and 
 requires it then it is impossible for them to do what they 
 want. If one does have it and has no need, then no loss. Lots 
 of people like to err on the side of "caution" which is really 
 the side of limitations and frustrations and laziness. Of 
 course, sometimes things should be limited, but I think this is 
 probably not one of those cases(I see no harm in allowing meta 
 code to get a function body and, say, create another function 
 based off it but a slight change.

 For example, one could mutate algorithms and run genetics 
 algorithms on them to see how function scan evolve. This might 
 lead to genetic ways to assemble programs. In any case, one 
 can't do it since one can't get at a functions body.

 For example, maybe one wants a way to debug a mixin:

 mixin("int x;"); <- can't debug

 void foo()
 {
    int x;
 }

 mixin(funcBody!foo) <- can debug since we defined foo outside 
 of the mixin and the compiler see's it naturally.


I'm with you in this part.


 I would argue, just because of "type safety" you mentioned, D 
 should not allow one to get the function body. The type safety 
 is not achievable because of
 https://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence


 What the hell does that have to do with anything? I don't know 
 what you are talking about when it comes to "type safety" and 
 equivalence. What I am talking about is being able to parse the 
 function body in a type safe way rather than having to hack 
 strings or write a D parser oneself.

 Instead of

     "int x;"

 one has <expression, <int, "x">>

 or whatever the parser parses in to(some type of AST).


I'll try to reformulate this.

Take the example given at
https://dlang.org/spec/function.html#closures
Paragraph 2.

Now, examine the contents of functions abc and def.

Does the functionality differ? For sure not.
Does the compiler knows it? It is not guaranteed.

The article I cited and the literature behind it state, that in 
general, an equivalence of function contents can not be tracked. 
However, to state for a function to be equal with another 
function exactly this is needed. And I thought you meant this by 
"type safety"...
Jul 26 2018
parent reply Mr.Bingo <Bingo Namo.com> writes:
On Thursday, 26 July 2018 at 13:27:09 UTC, Alex wrote:

 On Thursday, 26 July 2018 at 11:54:39 UTC, Mr.Bingo wrote:


 The string itself could be useful however... Whatever OP has 
 in mind with this string...



 Having a code block is useful in many ways simply because not 
 having it is the most limiting case. If one doesn't have it 
 and requires it then it is impossible for them to do what they 
 want. If one does have it and has no need, then no loss. Lots 
 of people like to err on the side of "caution" which is really 
 the side of limitations and frustrations and laziness. Of 
 course, sometimes things should be limited, but I think this 
 is probably not one of those cases(I see no harm in allowing 
 meta code to get a function body and, say, create another 
 function based off it but a slight change.

 For example, one could mutate algorithms and run genetics 
 algorithms on them to see how function scan evolve. This might 
 lead to genetic ways to assemble programs. In any case, one 
 can't do it since one can't get at a functions body.

 For example, maybe one wants a way to debug a mixin:

 mixin("int x;"); <- can't debug

 void foo()
 {
    int x;
 }

 mixin(funcBody!foo) <- can debug since we defined foo outside 
 of the mixin and the compiler see's it naturally.


 I'm with you in this part.


 I would argue, just because of "type safety" you mentioned, D 
 should not allow one to get the function body. The type 
 safety is not achievable because of
 https://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence


 What the hell does that have to do with anything? I don't know 
 what you are talking about when it comes to "type safety" and 
 equivalence. What I am talking about is being able to parse 
 the function body in a type safe way rather than having to 
 hack strings or write a D parser oneself.

 Instead of

     "int x;"

 one has <expression, <int, "x">>

 or whatever the parser parses in to(some type of AST).


 I'll try to reformulate this.

 Take the example given at
 https://dlang.org/spec/function.html#closures
 Paragraph 2.

 Now, examine the contents of functions abc and def.

 Does the functionality differ? For sure not.
 Does the compiler knows it? It is not guaranteed.

 The article I cited and the literature behind it state, that in 
 general, an equivalence of function contents can not be 
 tracked. However, to state for a function to be equal with 
 another function exactly this is needed. And I thought you 
 meant this by "type safety"...



But this doesn't matter... If the idea is to return a string then 
it doesn't matter, just return the requested function body. If is 
to return an AST then it just gives(in whatever suitable form) 
the AST for the requested function...

It's really not complicated:

Suppose one could get the function body as a string and suppose 
one had a D parser. Just use the D parser on the string and 
return the AST. D already has the D parser in it and also already 
has the string in it. It's just a matter of someone exposing that 
to the programmer to use. There is no issue anywhere because the 
function cannot change while compiling(hence there can be no sync 
issues).

I mean, if we want to see the function body we can just open up a 
text editor... If we want to know the syntactical structure we 
just parse the code with our brain. All that is being asked is to 
have the compiler give us the string(easy) and parse it for us in 
to some easy to use structure(some work but not hard, in fact, it 
might be easy).

There are no function pointers to deal with, no compiling, etc.


Again, we can already do this stuff by hand by using import to 
import the file containing the function we want to get... and use 
a D parser to find the function proper and then grab the function 
body and return it as a string. It is not hard to do but does 
require using -J on the source path.


Here is a simple dumb way to get the function body. The problem 
with "library" solutions is that they are not robust.


import std.stdio;



int foo(int x)
{
	return x;
}

auto GetFunctionBody(alias B)()
{
	import std.traits, std.meta, std.typecons, std.algorithm, 
std.string, std.range;
	enum ft = typeof(B).stringof;
	enum rt = ReturnType!(B).stringof;
	enum fn = fullyQualifiedName!(B);
	enum n = split(fn, ".")[$-1];
	enum mn = join(split(fn, ".")[0..$-1])~".d";
	enum fs = rt~" "~n~ft[rt.length..$];

	enum file = import(mn);

	
	pragma(msg, n, ", ", ft, ", ", rt, ", ", fn, ", ", mn, ", ", fs);
	
	auto res = "";
	auto found = false;
	for(int i = 0; i < file.length - fs.length; i++)
	{
		if (file[i..i+fs.length] == fs)
			found = true;	


		if (found)
			res ~= file[i];
		if (file[i] == '}')
			found = false;	
	}

	
		
	return res;
}


int main()
{

	writeln(GetFunctionBody!(foo));
	
	getchar();

     return 0;
}
Jul 26 2018
parent Mr.Bingo <Bingo Namo.com> writes:
So, does anyone want to take up the challenge of writing such a 
function that can safely get the function body? I guess D 
CTFE'able D parser would be required and basically use what I've 
given above. I've seen a few lexers around but not messed with 
them.

This will at least fill in a gap.
Jul 29 2018