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