On Wed, 09 May 2012 15:03:21 -0700, Era Scarecrow <[email protected]>
wrote:
On Wednesday, 9 May 2012 at 19:27:19 UTC, Adam Wilson wrote:
The problem is thus: CTFE requires that any function that it could
possibly evaluated by CTFE, must retain it's implementation.
Unfortunately, there is simply no way for the DI generation system to
know which functions are capable of being called by CTFE and which
ones actually are.
This limitation is due to the fact that DI generation must be run
before Semantic Analysis because said analysis may perform significant
rewrites of the AST. There is even a large (for DMD) comment in the
main function of DMD explaining that DI generation should not be moved
from where it is due to the inconsistencies that could arise.
The patch I created currently fails in the autotester because the
template function dur() in the druntime is called via CTFE from
Phobos. Per the community agreed upon DI rules, the function
implementation of the Duration constructor that is called by the dur()
function is stripped away and CTFE fails.
We as a community need to decide how important these two features are.
Here are the Pro's of each feature as I see it. I encourage you to add
to this list and debate the merits of each.
Pro's for DI:
Shared libraries are useless without proper header-style interfaces to
the code.
Can reduce compile time.
Required by business so as not to share the entire code-base of their
product.
Pro's of CTFE:
Makes writing certain types of otherwise complicated code simple.
Very useful to systems programmers.
By my view of it, lack of DI is a major blocker to any business
looking to use D, including mine; and that CTFE is just
"nice-to-have". And I would argue that if D wants to see any real
usage above the 0.3% it got on the May TIOBE index, it needs serious
business investment in using the language. My company would love to
use D, but we can't because we don't want to release our entire
code-base; hence my work on the DI generation patch. I would suggest
to you that almost every business looking at D is going to find the
current DI situation ... untenable.
Perhaps I missed something as I'm reading this.
Why would this be such a big deal? As I understand it some of this
comes from D couldn't compile to libraries (if that's different now I am
not sure, haven't kept up with all the updates) so everything in phobos
is distributed as source.
Theoretically D can compile Shared Libraries now. Which means that DI
files are going to be more useful than ever.
If we can't compile to a callable library (static or dynamic) for a
while and can't use CTFE on non-source, then the problem is more
explicitly present and either needs a workaround or some type of
convention.
CTFE cannot currently call a function without it's source.
However IF we can compile to libraries and those compiled libraries
are exported out with the .di files (I'd personally require the .di file
information also bs part of the library as a public string, so you can't
mix up wrong versions of .di files, which you can then extract) why then
that a problem? The binary execution code is already available and we
should be able to call it through the compiler as long as the interfaces
are used properly. I see this only as a partial problem being as the
compiler is written in C++ and not D.
Course there are security issues, if a module harbored a virus and
using CTFE or calling those functions unleashed it, assuming the program
had permissions to do any damage... At which time the compiler would
need very low permissions (or it's own UID) allowed to run so in those
cases it could crash gracefully...
Perhaps I'm just rambling now..
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
