trait to get the body code of a function?

Mr.Bingo Bingo at Namo.com
Thu Jul 26 11:54:39 UTC 2018


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.





More information about the Digitalmars-d-learn mailing list