trait to get the body code of a function?

[Alex]

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"...